multi-module partial archetype not supported
Hi Team, We are using Apache Maven 3.6.2 version and we found out that multi-module partial archetype is not supported. When applying a partial multimodule archetype on an existing multimodule project, few things like below should work. • -- existing pom/module poms should be merged • -- new modules should be added to the multimodule project • -- new files should be added to the project • -- attempt to modify an existing file should trigger an error According to Apache official site Jira ticket reference https://issues.apache.org/jira/browse/ARCHETYPE-550 , This issue is already fixed by someone and patch of the issue is available. So do you have any plans to release the latest version which includes the fix of multi-module partial archetype support. If not , is there any work around present for this. Regards, Sagar Koli.
[ANN] Apache Maven 3.6.3 Released
The Apache Maven team is pleased to announce the release of the Apache Maven 3.6.3 Apache Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information. Maven 3.6.3 is available via https://maven.apache.org/download.cgi Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project’s build, reporting, and documentation from a central place. The core release is independent of plugin releases. Further releases of plugins will be made separately. If you have any questions, please consult: - the web site: https://maven.apache.org/ - the maven-user mailing list: https://maven.apache.org/mailing-lists.html - the reference documentation: https://maven.apache.org/ref/3.6.3/ Overview about the major changes - This is a regression release to fix some critical issues shipped with 3.6.2. - Some license issues on binary distribution have been fixed. - This Maven distribution is now Reproducible: if you build from source archive, with JDK 8, on Windows, with 'mvn -DbuildNumber=cecedd343002696d0abb50b32b541b8a6ba2883f package' you’ll get bit-by-bit identical output that you can check with sha512 fingerprints. If you’re building on any Unix system, you’ll need to add “-Dline.separator=$'\r\n'”. See the https://maven.apache.org/guides/mini/guide-reproducible-builds.html for more details. For more information read https://maven.apache.org/docs/3.6.3/release-notes.html Enjoy! - The Maven Team
Re: 2 issues with maven version range
Hi John, On 24.11.19 20:46, John Patrick wrote: i'm trying to start using maven version range more but having issues with things like guava and also it not excluding version i believe should be excluded. 1) i don't think this is possible but it might be, take a look a google guava, it has a jre and a android version. using maven version range how can i say any newer jre version, or any newer android version? https://search.maven.org/artifact/com.google.guava/guava something like [25,) but only the jre maybe [25*-jre,) Let us start with Guava. The issue with Guava is that they made the `-jre` part of the version number which is from a Maven point of view simply wrong. This should have been done via a clas^sifier. Because -jre, -android are specialized packages which are valid for only particular environments. From the documentation[1]: ``` The classifier distinguishes artifacts that were built from the same POM but differ in content. It is some optional and arbitrary string that - if present - is appended to the artifact name just after the version number. As a motivation for this element, consider for example a project that offers an artifact targeting JRE 1.5 but at the same time also an artifact that still supports JRE 1.4. The first artifact could be equipped with the classifier jdk15 and the second one with jdk14 such that clients can choose which one to use. Another common use case for classifiers is to attach secondary artifacts to the project's main artifact. If you browse the Maven central repository, you will notice that the classifiers sources and javadoc are used to deploy the project source code and API docs along with the packaged class files. ``` So an android package could simply be namind by using: g: com.google.guava a: guava v: 27.1 classifier: jre etc. classifier: android Unfortunately they had decided to put this into the version which causes the issues. This in result means you can not select the version correctly. [1]: https://maven.apache.org/pom.html 2) i'm trying to use the version range "[4.7.0,5) "for io.cucumber:cucumber-core. So i'm expecting it to use 4.8.0, not 5.0.0-RC1 which is being picked up, i.e. mvn dependency:tree -Dverbose -Dincludes=io.cucumber https://search.maven.org/artifact/io.cucumber/cucumber-core what do i need to change "[4.7.0,5)" to do it excludes anything starting 5? So next checking for version comparison: This can be checked via command line: (from the Apache Maven installation): $ java -jar maven-artifact-3.6.2.jar 4.7.0 5 Display parameters as parsed by Maven (in canonical form) and comparison result: 1. 4.7.0 == 4.7 4.7.0 < 5 2. 5 == 5 This will show the obvious as you already know. Now let us check something different: lib$ java -jar maven-artifact-3.6.2.jar 5.0.0-alpha 5.0.0 Display parameters as parsed by Maven (in canonical form) and comparison result: 1. 5.0.0-alpha == 5-alpha 5.0.0-alpha < 5.0.0 2. 5.0.0 == 5 So based on that your version range: [4,5) will include everything which starts with "5.0.0", "5.0", or "5" this will also include "-RC??", "-alpha" and "-SNAPSHOT" because they are less than "5", "5.0" or "5.0.0" etc. Furthermore I would say "5" < "5-SNAPSHOT" is from a Maven point of view is very intuitve cause the "SNAPSHOT" is on the timeline before releasing final release "5". (This is also true for "5.0.0" < "5.0.0-SNAPSHOT"). To prevent having "RC"'s etc. in your range the only way is to use "[4,4.999.9)" (Yes it looks strange.) for given example cucumber-core... Also see the discussion on the users list: https://lists.apache.org/thread.html/888730bd2479a9ae247e12b1f7ae6a85285feb395bdfe99c2e435a46@ Unfortunately I agree that from a user point of view this should be done better. This could be changed for Maven 4.X but never for Maven 3.X. In the end my opinion (and experience) is simply not to use version ranges at all cause that could break your build without knowing why ..(I've seen that several times already)... Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: 2 issues with maven version range
> thoughts? (I don't design or use Maven version ranges) I agree that the behavior below, such as "5.0.0-SNAPSHOT" < "5", is not intuitive for users. Our team in Google recently articulated good practices of maintaining dependencies. One of the topics is "not to use version range": https://jlbp.dev/JLBP-14.html . On Tue, Nov 26, 2019 at 7:09 AM Maarten Mulders wrote: > I've recently had the same line of thought... > > Many projects publishing "release candidates" or "milestone releases". I > understand > this is great for having feedback from their user base, but sometimes > I'd rather use > a "stable" version. Although this brings a new question to the table: > who determines > what is stable? In the end, it's the author(s) of those projects who > decide that. > > Unfortunately, there seems not to be a default for releasing "release > candidates" > or "milestone releases". > > Cheers, > > Maarten > > On November 26, 2019 at 12:57, John Patrick wrote: > > > cheers for the information. > > > > I expect this might be asking space vs tabs, but do others feel the > > version range of "[4,5)" should exclude anything starting 5, include > > 5-SNAPSHOT and any 5...-RC* or 5...-alpha > > > > It seams wrong to have to use "[4,4.999)". > > > > I understand from a maths point of view and from a order point of view > > the ordering is correct but from an ease of use, end developers point > > of view, i should just be able to use "[4,5)" > > > > thoughts? > > > > On Mon, 25 Nov 2019 at 20:40, Tomo Suzuki > > wrote: > > I believe your cases do not work with version ranges. Version ranges > > depend > > on the order of the versions, and thus you cannot filter "-guava". > > > > The ordering of version is defined in > > org.eclipse.aether.util.version.GenericVersion in maven-resolver-util. > > > > Example code to check: > > > > // GenericVersionScheme is in > > org.apache.maven.resolver:maven-resolver-util:1.3.3 > > GenericVersionScheme scheme = new GenericVersionScheme(); > > List list = new ArrayList<>(); > > list.add(scheme.parseVersion("4.7.0")); > > list.add(scheme.parseVersion("4.9.0")); > > list.add(scheme.parseVersion("5")); > > list.add(scheme.parseVersion("5.0.0")); > > list.add(scheme.parseVersion("5.0.0-RC1")); > > list.add(scheme.parseVersion("5.0.0-SNAPSHOT")); > > Collections.sort(list); > > System.out.println(list); // [4.7.0, 4.9.0, 5.0.0-RC1, > > 5.0.0-SNAPSHOT, 5, 5.0.0] > > > > So version "5.0.0-RC1" is smaller than version "5"; you can use [4.7.0, > > 4.999]". > > > > Regards, > > Tomo > > > > On Sun, Nov 24, 2019 at 2:46 PM John Patrick > > wrote: > > > > i'm trying to start using maven version range more but having issues > > with things like guava and also it not excluding version i believe > > should be excluded. > > > > 1) i don't think this is possible but it might be, take a look a > > google guava, it has a jre and a android version. using maven version > > range how can i say any newer jre version, or any newer android > > version? > > > > https://search.maven.org/artifact/com.google.guava/guava > > > > something like [25,) but only the jre maybe [25*-jre,) > > > > 2) i'm trying to use the version range "[4.7.0,5) "for > > io.cucumber:cucumber-core. So i'm expecting it to use 4.8.0, not > > 5.0.0-RC1 which is being picked up, i.e. mvn dependency:tree -Dverbose > > -Dincludes=io.cucumber > > > > https://search.maven.org/artifact/io.cucumber/cucumber-core > > > > what do i need to change "[4.7.0,5)" to do it excludes anything > > starting 5? > > > > or are other people having similar issue so gave using trying to use > > maven version ranges when declaring dependencies? > > > > John > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > -- > > Regards, > > Tomo > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Regards, Tomo
Re: 2 issues with maven version range
I've recently had the same line of thought... Many projects publishing "release candidates" or "milestone releases". I understand this is great for having feedback from their user base, but sometimes I'd rather use a "stable" version. Although this brings a new question to the table: who determines what is stable? In the end, it's the author(s) of those projects who decide that. Unfortunately, there seems not to be a default for releasing "release candidates" or "milestone releases". Cheers, Maarten On November 26, 2019 at 12:57, John Patrick wrote: cheers for the information. I expect this might be asking space vs tabs, but do others feel the version range of "[4,5)" should exclude anything starting 5, include 5-SNAPSHOT and any 5...-RC* or 5...-alpha It seams wrong to have to use "[4,4.999)". I understand from a maths point of view and from a order point of view the ordering is correct but from an ease of use, end developers point of view, i should just be able to use "[4,5)" thoughts? On Mon, 25 Nov 2019 at 20:40, Tomo Suzuki wrote: I believe your cases do not work with version ranges. Version ranges depend on the order of the versions, and thus you cannot filter "-guava". The ordering of version is defined in org.eclipse.aether.util.version.GenericVersion in maven-resolver-util. Example code to check: // GenericVersionScheme is in org.apache.maven.resolver:maven-resolver-util:1.3.3 GenericVersionScheme scheme = new GenericVersionScheme(); List list = new ArrayList<>(); list.add(scheme.parseVersion("4.7.0")); list.add(scheme.parseVersion("4.9.0")); list.add(scheme.parseVersion("5")); list.add(scheme.parseVersion("5.0.0")); list.add(scheme.parseVersion("5.0.0-RC1")); list.add(scheme.parseVersion("5.0.0-SNAPSHOT")); Collections.sort(list); System.out.println(list); // [4.7.0, 4.9.0, 5.0.0-RC1, 5.0.0-SNAPSHOT, 5, 5.0.0] So version "5.0.0-RC1" is smaller than version "5"; you can use [4.7.0, 4.999]". Regards, Tomo On Sun, Nov 24, 2019 at 2:46 PM John Patrick wrote: i'm trying to start using maven version range more but having issues with things like guava and also it not excluding version i believe should be excluded. 1) i don't think this is possible but it might be, take a look a google guava, it has a jre and a android version. using maven version range how can i say any newer jre version, or any newer android version? https://search.maven.org/artifact/com.google.guava/guava something like [25,) but only the jre maybe [25*-jre,) 2) i'm trying to use the version range "[4.7.0,5) "for io.cucumber:cucumber-core. So i'm expecting it to use 4.8.0, not 5.0.0-RC1 which is being picked up, i.e. mvn dependency:tree -Dverbose -Dincludes=io.cucumber https://search.maven.org/artifact/io.cucumber/cucumber-core what do i need to change "[4.7.0,5)" to do it excludes anything starting 5? or are other people having similar issue so gave using trying to use maven version ranges when declaring dependencies? John - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Regards, Tomo - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: 2 issues with maven version range
cheers for the information. I expect this might be asking space vs tabs, but do others feel the version range of "[4,5)" should exclude anything starting 5, include 5-SNAPSHOT and any 5...-RC* or 5...-alpha It seams wrong to have to use "[4,4.999)". I understand from a maths point of view and from a order point of view the ordering is correct but from an ease of use, end developers point of view, i should just be able to use "[4,5)" thoughts? On Mon, 25 Nov 2019 at 20:40, Tomo Suzuki wrote: > > I believe your cases do not work with version ranges. Version ranges depend > on the order of the versions, and thus you cannot filter "-guava". > > The ordering of version is defined in > org.eclipse.aether.util.version.GenericVersion in maven-resolver-util. > > Example code to check: > > // GenericVersionScheme is in > org.apache.maven.resolver:maven-resolver-util:1.3.3 > GenericVersionScheme scheme = new GenericVersionScheme(); > List list = new ArrayList<>(); > list.add(scheme.parseVersion("4.7.0")); > list.add(scheme.parseVersion("4.9.0")); > list.add(scheme.parseVersion("5")); > list.add(scheme.parseVersion("5.0.0")); > list.add(scheme.parseVersion("5.0.0-RC1")); > list.add(scheme.parseVersion("5.0.0-SNAPSHOT")); > Collections.sort(list); > System.out.println(list); // [4.7.0, 4.9.0, 5.0.0-RC1, > 5.0.0-SNAPSHOT, 5, 5.0.0] > > So version "5.0.0-RC1" is smaller than version "5"; you can use [4.7.0, > 4.999]". > > Regards, > Tomo > > On Sun, Nov 24, 2019 at 2:46 PM John Patrick wrote: > > > i'm trying to start using maven version range more but having issues > > with things like guava and also it not excluding version i believe > > should be excluded. > > > > 1) i don't think this is possible but it might be, take a look a > > google guava, it has a jre and a android version. using maven version > > range how can i say any newer jre version, or any newer android > > version? > > > > https://search.maven.org/artifact/com.google.guava/guava > > > > something like [25,) but only the jre maybe [25*-jre,) > > > > 2) i'm trying to use the version range "[4.7.0,5) "for > > io.cucumber:cucumber-core. So i'm expecting it to use 4.8.0, not > > 5.0.0-RC1 which is being picked up, i.e. mvn dependency:tree -Dverbose > > -Dincludes=io.cucumber > > > > https://search.maven.org/artifact/io.cucumber/cucumber-core > > > > what do i need to change "[4.7.0,5)" to do it excludes anything starting 5? > > > > or are other people having similar issue so gave using trying to use > > maven version ranges when declaring dependencies? > > > > John > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > -- > Regards, > Tomo - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org