Playing Devil's advocate: I am always curious when folks complain about a "huge" dependency stack (for a start the term huge is inherently subjective). This is pretty much the reality of the modern OSS ecosystem, people (yourself included) try to avoid reinventing the wheel and want to focus on solving their problem rather than all the mundane engineering that goes into enabling that.
While there are legitimate use cases where keeping the dependency stack minimal is desirable (e.g. embedded computing) for most use cases the size of your dependency stack isn't a major issue. And if it is there are tools that can aggressively optimise this e.g. ProGuard [1] that are in common usage (e.g. the Android build chain incorporates ProGuard by default) Could you expand on why you see this as being such a problem? There's clearly a trade off between size of dependency stack and how much code you want to personally develop and maintain but my personal preference is usually to minimize the latter. Rob [1] https://www.guardsquare.com/en/products/proguard On 08/09/2019, 09:16, "Marco Neumann" <marco.neum...@gmail.com> wrote: Romain, sure Jena gives you so much more than just the basic graph infrastructure. I wasn't acutely aware of the guava shade mandatory requirement in a minimal viable setup of Jena. Still I would encourage you to engage with Jena community to discuss design ideas and opportunity for reuse of jena components in your work on graph at commons and apache. FYI I currently need the following libraries in a minimal viable setup to work with the Jena graph api. jena-base (215kb), jena-core (1.69mb), jena-shaded-guave (2.73mb), log4j (479kb), slf4j-log (41kb), slf4j-api (12kb) Marco On Sat, Sep 7, 2019 at 10:33 PM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > Hi Marco, > > Had a look to jena for another project and didnt evaluate it here for these > reasons (happy to be wrong): > > - dep stack was huge for only graph part (guava shade, some other uneeded > commons etc, most being excludable but without guarantees in time) > - it is not about DAG and therefore misses navigation methods (which is > what I need in addition to "mutation" methods for the algo i want to impl) > - it is not the goal of jena so API and core stack can evolve in an > undesired manner > > To mention alternatives, spark, flink, beam, ignite for the few I can think > about, have something not crazy but still this stack and API issues :(. > > This is how i ended up looking commons, to try to have something stable and > dep free. > > Romain > > > Le sam. 7 sept. 2019 à 23:15, Marco Neumann <marco.neum...@gmail.com> a > écrit : > > > I highly recommend to take a look at the Apache Jena project for > > inspiration here. It has a very mature graph representationat this point: > > > > https://jena.apache.org/ > > > > > > > https://jena.apache.org/documentation/javadoc/jena/org/apache/jena/graph/Graph.html > > > > Jena use triples in the form of <v><e><v> to encode the graph<v,e> > > > > give it try and make sure to post to us...@jena.apache.org if you have > any > > questions > > > > enjoy, > > Marco > > > > On Sat, Sep 7, 2019 at 10:30 AM Romain Manni-Bucau < > rmannibu...@gmail.com> > > wrote: > > > > > Hi all > > > > > > What is the status of graph at commons - or apache if we have something > > > elsewhere? > > > > > > I found in sandbox that doc > > > > > > > > > https://commons.apache.org/sandbox/commons-graph/apidocs/org/apache/commons/graph/DirectedGraph.html > > > , > > > but wonder if we have something live and if not why it failed. > > > > > > My rational is I started to write some DAG modelization and tooling > > > (backward browsing in my case) but I see it could be generic so wonder > if > > > it is worse thinking about commons or incubator of if scope is too > small > > > for that and keeping it specific is saner. > > > > > > Anyone has some pointers? > > > > > > -- > > > > > > --- > > Marco Neumann > > KONA > > > > -- > > > > > > --- > > Marco Neumann > > KONA > > > -- --- Marco Neumann KONA --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
