On Thu, Mar 8, 2018 at 10:01 AM, ajs6f <aj...@apache.org> wrote: > > On Mar 8, 2018, at 8:33 AM, Gilles <gil...@harfang.homelinux.org> wrote: > > Would it be useful (and interesting as part of GSoC work) to > > establish > > (1) which tools requires fixing, > > (2) prepare enhancement requests for the respective projects, > > and in the meantime, adapt the "Commons" build (with a "JDK 9" > > profile) > > (3) to disable plugins that do not work yet, > > (4) provide the option to generate a "multi-release" JAR (although > > it would not be the deployed as part of the official release > > process)? > > Hi, this is Adam Soroka (prospective mentor for this project). I'm sorry > to have been absent from this conversation so far (been very busy this > week) but Gilles has said much of what I would have said, so thanks Gilles! > > I would emphasize a couple of points: > > This is a GSoC project. The expectations and the marks of success are > fundamentally different than for many other contributions. > > Gilles has rightly pointed out that this is about Commons RDF and that is > all. Kamila unfortunately didn't make that clear in the subject line of the > thread, but that was just a slip of the keyboard. It's not about any other > piece of Commons. It won't affect them, so there's no need to worry about > how release artifacts or other products for other components might be > affected. They won't be. > > I don't think anyone would claim (or has claimed) that Commons (or any > Commons component) should target Java9. The idea here is to work with the > JPMS. There is no obvious or sensible way to do that without using Java9. > > The tasks that Kamila and Gilles have talked about are (IMHO) sensible and > useful. We can discuss how soon and in what way Commons as a whole should > engage with JPMS, but I don't see why that should stop individual > components from exploring it. In fact, as Gilles points out, that will be a > useful way of gathering info for a larger set of efforts. > > Lastly, on the assumption that Kamila's work involves a lot of "well, > plugin X doesn't work, so I'll have to talk to that project", we are doing > good. That is _EXACTLY_ what should happen during a GSoC project. The > student should be discovering that working on open source software is often > (I would say _very_ often) just as much about understanding how different > software projects and communities relate to each other and how to get > efforts synchronized than about just banging out line after line of code in > isolation, only to throw the results over a fence to a single project. > > In summary-- this proposed project shouldn't affect anything or -one > outside of the user base of Commons RDF (which hasn't even reached 1.0), > and it may only result in a lot of documentation and "speculative" work, > and that would be fine, as long as Kamila learns a lot about working with > open source software efforts, which I'm confident she can and will. > > Adam Soroka ; aj...@apache.org
That's all quite nice but the hard reality is that the tool chains out there are simply not ready for JPMS, as I've painfully learned contributing to Log4j 2. MR Jars, module-infos, all of that breaks Maven plugins and tools left and right. So I do not see MR-jars as a viable options for any Commons Components at this time. The best we can do ATM is play with automatic module names in manifest files and look at what jdeps say about a given component and see if we want to only depend on java.base or create Maven modules to compartmentalize dependencies. Gary > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
