Re: plexus-utils 4.x and Xpp3DomBuilder
plexus-xml 3.0.0 released, compatible with Maven 3 Maven Archetype upgraded as a proof of work: https://issues.apache.org/jira/browse/ARCHETYPE-648 = upgrading plexus-utils 3 to plexus-utils 4 + plexus-xml 3 (when XML APIs required) is a breeze what has to be avoided is upgrading plexus-xml 3 to 4, as it breaks (for now) running your code in Maven 3 but requires Maven 4 Thanks for the feedback, this helped us clarify the plan Regards, Hervé Le dimanche 10 septembre 2023, 18:50:27 CEST Hervé Boutemy a écrit : > working on it, I created a branch for plexus-xml 3.x: > https://github.com/codehaus-plexus/plexus-xml/tree/3.x > > we should probably release such plexus-xml 3 that is the "normal" usual XML > code that we used for years, extracted from plexus-utils 3 > > plexus-xml 4 is currently only for Maven 4 > > > FYI, I tried to upgrade plexus-utils in a few Maven-maintained plugins > My findings are: > - many plugins use XML API, sometime just for Xpp3ParserException from Maven > core API, sometimes because they use Modello to read/write XML... > then we have many Maven-maintained plugins to test strategies > > - a few plugins don't use XML at all: in this case, upgrading plexus-utils > from 3 to 4 is feasible just now: > https://github.com/apache/maven-jarsigner-plugin/pull/12 > > Regards, > > Hervé > > Le dimanche 10 septembre 2023, 10:11:14 CEST Sylwester Lachiewicz a écrit : > > And looks like this apply not only to plugins but also to shared libs for > > maven (ASF also plexus and mojohous) > > > > Sylwester > > > > niedz., 10 wrz 2023, 09:00 użytkownik Hervé Boutemy > > > > > > napisał: > > > Le samedi 9 septembre 2023, 19:33:51 CEST Václav Haisman a écrit : > > > > On 25. 07. 23 20:56, Slawomir Jaranowski wrote: > > > > > Hi > > > > > > > > > > I'm trying to update plexus-utils 3.5.x to plexus-utils/plexus-xml > > > > > 4.x > > > > > > in > > > > > > > > maven-enforcer > > > > > > > > > > In maven-enforcer (and in many other plugins ...) is used, code like: > > > > > Xpp3Dom enforcerRules = > > > > > Xpp3DomBuilder.build(descriptorStream, > > > > > > > > > > "UTF-8"); > > > > > > > > > > Xpp3Dom and Xpp3DomBuilder - has new implementation in plexus-xml > > > > > > > > > > > but > > > > > > > > Maven 3.x exports > > > > > > > > > > > > > > > > org.codehaus.plexus.util.xml.Xpp3Dom > > > > > > > e> > > > > > > org.codehaus.plexus.util.xml.pull.XmlPullParser > > ed > > > > > > > > Package> > > > > > > org.codehaus.plexus.util.xml.pull.XmlPullParserExceptio > > > n< > > > > > > > > /exportedPackage> > > > > > > org.codehaus.plexus.util.xml.pull.XmlSerializer > > ed > > > > > > > > Package> > > > > > > > > > > It is very magical that we export classes but not export artifact > > > > > which contains those classes ... > > > > > > > > > > so incompatibilite code for Xpp3Dom is used ... > > > > > > > > > > Any hints on how to process it. > > > > > > > > So, what is the takeaway of this tread for casual Maven plugin > > > > developers like me? Should I avoid plexus-utils 4.x in Maven 3 > > > > plugins? > > > > > > more precisely: don't upgrade plexus-utils to 4 *if you need plexus-xml* > > > > > > our intent of splitting concerns between general non-XML utils vs XML is > > > a > > > success: upgrading plexus-utils will make clear which plugins > > > > > > but when you need XML details in your plugin = where Maven core has an > > > impact, > > > we are not clear yet on how to make the plexus xml update Maven 3 and 4 > > > compliant at the same time > > > > > > this thread needs to continue because we're not yet at the final > > > conclusion, > > > > > > but this intermediate small message can be used for now: > > > don't upgrade plexus-utils to 4 *if you need plexus-xml* > > > > > > Regards, > > > > > > Hervé > > > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: How to fix MNG-7855 (dependencies wrongly put on class-path rather than module-path)?
Hi, Le mar. 12 sept. 2023 à 09:16, Henning Schmiedehausen < henn...@schmiedehausen.org> a écrit : > I am not sure that we have to. I think that the discussion got derailed by > disagreement about the "automatic module name" entry in a jar. > > My interpretation of JEPS-261 is, that there are only two things: > > - JPMS modules, which have a module-info.class file at the root of the > implementation jar > - everything else, which are treated as "automatic modules". The entry in > the manifest controls the "automatically created name" for the module. But > they are fundamentally the same thing. > > So for running the build lifecycle, there is IMHO only: > > - if there is a module-info.java in any source root present, it is a JPMS > module. This should use the JPMS toolchain > This is an assumption and regularly not true, in particular when the build is not intended to use JPMS at runtime, the module should stick to classpath. > - Everything else gets treated like a "legacy" java build, independent of > whether there is an automatic module name set in the jar or not or what JDK > version is used to build the artifact > > Maven spends a lot of time trying to deal with corner cases and I am not > sure that we get them right. > AFAIK mainstream frameworks (spring, microprofile, jakarta) ignore by default JPMS (and most of their env do not even read module-info) so guess it stays the default today. > > -h > > > > > > On Sun, Sep 3, 2023 at 1:58 AM Martin Desruisseaux < > martin.desruisse...@geomatys.com> wrote: > > > Le 2023-09-02 à 21 h 15, Henning Schmiedehausen a écrit : > > > > > This is the piece that really makes me sad. We tend to get lost in > > > "rightness" discussions and don't show pragmatism. > > In this case we have an opinion-free, objective criterion: make possible > > to pass to Java tools (java, javac, javadoc…) command-line arguments > > that work for a JPMS application. Making that task easier would be a > > bonus, but at first at least make it possible. > > > > > > >> The most urgent one in my opinion is to give control to developers > > >> about class-path versus module-path decisions. > > > I tend to agree with this, however extending the pom model is most > > > likely not a viable option. > > Recent emails about Maven 4 made me think that POM changes may be > > possible. But anyway, no matter if POM changes are accepted or not, > > there is also a need for some global option for controlling the current > > algorithm. The reason is that even if POM changes were accepted, the > > current algorithm would still be the default applied when nothing is > > specified in the POM, and that default needs to be changed. > > > > Martin > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > >
Re: Remove / reset compileSourceRoots list?
On Sun, Sep 3, 2023 at 11:19 PM Guillaume Nodet wrote: > Le sam. 2 sept. 2023 à 08:16, Henning Schmiedehausen < > henn...@schmiedehausen.org> a écrit : > > > I have a mixed kotlin/java multi-module project that uses src/main/java > for > > the java code and src/main/kotlin for kotlin code. > > > > For the java-only projects, everything is fine. sourceDirectory points to > > src/main/java, testSourceDirectory points to src/test/java. > > > > We activate a specific profile that turns on the kotlin compiler if > > src/main/kotlin is present. For modules that have both kotlin and java > > code, this works fine as well. We add src/main/kotlin to the source roots > > and src/test/kotlin to the test roots (using the build-helper plugin). > > > > However, for kotlin-only projects (where no src/main/java and > src/test/java > > exists), we get a build warning: "Source root doesn't exist: > > .../src/main/java" (e.g. from the kotlin compiler). > > > > Why is the kotlin compiler given a pointer to a java source root ? > The java compiler has a property compileSourceRoots which defaults to the > project.compileSourceRoots but that can be overridden in such cases. > It seems the kotlin-maven-plugin has a sourceDirs property which you could > set to only the kotlin one. > Yes. It's complicated. Basically, for mixed source trees, the kotlin compiler needs to be able to read the java and the kotlin source files, otherwise you could not write kotlin code that references java code in the same module. See https://kotlinlang.org/docs/maven.html#compile-kotlin-and-java-sources for details. > > > > > > As we activate the compiler from a profile, we can not set the initial > > sourceDirectory or testSourceDirectory (overriding those values is not > > supported in a profile). > > > > Have you tried setting those values with properties and override the > properties in the profile ? > Oh, that is an interesting approach. I have not actually tried that. > > > > > > Is there a way to clear the list of source roots in the maven project? I > > looked into the code and what the build helper does and tried using > > project.getCompileSourceRoots().clear() which works only partially. > > > > Why partially ? > Because it works for a bit (it seems in the same lifecycle phase) and then a bit later, plugin execution has the old values (pre calling "clear()") again. There is some cloning of the project element somewhere, so the clear() call removes the directories from the cloned Project object but can not affect the actual source. > > > > > > Is there an official way to clear / set the list of compileSourceRoots > and > > testSourceRoots from a plugin that can be used from a profile? > > > > Not sure about that... ;-) > Thanks for looking into this. -h
Re: How to fix MNG-7855 (dependencies wrongly put on class-path rather than module-path)?
I am not sure that we have to. I think that the discussion got derailed by disagreement about the "automatic module name" entry in a jar. My interpretation of JEPS-261 is, that there are only two things: - JPMS modules, which have a module-info.class file at the root of the implementation jar - everything else, which are treated as "automatic modules". The entry in the manifest controls the "automatically created name" for the module. But they are fundamentally the same thing. So for running the build lifecycle, there is IMHO only: - if there is a module-info.java in any source root present, it is a JPMS module. This should use the JPMS toolchain - Everything else gets treated like a "legacy" java build, independent of whether there is an automatic module name set in the jar or not or what JDK version is used to build the artifact Maven spends a lot of time trying to deal with corner cases and I am not sure that we get them right. -h On Sun, Sep 3, 2023 at 1:58 AM Martin Desruisseaux < martin.desruisse...@geomatys.com> wrote: > Le 2023-09-02 à 21 h 15, Henning Schmiedehausen a écrit : > > > This is the piece that really makes me sad. We tend to get lost in > > "rightness" discussions and don't show pragmatism. > In this case we have an opinion-free, objective criterion: make possible > to pass to Java tools (java, javac, javadoc…) command-line arguments > that work for a JPMS application. Making that task easier would be a > bonus, but at first at least make it possible. > > > >> The most urgent one in my opinion is to give control to developers > >> about class-path versus module-path decisions. > > I tend to agree with this, however extending the pom model is most > > likely not a viable option. > Recent emails about Maven 4 made me think that POM changes may be > possible. But anyway, no matter if POM changes are accepted or not, > there is also a need for some global option for controlling the current > algorithm. The reason is that even if POM changes were accepted, the > current algorithm would still be the default applied when nothing is > specified in the POM, and that default needs to be changed. > > Martin > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
[ANN] Maven Resolver Ant Tasks 1.5.0 released
The Apache Maven team is pleased to announce the release of the Maven Resolver Ant Tasks 1.5.0 https://maven.apache.org/resolver-ant-tasks/ Release Notes - Maven Resolver - Version ant-tasks-1.5.0 ** Improvement * [MRESOLVER-402] - Properly expose resolver configuration * [MRESOLVER-403] - Support depMgt for transitive dependencies ** Task * [MRESOLVER-400] - Update to parent POM 40, reformat * [MRESOLVER-401] - Drop use of SL and deprecated stuff, up version to 1.5.0 ** Dependency upgrade * [MRESOLVER-343] - Upgrade ant to 1.10.13 * [MRESOLVER-344] - Upgrade Maven to 3.9.4, Resolver 1.9.15 Have fun, -The Apache Maven team
[RESULT] [VOTE] Maven Resolver Ant Tasks 1.5.0
Howdy, The vote has passed with the following result: +1: Michael, Herve, Slawomir PMC quorum: reached I will promote the source release zip file to the Apache distribution area and the artifacts to the central repo. T
