No, the cleanup of the java 9 classes is bound to the compile step. Therefore, you don’t need to do a clean first. That would have been very aggravating.
> On May 18, 2017, at 11:38 AM, Ralph Goers <rgo...@apache.org> wrote: > > Yes, I had to do something similar. But this is fragile if you don’t always > do a clean or explicitly include a clean step that runs to clean up those > items even if you didn’t specify it. > > Ralph > >> On May 18, 2017, at 7:20 AM, Russell Gold <russell.g...@oracle.com >> <mailto:russell.g...@oracle.com>> wrote: >> >> Maven support and tool support in general for MR Jars is very poor at the >> moment - including the bundle plugin. I do have a working example >> <https://github.com/javaee/gmbal-pfl/blob/master/pfl-basic/pom.xml> you >> could look at that includes OSGi support. The key here is that I delete the >> java9 classes before computing the OSGi manifest, and only compile them >> before building the jar. >> >> Russ >> >>> On May 17, 2017, at 11:28 PM, Ralph Goers <rgo...@apache.org >>> <mailto:rgo...@apache.org>> wrote: >>> >>> I am afraid I have to echo these sentiments to some degree. In trying to >>> get Log4j to support Java 9 I first tried to use a multi-release jar. This >>> failed miserably when the OSGi build tool failed over finding java classes >>> under META-INF. Then it proceeded to complain about the module-info.java >>> files. Why these are java syntax instead of json or something more sensible >>> for something that only contains declarations is a mystery to me. FWIW - >>> the OSGi people don’t seem interested in supporting these new features - >>> https://issues.apache.org/jira/browse/FELIX-5592 >>> <https://issues.apache.org/jira/browse/FELIX-5592> >>> <https://issues.apache.org/jira/browse/FELIX-5592 >>> <https://issues.apache.org/jira/browse/FELIX-5592>>. >>> >>> I have been able to work around some of these issues but it has made the >>> Log4j build very fragile and I haven’t really begun to see what happens >>> when log4j is actually modularized or runs in an application that is. >>> >>> Ralph >>> >>>> On May 17, 2017, at 10:26 AM, Eric Johnson <e...@tibco.com >>>> <mailto:e...@tibco.com>> wrote: >>>> >>>> On Wed, May 17, 2017 at 1:08 AM, Andrew Dinn <ad...@redhat.com >>>> <mailto:ad...@redhat.com>> wrote: >>>> >>>>> On 16/05/17 19:11, Gregg Wonderly wrote: >>>>> >>>>> <ad cohortem hominum snipped (pardon my French)> >>>>> >>>>>> If we really cannot actually keep from breaking 90% of existing Java >>>>>> in the market place when this new JDK release goes out, how valuable >>>>>> is JigSaw really? >>>>> >>>>> citation needed? >>>>> >>>> >>>> I mostly ignore jigsaw, and check in every now and then. >>>> >>>> I have a few co-workers that have poked at migrating their products to Java >>>> 9. So far as I know, nobody has succeeded yet. >>>> >>>> With significant regularity, I see issues pop up on this list that have odd >>>> problems, or persist in being unresolved. One of my favorites at the moment >>>> is automatic module names - a problem that Jigsaw caused for itself. Maybe >>>> that one is resolved for now, but I'm pretty certain that questions will >>>> come flooding back once Java 9 GAs. >>>> >>>> As near as I can tell, applications that compile and run under Java 8 will >>>> mostly *not* "just work" with Java 9 JRE. And that seems to be the lived >>>> experience of my co-workers. If a project is lucky, the only changes >>>> necessary will involve command line parameters. If a team is unlucky, they >>>> will need to rebuild for Java 9. If a team is really unlucky, they will >>>> need to partially or fully modularize. At which point some even more >>>> juggling is required to continue to support Java 7 & 8, if that's required >>>> by customers. >>>> >>>> My overall concerns for Jigsaw: >>>> https://medium.com/@one.eric.johnson/java-9-jigsaw-troubles-4fc406ef41e0 >>>> <https://medium.com/@one.eric.johnson/java-9-jigsaw-troubles-4fc406ef41e0> >>>> >>>> I'm not sure what citations you expect to see. There's probably nobody out >>>> there who can afford to pre-flight an EA build of Java 9 against all their >>>> products to see what the actual costs are going to be. Based on anecdotal >>>> evidence from this mailing list, significant players in the Java ecosystem >>>> - build tools, IDEs, critical libraries - have all had to fix unexpected >>>> breakages with Java 9. Obviously, the ones that don't break don't typically >>>> show up, so this is a self-selecting example, but an important one. >>>> >>>> However, even something as simple as requiring changes to command line >>>> parameters in order to launch a program compiled for Java 8 is a breaking >>>> change. The Jigsaw team seems to be taking this as a mere complaint, rather >>>> than as a genuine compatibility issue. >>>> >>>> Here's a challenge back to the Jigsaw team. Can I still do java -jar ... >>>> every existing Java application (without recompile!) that currently >>>> launches that way? I'm even willing to cut some slack and ignore >>>> applications that use com.sun APIs that have been "private" for years. Will >>>> that still work? The Jigsaw community should be able to provide evidence >>>> that's still possible, not that we should be required to provide evidence >>>> that it isn't. >>>> >>>> Eric. >>>> >>>> >>>>> regards, >>>>> >>>>> >>>>> Andrew Dinn >>>>> ----------- >>>>> >>>> >>> >> >
