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> 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 >>>> ----------- >>>> >>> >> >
