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* <http://www.osgi.org/>* > **[email protected]* <[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]*<[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]*<[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]* <[email protected]>> > <ecblank.gif> > To: <ecblank.gif> > > OSGi Developer Mail List <*[email protected]*<[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]*<[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* <http://www.osgi.org/>* > **[email protected]* <[email protected]> > > office: *+1 386 848 1781* <%2B1%20386%20848%201781> > mobile: *+1 386 848 3788* <%2B1%20386%20848%203788> > > > > > > > > From: Raymond Auge > <*[email protected]*<[email protected]> > > > To: OSGi Developer Mail List > <*[email protected]*<[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]*<[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 > *<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* > **[email protected]* <[email protected]>* > **https://mail.osgi.org/mailman/listinfo/osgi-dev*<https://mail.osgi.org/mailman/listinfo/osgi-dev> > > > > > > > > > > > _______________________________________________ > OSGi Developer Mail List* > **[email protected]* <[email protected]>* > **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* > **[email protected]* <[email protected]>* > **https://mail.osgi.org/mailman/listinfo/osgi-dev*<https://mail.osgi.org/mailman/listinfo/osgi-dev> > > > > > > _______________________________________________ > OSGi Developer Mail List* > **[email protected]* <[email protected]>* > **https://mail.osgi.org/mailman/listinfo/osgi-dev*<https://mail.osgi.org/mailman/listinfo/osgi-dev> > > > > _______________________________________________ > OSGi Developer Mail List* > **[email protected]* <[email protected]>* > **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* > **[email protected]* <[email protected]>* > **https://mail.osgi.org/mailman/listinfo/osgi-dev*<https://mail.osgi.org/mailman/listinfo/osgi-dev> > > > _______________________________________________ > OSGi Developer Mail List* > **[email protected]* <[email protected]>* > **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 > [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é* <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 [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
