Hi Raymond, I didn't have much time in "reviewing" it, but if you look for a cool place to donate it to, on place would be OPS4j [1]. I'm sure it would fit in there.
regards, Achim [1] - http://team.ops4j.org/wiki/display/ops4j/Open+Participation+Software+for+Java 2012/9/16 Raymond Auge <raymond.a...@liferay.com> > Ok, so I've returned with some new insights. > > I have still found that there are limitations to what's currently out > there, including jdt. > > The underlying assumption for runtime compilation (including jdt) is that > construction of the classpath would be done by directly introspecting jars > and/or classes in the file system as well as none of the implementations I > found were OSGi aware in any way. > > Compilations completed under this assumption would be left to fail during > execution because such a classpath would have access to resources not > available at runtime, such as the packages of a dependency not listed in > the imports of the calling bundle. > > However, I was able to create a very tiny implementation that is fully > OSGi aware whose only dependency is on osgi.core 4.3 which works within > proper runtime constraints without doing any nasty jar reading, resource > parsing (well some tiny reasonable bit), file system access or anything > like that. > > I'd like to submit the *phidias* project for your review, and I'm > wondering if one of the major OSGi implementation communities would be > interested in this as a donation. > > https://github.com/rotty3000/phidias > > It's a well formed OSGi > bundle<https://github.com/downloads/rotty3000/phidias/org.phidias.compile-0.1.2.jar> > . > The readme > <https://github.com/rotty3000/phidias/blob/master/README.md>provides all the > details of the very tiny 4 class API (8k module). > > I still have to add support for capturing resulting bytecode for storing > in memory as the jasper Jsr199JavaCompiler does. > > Sincerely, > - Ray > > > On Fri, Sep 14, 2012 at 2:30 PM, Raymond Auge <raymond.a...@liferay.com>wrote: > >> Alright then! >> >> Thanks All, >> - Ray >> >> >> On Fri, Sep 14, 2012 at 2:17 PM, BJ Hargrave <hargr...@us.ibm.com> wrote: >> >>> > OSGi has done this for many other limited parts of Java, JDBC, >>> Protocol handlers, etc. >>> >>> >>> Yes, but those are things commonly used by programmers. The java >>> compiler is not commonly used. There are only a few specialized needs such >>> as JSP compiling. So there is not a lot of benefit in specifying how to do >>> something when there are only 2 compilers around (java and jdt) and few >>> people actually needing to use the compiler. >>> >>> -- >>> >>> *BJ Hargrave* >>> Senior Technical Staff Member, IBM >>> OSGi Fellow and CTO of the *OSGi Alliance* <http://www.osgi.org/>* >>> **hargr...@us.ibm.com* <hargr...@us.ibm.com> >>> >>> office: +1 386 848 1781 >>> mobile: +1 386 848 3788 >>> >>> >>> >>> >>> >>> >>> From: Raymond Auge <raymond.a...@liferay.com> >>> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>, >>> Date: 2012/09/14 12:28 >>> Subject: Re: [osgi-dev] best way to generate a classpath for >>> javax.tools.JavaCompiler >>> Sent by: osgi-dev-boun...@mail.osgi.org >>> ------------------------------ >>> >>> >>> >>> I'm not in any way trying to suggest that JDT is not an capable or >>> completely "viable" alternative. >>> >>> What I'm suggesting only is that where OSGi attempts to be "the >>> modularity framework for java" (which for the record I will argue is true >>> every time) some parts of Java don't work are work badly, javax.tools being >>> a case. >>> >>> Doesn't that leave a responsibility for the OSGi community to at least >>> make an attempt to address the shortcoming (whomever it belongs to)? >>> >>> OSGi has done this for many other limited parts of Java, JDBC, Protocol >>> handlers, etc. >>> >>> - Ray >>> >>> On Fri, Sep 14, 2012 at 11:41 AM, Felix Meschberger <*fmesc...@gmail.com >>> * <fmesc...@gmail.com>> wrote: >>> Hi, >>> >>> Am 14.09.2012 um 15:17 schrieb Raymond Auge: >>> >>> Ok, so I managed to get this working using JDT (as recommended & with a >>> little help from some pax/ops4j tools, thanks Achim for the suggestion). >>> >>> However, I'm left with the notion that there is seems to be an apparent >>> "understanding" that javax.tools doesn't play nice with OSGi and that >>> the general recommendation is "use jdt instead of javax.tools in OSGi". >>> >>> I don't buy into this. Basically you want to compile and have two (or >>> more) compilers to choose from to use. One compiler is easy to use the >>> other is harder to use. So you naturally go for the easier to use. >>> >>> >>> >>> Doesn't this sound like it might be a fairly restrictive limitation >>> considering the evolution of the Java platform toward more dynamic language >>> design? I would think that javax.tools might play a pretty large role >>> in this. >>> >>> I would assume the eclipse compiler, once Java Modularity comes and >>> requires compiler support, will also support it. So, nothing to fear here, >>> I would assume. But, of course, I cannot talk for the Eclipse community -- >>> but as a user of the Eclipse platform I would expect such support. >>> >>> >>> Isn't there something the OSGi community should be doing about this? >>> >>> a) write a spec to add support for it >>> b) petition the current spec to allow for injectable bytecode >>> resolution, thus enabling OSGi to be supported >>> c) something else... >>> >>> So, I'm no longer asking from the point of view "How to I solve my >>> immediate problem?" (Done!) >>> >>> Now I'm asking more as "I don't think the current recommendation is >>> actually the right solution. (C|Sh)ouldn't we make it better?" >>> >>> Why ? Along with what I said above, I don't really agree to the >>> recommended solution to not be the right one. >>> >>> >>> Something like (I'm not really sure if this is possible or if there is >>> a deeper limitation in javax.tools): >>> >>> javax.tools.JavaCompiler javaCompiler = >>> ToolProvider.getSystemJavaCompiler(); >>> StandardJavaFileManager >>> standardFileManager = javaCompiler.getStandardFileManager(...); >>> JavaBundleManager javaBundleManager >>> = bundle.adapt(JavaBundleManager.class); >>> javaBundleManager.someMergeOperationOrWhatever(standardFileManager); >>> javax.tools.JavaCompiler.CompilationTask ct >>> = javaCompiler.getTask(.., javaBundleManager, ..); >>> >>> I don't know the javax.tools.JavaCompiler stuff and so can't comment on >>> how this could be done there... >>> >>> Regards >>> Felix >>> >>> >>> >>> Sincerely, >>> - Ray >>> >>> >>> On Fri, Sep 14, 2012 at 8:27 AM, Thomas Watson >>> <*tjwat...@us.ibm.com*<tjwat...@us.ibm.com>> >>> wrote: >>> We also do a similar thing in Equinox for jsp support. >>> >>> Tom >>> >>> >>> >>> <graycol.gif>Felix Meschberger ---09/14/2012 06:37:05 AM---Hi, Am >>> 13.09.2012 um 17:01 schrieb Raymond Auge: >>> >>> <ecblank.gif> >>> From: <ecblank.gif> >>> Felix Meschberger <*fmesc...@gmail.com* <fmesc...@gmail.com>> >>> <ecblank.gif> >>> To: <ecblank.gif> >>> >>> OSGi Developer Mail List <*osgi-dev@mail.osgi.org*<osgi-dev@mail.osgi.org>>, >>> <ecblank.gif> >>> Date: <ecblank.gif> >>> 09/14/2012 06:37 AM <ecblank.gif> >>> Subject: <ecblank.gif> >>> >>> Re: [osgi-dev] best way to generate a classpath for >>> javax.tools.JavaCompiler >>> ------------------------------ >>> >>> >>> >>> >>> Hi, >>> >>> Am 13.09.2012 um 17:01 schrieb Raymond Auge: >>> No, in fact the root problem is trying to do is use jasper to compile >>> JSPs in OSGi. >>> >>> In the Apache Sling project we embed the Eclipse compiler for compiling >>> JSPs since this is much easier to embedd and use in the OSGi context. >>> Particularly with respect to the class path: the compiler just asks a >>> helper class for classes and doesn't care, where these come from. >>> >>> Regards >>> Felix >>> >>> However, I seem to have once again missed some facts about how this is >>> setup, so ignore this for now. If I actually find a problem I'll come back >>> to it. >>> >>> Thanks and sorry for the noise. >>> >>> - Ray >>> >>> >>> On Thu, Sep 13, 2012 at 10:45 AM, BJ Hargrave >>> <*hargr...@us.ibm.com*<hargr...@us.ibm.com>> >>> wrote: >>> I don't understand the question? Are you trying to package tools.jar as >>> a bundle? >>> >>> -- >>> *BJ Hargrave* >>> Senior Technical Staff Member, IBM >>> OSGi Fellow and CTO of the *OSGi Alliance* <http://www.osgi.org/>* >>> **hargr...@us.ibm.com* <hargr...@us.ibm.com> >>> >>> office: *+1 386 848 1781* <%2B1%20386%20848%201781> >>> mobile: *+1 386 848 3788* <%2B1%20386%20848%203788> >>> >>> >>> >>> >>> >>> >>> >>> From: Raymond Auge >>> <*raymond.a...@liferay.com*<raymond.a...@liferay.com> >>> > >>> To: OSGi Developer Mail List >>> <*osgi-dev@mail.osgi.org*<osgi-dev@mail.osgi.org>>, >>> >>> Date: 2012/09/13 10:41 >>> Subject: [osgi-dev] best way to generate a classpath for >>> javax.tools.JavaCompiler >>> Sent by: >>> *osgi-dev-boun...@mail.osgi.org*<osgi-dev-boun...@mail.osgi.org> >>> >>> ------------------------------ >>> >>> >>> >>> >>> Hey all, >>> >>> Is there a definitive way to create a classpath for >>> javax.tools.JavaCompiler in OSGi? >>> >>> I've asked the same here: * >>> >>> ** >>> http://stackoverflow.com/questions/12408624/the-definitive-way-to-generate-a-classpath-for-javax-tools-javacompiler-in-osgi >>> *<http://stackoverflow.com/questions/12408624/the-definitive-way-to-generate-a-classpath-for-javax-tools-javacompiler-in-osgi> >>> >>> >>> i.e. does this exist or need to be specified and then implemented? >>> >>> -- * >>> **Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>> <http://twitter.com/#!/rotty3000> | >>> Senior Software Architect | *Liferay, Inc.* <http://www.liferay.com/> >>> <https://twitter.com/#!/liferay> >>> >>> --- >>> >>> >>> 8-9 October 2012 |* Liferay **North America Symposium* | * >>> liferay.com/northamerica2012* <http://www.liferay.com/northamerica2012> >>> >>> 16-17 October 2012 |* Liferay **Europe Symposium* | * >>> liferay.com/europe2012* <http://www.liferay.com/europe2012> >>> >>> 24-25 October 2012 |* Liferay **Spain Symposium* | * >>> liferay.com/spain2012* <http://www.liferay.com/spain2012> >>> >>> _______________________________________________ >>> OSGi Developer Mail List* >>> **osgi-dev@mail.osgi.org* <osgi-dev@mail.osgi.org>* >>> **https://mail.osgi.org/mailman/listinfo/osgi-dev*<https://mail.osgi.org/mailman/listinfo/osgi-dev> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> OSGi Developer Mail List* >>> **osgi-dev@mail.osgi.org* <osgi-dev@mail.osgi.org>* >>> **https://mail.osgi.org/mailman/listinfo/osgi-dev*<https://mail.osgi.org/mailman/listinfo/osgi-dev> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>> <http://twitter.com/#!/rotty3000> | >>> Senior Software Architect | *Liferay, Inc.* <http://www.liferay.com/> >>> <https://twitter.com/#!/liferay> >>> >>> --- >>> >>> 8-9 October 2012 |* Liferay **North America Symposium* | * >>> liferay.com/northamerica2012* <http://www.liferay.com/northamerica2012> >>> >>> 16-17 October 2012 |* Liferay **Europe Symposium* | * >>> liferay.com/europe2012* <http://www.liferay.com/europe2012> >>> >>> 24-25 October 2012 |* Liferay **Spain Symposium* | * >>> liferay.com/spain2012* <http://www.liferay.com/spain2012> >>> >>> >>> >>> >>> _______________________________________________ >>> OSGi Developer Mail List* >>> **osgi-dev@mail.osgi.org* <osgi-dev@mail.osgi.org>* >>> **https://mail.osgi.org/mailman/listinfo/osgi-dev*<https://mail.osgi.org/mailman/listinfo/osgi-dev> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> OSGi Developer Mail List* >>> **osgi-dev@mail.osgi.org* <osgi-dev@mail.osgi.org>* >>> **https://mail.osgi.org/mailman/listinfo/osgi-dev*<https://mail.osgi.org/mailman/listinfo/osgi-dev> >>> >>> >>> >>> _______________________________________________ >>> OSGi Developer Mail List* >>> **osgi-dev@mail.osgi.org* <osgi-dev@mail.osgi.org>* >>> **https://mail.osgi.org/mailman/listinfo/osgi-dev*<https://mail.osgi.org/mailman/listinfo/osgi-dev> >>> >>> >>> >>> -- * >>> * >>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>> <http://twitter.com/#!/rotty3000> | Senior Software Architect | *Liferay, >>> Inc.* <http://www.liferay.com/> >>> <https://twitter.com/#!/liferay> >>> >>> --- >>> >>> 8-9 October 2012 |* Liferay **North America Symposium* | * >>> liferay.com/northamerica2012* <http://www.liferay.com/northamerica2012> >>> >>> 16-17 October 2012 |* Liferay **Europe Symposium* | * >>> liferay.com/europe2012* <http://www.liferay.com/europe2012> >>> >>> 24-25 October 2012 |* Liferay **Spain Symposium* | * >>> liferay.com/spain2012* <http://www.liferay.com/spain2012> >>> >>> >>> >>> >>> _______________________________________________ >>> OSGi Developer Mail List* >>> **osgi-dev@mail.osgi.org* <osgi-dev@mail.osgi.org>* >>> **https://mail.osgi.org/mailman/listinfo/osgi-dev*<https://mail.osgi.org/mailman/listinfo/osgi-dev> >>> >>> >>> _______________________________________________ >>> OSGi Developer Mail List* >>> **osgi-dev@mail.osgi.org* <osgi-dev@mail.osgi.org>* >>> **https://mail.osgi.org/mailman/listinfo/osgi-dev*<https://mail.osgi.org/mailman/listinfo/osgi-dev> >>> >>> >>> >>> -- * >>> **Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>> <http://twitter.com/#!/rotty3000> | Senior Software Architect | *Liferay, >>> Inc.* <http://www.liferay.com/> <https://twitter.com/#!/liferay> >>> >>> --- >>> >>> 8-9 October 2012 |* Liferay **North America Symposium* | * >>> liferay.com/northamerica2012* <http://www.liferay.com/northamerica2012> >>> >>> 16-17 October 2012 |* Liferay **Europe Symposium* | * >>> liferay.com/europe2012* <http://www.liferay.com/europe2012> >>> >>> 24-25 October 2012 |* Liferay **Spain Symposium* | * >>> liferay.com/spain2012* <http://www.liferay.com/spain2012> >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> osgi-dev@mail.osgi.org >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> osgi-dev@mail.osgi.org >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >> >> >> >> -- >> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >> <http://twitter.com/#!/rotty3000> | Senior Software Architect | *Liferay, >> Inc.* <http://www.liferay.com> <https://twitter.com/#!/liferay> >> >> --- >> >> 8-9 October 2012 |* Liferay **North America Symposium* | >> liferay.com/northamerica2012 <http://www.liferay.com/northamerica2012> >> >> 16-17 October 2012 |* Liferay **Europe Symposium* | >> liferay.com/europe2012 <http://www.liferay.com/europe2012> >> >> 24-25 October 2012 |* Liferay **Spain Symposium* | >> liferay.com/spain2012<http://www.liferay.com/spain2012> >> >> >> > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > <http://twitter.com/#!/rotty3000> | Senior Software Architect | *Liferay, > Inc.* <http://www.liferay.com> <https://twitter.com/#!/liferay> > > --- > > 8-9 October 2012 |* Liferay **North America Symposium* | > liferay.com/northamerica2012 <http://www.liferay.com/northamerica2012> > > 16-17 October 2012 |* Liferay **Europe Symposium* | > liferay.com/europe2012<http://www.liferay.com/europe2012> > > 24-25 October 2012 |* Liferay **Spain Symposium* | > liferay.com/spain2012<http://www.liferay.com/spain2012> > > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project Lead blog <http://notizblog.nierbeck.de/>
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
