Re: plexus-utils 4.x and Xpp3DomBuilder
I think the decision to not export plexus-utils was taken some time ago. Unfortunately, the xml bits still have to be provided by the maven core class loader. I think in this case, Maven 3.9.x should also expose the builder class org.codehaus.plexus.util.xml.Xpp3DomBuilder I think this should work, but this would only solve the problem for the latest 3.9.x maven, not older versions. Le mar. 25 juil. 2023 à 20:56, Slawomir Jaranowski a écrit : > 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 > > > org.codehaus.plexus.util.xml.pull.XmlPullParser > > > org.codehaus.plexus.util.xml.pull.XmlPullParserException > > > org.codehaus.plexus.util.xml.pull.XmlSerializer > > 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. > > -- > Sławomir Jaranowski > -- Guillaume Nodet
Re: How to fix MNG-7855 (dependencies wrongly put on class-path rather than module-path)?
Le lun. 4 sept. 2023 à 18:34, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2023-09-03 à 16 h 53, Romain Manni-Bucau a écrit : > > > Think command line tuning is already possible. > This if true for many parameters, but not for class-path / module-path > as far as I can see. It is easy to add parameters that were not added by > Maven. But it is difficult to change parameters added by Maven, > especially when there is no configuration option. The alternative using > java:exec is not very different than using Ant. At this point, it would > be easier to use Ant + Ivy. > I'd say open issues for the related plugins, several are known to be used (not sure about javadoc but others should). > > > > Pom changes are possible but mainly in build pom, not really in > > central pom > It would be additions rather than changes, and an absence of new element > would mean to use the default. But even if the additions are limited to > the build POM, it may be sufficient for a majority of cases. > The cases where you don't use dependencies so means you can't really use JPMS e2e so not sure it helps without new meta (properties). > > Martin > > > > - > 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)?
Le 2023-09-03 à 16 h 53, Romain Manni-Bucau a écrit : Think command line tuning is already possible. This if true for many parameters, but not for class-path / module-path as far as I can see. It is easy to add parameters that were not added by Maven. But it is difficult to change parameters added by Maven, especially when there is no configuration option. The alternative using java:exec is not very different than using Ant. At this point, it would be easier to use Ant + Ivy. Pom changes are possible but mainly in build pom, not really in central pom It would be additions rather than changes, and an absence of new element would mean to use the default. But even if the additions are limited to the build POM, it may be sufficient for a majority of cases. 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?
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. > > 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 ? > > 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 ? > > 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... ;-) > > -h > -- Guillaume Nodet
