> 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
