So spring and other scanners scan classes under /META-INF/versions/... i was unaware of that. So probably need a major version bump then, so it indicates a major change, so that consumers treat it as such and test it.
On Sun, 1 Mar 2020 at 17:11, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > > Le dim. 1 mars 2020 à 18:00, John Patrick <nhoj.patr...@gmail.com> a écrit : > > > Romain, The 4 commons projects I'm referring to already have > > Automatic-Module-Name in the Manifest, if that is what you mean by > > "explicit module name in the manifest". > > > > I've been playing around with jdk 1.8, 9, 10, 11, 12, 13 and 14, for > > about 18 months and not seen the issue you described about needing > > module-info being in the jar root. > > > > Regarding jpms classifier, I don't think that will help transitive > > dependency, so A project depending upon collections which depends upon > > codec. So will collections depend upon codec or codec-jpms. From what > > I've got working I can add module-info without breaking pre java 11 > > users. > > > > Test in j8 apps which didnt upgrade their scanner (spring, xbean, > reflections, asm and friends, all have version limited to java 8 and not > multirelease friendly), all are broken and it is one reason why adding > .class with bytecode version > java 8 is very risky while java 8 apps are > maintained (and we are still at ~50% of java 8 apps in prod today). > Best case it requires to upgrade these libs...so all the stack too which is > not always desired to upgrade a commons dep, worse case there is to upgrade > possible so dep is forked or dropped. > Indeed you dont see it in plain javase but commons being "commons", we must > consider this common case too IMHO. > > > > Peter, I'm trying to do as smaller change as possible to add > > module-info, and also only using core maven plugins > > > > Commons Developers, I'll start raising jira tickets per project, per step. > > > > John > > > > > > > > John > > > > On Sun, 1 Mar 2020 at 11:44, Peter Verhas <pe...@verhas.com> wrote: > > > > > > I used Jabel, and Maven profiles to generate jvm8 and also jvm11 jars in > > > the Java::Geci project. > > > > > > I also wrote a document about what, why, and how I did it: > > > > > > > > > https://javax0.wordpress.com/2019/11/06/supporting-java-8/ > > > > > > It may help. > > > > > > Peter > > > > > > > > > On Sun, 1 Mar 2020 at 12:38, Romain Manni-Bucau <rmannibu...@gmail.com> > > > wrote: > > > > > > > Hi John, > > > > > > > > Didnt check on java 11 ga but in early versions module-info was > > required to > > > > be at the root of the jar even if overriden for some version ( > > > > http://openjdk.java.net/jeps/238) so it ends up in the fact that some > > java > > > > 8 apps will be broken by this addition and that only doing it in a mjar > > > > will lead to the same kind of issues + will be likely ignored for other > > > > apps. > > > > > > > > What about doing classified jar "jpms" at the same time than current > > > > default jar to propose jpms integration early (worse case)? > > > > > > > > Alternative to just have an explicit module name in the manifest but no > > > > module-info also sounds safer to me and still enables to use jpms. > > > > > > > > Hope it makes sense. > > > > > > > > Le dim. 1 mars 2020 à 12:08, John Patrick <nhoj.patr...@gmail.com> a > > > > écrit : > > > > > > > > > I'm wanting to correctly use Collections and Lang as Java Modules. > > > > > > > > > > Looking at the dependencies, I'll need to tackle all four projects. > > > > > > > > > > I'm planning on doing the following as if I'm touching the projects I > > > > > might as well help out; > > > > > 1) spring clean .gitignore, each project has different list, some > > > > > documented others not > > > > > 2) update to hamcrest v2.2 > > > > > 3) update to junit v5.6 (jupiter and vintage) > > > > > 4) tackle low hanging fruit tests that can quickly be moved to > > jupiter > > > > > 5) update maven-dependencies to latest for compiler, jar, install > > > > > 6) discuss how toolchain should be setup for build tools have access > > > > > to jdk 1.8 and jdk 11, ideally the same pattern/approach for all > > > > > commons projects > > > > > 7) add src/main/java11/module-info.java > > > > > 8) add toolchain plugin and update compiler plugin to make Multi > > Release > > > > > jar > > > > > > > > > > my questions are; > > > > > a) how many jira tickets? one pre project? one per task/pr? > > > > > b) prepare into new release i.e. commons-collection5 > > > > > c) should i do all my pom changes to a parent pom? > > > > > d) toolchains developers, how should I document the requirement for > > > > > developers want to build locally, give example which they need to > > > > > complete > > > > > e) toolchains cicd, how should i set that up? i'm use to jenkins and > > > > > circle ci, not travis or gitflow? > > > > > > > > > > I'm doing this for other open source projects and work projects, but > > > > > can't finish the open source or work projects until the open source > > > > > dependency projects get fixed. Updating these 4 commons project will > > > > > unblock about 10 downstream pr's i'm working on. > > > > > > > > > > I don't want to break backwards compatibility so don't want to just > > > > > update to jdk 11, that is why I'm suggesting to use multi release > > > > > jars, so module-info.java is in META-INF/versions/11/module-info.jar. > > > > > I don't want to add new features, I just want the module-info so if > > > > > you are using a newer jdk you can use modules. > > > > > > > > > > John > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > -- > > > Peter Verhas > > > pe...@verhas.com > > > t: +41791542095 > > > skype: verhas > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
