multi-module partial archetype not supported

2019-11-26 Thread Sagar Koli
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

2019-11-26 Thread Robert Scholte
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

2019-11-26 Thread Karl Heinz Marbaise

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

2019-11-26 Thread Tomo Suzuki
> 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

2019-11-26 Thread Maarten Mulders

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

2019-11-26 Thread John Patrick
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