Yes longer term (and now we have moved to Java 7) it would be best to avoid dynamic class loading where possible and use the Java 7 ServiceLoader paradigm instead.
Some of the existing stuff is because of the existing module structure meaning that it is actually preferable to use the ARQ implementations over some things in Jena Core (e.g. readers and writers) but the module structure means Jena-Core can't guarantee the presence. We have talked about restructuring the modules longer term (I.e. Jena3) which would also resolve some of this kind of problem and avoid any need for ServiceLoader or dynamic class loading in places However there will likely still be some places where dynamic class loading would need to remain e.g. Jena assembler, use of java: URIs for extension functions because they are useful features Rob On 04/11/2014 09:54, "Minto van der Sluis" <mi...@xup.nl> wrote: >Hi, > >If I recall correctly it is required due Jena using dynamic class >loading (Class.forName). Doing a grep on my "not updated in a long time" >checkout reveals 38 occurrences. > >If Jena is considering to provide OSGi bundles maybe then reconsider >using an alternative for dynamic class loading. > >Regards, > >Minto > > > > >Reto Gmür schreef op 4-11-2014 14:32: >> Hi Stian, >> >> If I understood and remember correctly the problem are circular >> dependencies between jena artifacts and packages occurring in multiple >> jars. I'm sure Minto (CC) can tell you the reasons more. >> >> If providing OSGi bundles becomes part of Jena then maybe the root >> cause of requiring this rather ugly dynamic imports and split-packages >> can be addressed. This is likely to be beneficial to the overall design. >> >> Cheers, >> Reto >> >> On Tue, Nov 4, 2014 at 2:15 PM, Stian Soiland-Reyes >> <soiland-re...@cs.manchester.ac.uk >> <mailto:soiland-re...@cs.manchester.ac.uk>> wrote: >> >> Reto, what was the reason for why Clerezza made the >> clerezza.osgi.dynamicimport.pkg indirect properties? >> >> Not sure I quite get this property: >> >> >> >><clerezza.osgi.export>${clerezza.osgi.export.pkg}*;version=${pkgVersion}; >>-split-package:=merge-first >> </clerezza.osgi.export> >> >> >> >> >> On 4 November 2014 13:12, Stian Soiland-Reyes >> <soiland-re...@cs.manchester.ac.uk >> <mailto:soiland-re...@cs.manchester.ac.uk>> wrote: >> > If you found that splitting it up into different bundles works, >>then >> > perhaps we should not need to have any wrapping bundles at all, >>and >> > can just add the <packaging>bundle</packaging> stuff to the main >> > modules? >> > >> > >> > >> > On 4 November 2014 10:54, Reto Gmür <r...@apache.org >> <mailto:r...@apache.org>> wrote: >> >> Hi >> >> >> >> In the clerezza project we have been wrapping jena for a while >> as OSGi >> >> bundles. >> >> >> >> Recently it got split up into different bundles. The source >> (i.e. the poms) >> >> can be seen here: >> >> >> >> https://github.com/apache/clerezza/tree/master/ext >> >> >> >> Cheers, >> >> Reto >> >> >> >> On Sat, Nov 1, 2014 at 2:26 AM, Stian Soiland-Reyes < >> >> soiland-re...@cs.manchester.ac.uk >> <mailto:soiland-re...@cs.manchester.ac.uk>> wrote: >> >> >> >>> I would like to hear from your experience of a custom-wrapped >> bundle >> >>> what you decided to include or not. >> >>> >> >>> See my other email message in this thread.. >> >>> >> >>> Basically in short: >> >>> >> >>> >> >>> >> >>http://build.mygrid.org.uk/ci/job/jena-bundle/21/org.apache.jena$jena-osg >>i/ >> >>> >> >>> >> >>> >> >>http://repository.mygrid.org.uk/artifactory/ext-snapshot-local/org/apache >>/jena/jena-osgi/2.12.2-SNAPSHOT/ >> >>> >> >>> >> >>http://repository.mygrid.org.uk/artifactory/ext-snapshot-local/org/apache >>/jena/jena-parent/12-SNAPSHOT/ >> >>> >> >>> >> >>> >> >>> On 31 October 2014 13:27, Mark Feblowitz >> <markfeblow...@icloud.com <mailto:markfeblow...@icloud.com>> wrote: >> >>> > I’m an OSGi user, and have been using a custom-wrapped Jena >> OSGi bundle >> >>> for more than a year. >> >>> > >> >>> > I’d be happy to try it out. How would I do so? >> >>> > >> >>> > Mark >> >>> > >> >>> > >> >>> > >> >>> >> On Oct 31, 2014, at 6:56 AM, Andy Seaborne <a...@apache.org >> <mailto:a...@apache.org>> wrote: >> >>> >> >> >>> >> On 28/10/14 16:50, stain wrote: >> >>> >>> GitHub user stain opened a pull request: >> >>> >>> >> >>> >>> https://github.com/apache/jena/pull/10 >> >>> >>> >> >>> >>> Jena OSGi bundle >> >>> >>> >> >>> >>> Embedding core Jena modules in a single OSGi bundle. >> >>> >>> >> >>> >>> This works around classloader issues such as Jena's use >>of >> >>> `Class.forName()`, but does not yet support other OSGi bundles >> to easily >> >>> plug in 3rd party Jena implementations of say readers and >>writers. >> >>> >>> >> >>> >>> Modules included: >> >>> >>> * jena-core >> >>> >>> * jena-arq >> >>> >>> * jena-tdb >> >>> >>> * jena-sdb >> >>> >>> * jena-iri >> >>> >> >> >>> >> Having one bundle for Jena makes a lot of sense as we build >> and release >> >>> whole systems, so partial replacement of bits and pieces isn't >> >>> supported/encouraged anyway. Releases may change cross module >> >>> assumptions. Personally, I'd drop SDB from the included >> modules; it's >> >>> being made a maven-only module next time, and not in the >> distribution >> >>> binaries. >> >>> >> >> >>> >> What I'd really, really like is for this to be tested by >> other OSGi >> >>> users. As far as I know, none of the committers use OSGi >> day-to-day >> >>> (we/Epimorphics used to but when we looked at the >> costs/benefits we switch >> >>> to a simpler, service architecture style). >> >>> >> >> >>> >> Stain - what would you say to advertising this on users@ (and >> >>> dev@clerezza?) and seeing if we can get some user testing and >> validation? >> >>> >> >> >>> >> Andy >> >>> >> >> >>> >>> >> >>> >>> This OSGi bundle includes a dependency on the >> `httpclient-osgi` >> >>> and `httpcore-osgi` version. All other packages used are >> embeded within the >> >>> OSGi bundle, making them appear on a single classloader in OSGi. >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> You can merge this pull request into a Git repository by >> running: >> >>> >>> >> >>> >>> $ git pull https://github.com/stain/jena >>jena-osgi-bundle >> >>> >>> >> >>> >>> Alternatively you can review and apply these changes as >> the patch at: >> >>> >>> >> >>> >>> https://github.com/apache/jena/pull/10.patch >> >>> >>> >> >>> >>> To close this pull request, make a commit to your >> master/trunk branch >> >>> >>> with (at least) the following in the commit message: >> >>> >>> >> >>> >>> This closes #10 >> >>> >>> >> >>> >>> ---- >> >>> >>> commit 1957808b34a408bf0278cfb4017d6e7040eebabb >> >>> >>> Author: Stian Soiland-Reyes >> <soiland-re...@cs.manchester.ac.uk >> <mailto:soiland-re...@cs.manchester.ac.uk>> >> >>> >>> Date: 2014-10-28T16:03:15Z >> >>> >>> >> >>> >>> pom tweaks so it builds >> >>> >>> >> >>> >>> .. also a spelling mistake tixed >> >>> >>> >> >>> >>> commit 5724c31d542d7c8ddf89c4333fbe4809d7783f49 >> >>> >>> Author: Stian Soiland-Reyes >> <soiland-re...@cs.manchester.ac.uk >> <mailto:soiland-re...@cs.manchester.ac.uk>> >> >>> >>> Date: 2014-10-28T16:34:59Z >> >>> >>> >> >>> >>> Embedding all Jena modules in a single OSGi bundle. >> >>> >>> >> >>> >>> commit 3bb12d0a1472977cfcd51abf392683659bac1e4d >> >>> >>> Author: Stian Soiland-Reyes >> <soiland-re...@cs.manchester.ac.uk >> <mailto:soiland-re...@cs.manchester.ac.uk>> >> >>> >>> Date: 2014-10-28T16:38:00Z >> >>> >>> >> >>> >>> httpcore-osgi 4.2.5 >> >>> >>> >> >>> >>> commit aa705c9e3e4f3b4c58924e95aa223213358b08e3 >> >>> >>> Author: Stian Soiland-Reyes >> <soiland-re...@cs.manchester.ac.uk >> <mailto:soiland-re...@cs.manchester.ac.uk>> >> >>> >>> Date: 2014-10-28T16:42:48Z >> >>> >>> >> >>> >>> ver.* properties as in jena-parent >> >>> >>> >> >>> >>> TODO: Move these properties to jena-parent? >> >>> >>> >> >>> >>> ---- >> >>> >>> >> >>> >>> >> >>> >>> --- >> >>> >>> If your project is set up for it, you can reply to this >> email and have >> >>> your >> >>> >>> reply appear on GitHub as well. If your project does not >> have this >> >>> feature >> >>> >>> enabled and wishes so, or if the feature is enabled but >> not working, >> >>> please >> >>> >>> contact infrastructure at infrastruct...@apache.org >> <mailto:infrastruct...@apache.org> or file a JIRA >> >>> ticket >> >>> >>> with INFRA. >> >>> >>> --- >> >>> >>> >> >>> >> >> >>> > >> >>> >> >>> >> >>> >> >>> -- >> >>> Stian Soiland-Reyes, myGrid team >> >>> School of Computer Science >> >>> The University of Manchester >> >>> http://soiland-reyes.com/stian/work/ >> http://orcid.org/0000-0001-9842-9718 >> >>> >> > >> > >> > >> > -- >> > Stian Soiland-Reyes, myGrid team >> > School of Computer Science >> > The University of Manchester >> > http://soiland-reyes.com/stian/work/ >> http://orcid.org/0000-0001-9842-9718 >> >> >> >> -- >> Stian Soiland-Reyes, myGrid team >> School of Computer Science >> The University of Manchester >> http://soiland-reyes.com/stian/work/ >> http://orcid.org/0000-0001-9842-9718 >> >> > > >-- >ir. ing. Minto van der Sluis >Software innovator / renovator >Xup BV > >Mobiel: +31 (0) 626 014541 >
