Hi Am 16.09.2012 um 22:29 schrieb Raymond Auge:
> 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. I don't know how you come to that conclusion -- particularly looking at how the Apache Sling JSP Compiler does it: We don't do JAR file inspection at all because we don't have those files ;-) > > 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. That's true of all compilations which is why bundles import and be wired. Now for dynamically generated classes, there is no bundle to run in (generally). So in Apache Sling (I can only speak for that project) we have a class loader provider which knows about the provided packages in the framework and is able to provide classes to the running JSPs (in our case). If a class happens to be missing at one point in time after compilation, so be it. The JSP fails -- there is nothin much we can do... > > 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. I am not sure, whether the OSGi dev list is the appropriate forum to offer contributions to communities. Rather I suggest to approach the respective communities (Apache Felix, Apache Sling, Apache Aries or OPS4J or whoever) directly. As for the Apache projects, though, LGPL is not an acceptable license and you would have to relicense for contribution. > > https://github.com/rotty3000/phidias > > It's a well formed OSGi bundle. > The readme provides all the details of the very tiny 4 class API (8k module). Not counting tools.jar that needs to be redistributed, right ? We cannot expect the target platform to run the JDK. Regards Felix > > 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 <[email protected]> > wrote: > Alright then! > > Thanks All, > - Ray > > > On Fri, Sep 14, 2012 at 2:17 PM, BJ Hargrave <[email protected]> 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 > [email protected] > > office: +1 386 848 1781 > mobile: +1 386 848 3788 > > > > > > > From: Raymond Auge <[email protected]> > To: OSGi Developer Mail List <[email protected]>, > Date: 2012/09/14 12:28 > Subject: Re: [osgi-dev] best way to generate a classpath for > javax.tools.JavaCompiler > Sent by: [email protected] > > > > 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> > <ecblank.gif> > To: <ecblank.gif> > > OSGi Developer Mail List <[email protected]>, > <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 <[email protected]> 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 > [email protected] > > office: +1 386 848 1781 > mobile: +1 386 848 3788 > > > > > > > > From: Raymond Auge <[email protected]> > To: OSGi Developer Mail List <[email protected]>, > Date: 2012/09/13 10:41 > Subject: [osgi-dev] best way to generate a classpath for > javax.tools.JavaCompiler > Sent by: [email protected] > > > > > 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 > > > i.e. does this exist or need to be specified and then implemented? > > -- > Raymond Augé | Senior Software Architect | Liferay, Inc. > --- > > > > 8-9 October 2012 | Liferay North America Symposium | > liferay.com/northamerica2012 > > 16-17 October 2012 | Liferay Europe Symposium | liferay.com/europe2012 > > 24-25 October 2012 | Liferay Spain Symposium | liferay.com/spain2012 > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > > > > > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > > > > > -- > Raymond Augé | Senior Software Architect | Liferay, Inc. > --- > > > 8-9 October 2012 | Liferay North America Symposium | > liferay.com/northamerica2012 > > 16-17 October 2012 | Liferay Europe Symposium | liferay.com/europe2012 > > 24-25 October 2012 | Liferay Spain Symposium | liferay.com/spain2012 > > > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > -- > Raymond Augé | Senior Software Architect | Liferay, Inc. > --- > > 8-9 October 2012 | Liferay North America Symposium | > liferay.com/northamerica2012 > > 16-17 October 2012 | Liferay Europe Symposium | liferay.com/europe2012 > > 24-25 October 2012 | Liferay Spain Symposium | liferay.com/spain2012 > > > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > -- > Raymond Augé | Senior Software Architect | Liferay, Inc. > > --- > > 8-9 October 2012 | Liferay North America Symposium | > liferay.com/northamerica2012 > > 16-17 October 2012 | Liferay Europe Symposium | liferay.com/europe2012 > > 24-25 October 2012 | Liferay Spain Symposium | liferay.com/spain2012 > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > -- > Raymond Augé | Senior Software Architect | Liferay, Inc. > --- > > 8-9 October 2012 | Liferay North America Symposium | > liferay.com/northamerica2012 > > 16-17 October 2012 | Liferay Europe Symposium | liferay.com/europe2012 > > 24-25 October 2012 | Liferay Spain Symposium | liferay.com/spain2012 > > > > > > > > -- > Raymond Augé | Senior Software Architect | Liferay, Inc. > --- > > 8-9 October 2012 | Liferay North America Symposium | > liferay.com/northamerica2012 > > 16-17 October 2012 | Liferay Europe Symposium | liferay.com/europe2012 > > 24-25 October 2012 | Liferay Spain Symposium | liferay.com/spain2012 > > > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
