Re: Incomprehensable error!! -> Didn't help!

[Tamás Cservenák]

Howdy,

That is my experience as well, IDEA is good, but sometimes has
glitches (my current pet peeve with the latest version is that Maven
"Refresh" does not refresh in some cases).

And yes, the Maven CLI is the "golden standard", that is what we can
support -- sorta. Everything else, like IDE integrations, tools using
it, etc... Well, bummer.

Thanks
T

On Wed, Sep 11, 2024 at 6:55 PM Tommy Svensson  wrote:
>
> This unfortunately did not help!
>
> From my POM:
>
> 
> 
> repsy
> repsy
> https://repo.repsy.io/mvn/tombensve/natusoft-os
> 
> 
>
> 
> 
> repsy
> My Private Maven Repository on Repsy
> https://repo.repsy.io/mvn/tombensve/natusoft-os
> 
>
> 
> [ERROR] Could not find artifact 
> se.natusoft.tools.doc.markdowndoc:markdowndoc- maven-plugin:jar:3.0.1 in 
> central (https://repo.maven.apache.org/maven2)
>
> Line from Repsy repo:
>
> se.natusoft.tools.doc.markdowndoc:markdowndoc-maven-plugin:3.0.1
> For some reason it is not looking in my repo which is specified in my pom as 
> seen above!
>
> …
>
> Aha! I solved it, now built every thing! The solution was to NOT BUILD IN 
> IDEA!!!
>
> ./mvnw clean install
> In a terminal did the trick!
>
> The Brains aren’t so Jet:y these days. Maybe they are doing too much.
>
>
>
> Tommy Svensson
> to...@natusoft.se
>
>
>
> Från: Tommy Svensson 
> Svara: Tommy Svensson 
> Datum: 11 september 2024 at 18:16:40
> Till: Maven Users List , Tamás Cservenák 
> 
> Ämne:  Re: Incomprehensable error!!
>
> Hello Tamas,
>
> Thanks for the reply! It is this: https://repo.maven.apache.org/maven2 it 
> complains about not finding my binary in. And as I said, it never will.
>
> But cleaning my local repo and rebuild sounds like a very good idea. I wish I 
> thought of that myself …
>
>
>
> Tommy Svensson
> to...@natusoft.se
>
>
>
> Från: Tamás Cservenák 
> Svara: Maven Users List 
> Datum: 11 september 2024 at 18:03:08
> Till: Maven Users List 
> Ämne:  Re: Incomprehensable error!!
>
> Hej Tommy,
>
> easy to check:
> nuke (or just mv repository repository-off temporarily) your local
> repository and rebuild with an empty local repository => it will fail.
>
> This means that your build is incomplete regarding required repository
> definitions, it needs something that is not available from the
> repositories that are defined (in POM and/or in settings/profiles).
>
> HTH
> Tamas
>
> On Wed, Sep 11, 2024 at 5:56 PM Tommy Svensson  wrote:
> >
> > I out of the blue get this error when building:
> >
> > Artifact 
> > se.natusoft.tools.codelicmgr:CodeLicenseManager-maven-plugin:pom:2.2.6 is 
> > present in the local repository, but cached from a remote repository ID 
> > that is unavailable in current build context, verifying that is 
> > downloadable from [central (https://repo.maven.apache.org/maven2, default, 
> > releases)][INFO] Artifact 
> > se.natusoft.tools.codelicmgr:CodeLicenseManager-maven-plugin:pom:2.2.6 is 
> > present in the local repository, but cached from a remote repository ID 
> > that is unavailable in current build context, verifying that is 
> > downloadable from [central (https://repo.maven.apache.org/maven2, default, 
> > releases)]
> >
> > What the message says is totally correct! The binary is not in maven 
> > central and never will be!!!
> >
> > Why is that a problem ? Why should I now not be able to build locally due 
> > to that ?
> >
> > It just makes no sense!
> >
> > I’ve been building this over and over without a problem and suddenly out of 
> > the blue this happens, and makes it completely totally impossible for me to 
> > do anything!
> >
> > The actual failed dependency is on my disk but still it has to go out and 
> > not find it elsewere, which it never will …
> >
> > Maybe I’m standing in the wrong angle towards north when I’m building …
> >
> >
> >
> > Tommy Svensson
> > to...@natusoft.se
> >
> >
>
> -
> 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: Incomprehensable error!! -> Didn't help!

[Tommy Svensson]

This unfortunately did not help!

From my POM:



repsy
repsy
https://repo.repsy.io/mvn/tombensve/natusoft-os





repsy
My Private Maven Repository on Repsy
https://repo.repsy.io/mvn/tombensve/natusoft-os



[ERROR] Could not find artifact se.natusoft.tools.doc.markdowndoc:markdowndoc- 
maven-plugin:jar:3.0.1 in central (https://repo.maven.apache.org/maven2)

Line from Repsy repo:

se.natusoft.tools.doc.markdowndoc:markdowndoc-maven-plugin:3.0.1
For some reason it is not looking in my repo which is specified in my pom as 
seen above!

…

Aha! I solved it, now built every thing! The solution was to NOT BUILD IN 
IDEA!!!

./mvnw clean install  
In a terminal did the trick!

The Brains aren’t so Jet:y these days. Maybe they are doing too much.



Tommy Svensson
to...@natusoft.se



Från: Tommy Svensson 
Svara: Tommy Svensson 
Datum: 11 september 2024 at 18:16:40
Till: Maven Users List , Tamás Cservenák 

Ämne:  Re: Incomprehensable error!!

Hello Tamas,

Thanks for the reply! It is this: https://repo.maven.apache.org/maven2 it 
complains about not finding my binary in. And as I said, it never will.

But cleaning my local repo and rebuild sounds like a very good idea. I wish I 
thought of that myself …



Tommy Svensson
to...@natusoft.se



Från: Tamás Cservenák 
Svara: Maven Users List 
Datum: 11 september 2024 at 18:03:08
Till: Maven Users List 
Ämne:  Re: Incomprehensable error!!

Hej Tommy,  

easy to check:  
nuke (or just mv repository repository-off temporarily) your local  
repository and rebuild with an empty local repository => it will fail.  

This means that your build is incomplete regarding required repository  
definitions, it needs something that is not available from the  
repositories that are defined (in POM and/or in settings/profiles).  

HTH  
Tamas  

On Wed, Sep 11, 2024 at 5:56 PM Tommy Svensson  wrote:  
>  
> I out of the blue get this error when building:  
>  
> Artifact 
> se.natusoft.tools.codelicmgr:CodeLicenseManager-maven-plugin:pom:2.2.6 is 
> present in the local repository, but cached from a remote repository ID that 
> is unavailable in current build context, verifying that is downloadable from 
> [central (https://repo.maven.apache.org/maven2, default, releases)][INFO] 
> Artifact 
> se.natusoft.tools.codelicmgr:CodeLicenseManager-maven-plugin:pom:2.2.6 is 
> present in the local repository, but cached from a remote repository ID that 
> is unavailable in current build context, verifying that is downloadable from 
> [central (https://repo.maven.apache.org/maven2, default, releases)]  
>  
> What the message says is totally correct! The binary is not in maven central 
> and never will be!!!  
>  
> Why is that a problem ? Why should I now not be able to build locally due to 
> that ?  
>  
> It just makes no sense!  
>  
> I’ve been building this over and over without a problem and suddenly out of 
> the blue this happens, and makes it completely totally impossible for me to 
> do anything!  
>  
> The actual failed dependency is on my disk but still it has to go out and not 
> find it elsewere, which it never will …  
>  
> Maybe I’m standing in the wrong angle towards north when I’m building …  
>  
>  
>  
> Tommy Svensson  
> to...@natusoft.se  
>  
>  

-  
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org  
For additional commands, e-mail: users-h...@maven.apache.org  

[ANN] Release Maven Help Plugin 3.5.0 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
Help Plugin version 3.5.0.


https://maven.apache.org/plugins/maven-help-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-help-plugin
  3.5.0



Release Notes - Maven Help Plugin - Version 3.5.0

** Task
* [MPH-189] - Get rid of commons-lang3

** Dependency upgrade
* [MPH-212] - Upgrade to Doxia 2.0.0 Milestone Stack
* [MPH-215] - Upgrade to Parent 43


NOTE: Read the details on this release here: 
https://cwiki.apache.org/confluence/display/MAVEN/Towards+Doxia+2.0.0+Stack


Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Release Maven Help Plugin 3.4.1 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
Help Plugin version 3.4.1.


https://maven.apache.org/plugins/maven-help-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-help-plugin
  3.4.1



Release Notes - Maven Help Plugin - Version 3.4.1

** Test
* [MPH-207] - Exercise output of an expression returning a null object.

** Dependency upgrade
* [MPH-211] - Upgrade maven-plugin parent to 41
* [MPH-213] - Upgrade org.codehaus.plexus:plexus-interactivity-api 
from 1.3

* [MPH-214] - Upgrade to Parent 42


Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Release Maven Help Plugin 3.4.0 released

[Slawomir Jaranowski]

The Apache Maven team is pleased to announce the release of the Maven Help
Plugin version 3.4.0.

The Maven Help Plugin is used to get relative information about a project
or the system.

https://maven.apache.org/plugins/maven-help-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-help-plugin
  3.4.0


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/plugins/maven-help-plugin/download.html

Release Notes - Maven Help Plugin - Version 3.4.0

** Improvement
* [MPH-185] - Require Maven 3.6.3
* [MPH-195] - Get rid of ${localRepository} from mojo parameter
* [MPH-198] - Get rid of maven-reporting-exec
* [MPH-201] - Improvement of usage maven-plugin-tools-generators

** Task
* [MPH-200] - Refresh download page

** Dependency upgrade
* [MPH-194] - Upgrade Parent to 39
* [MPH-196] - Bump xstream to 1.4.20
* [MPH-197] - Upgrade plexus-utils to 3.5.1
* [MPH-199] - Bump mockito-core from 2.28.2 to 4.11.0
* [MPH-202] - Bump mrm-maven-plugin from 1.4.1 to 1.5.0
* [MPH-203] - Bump commons-lang3 from 3.8.1 to 3.12.0

Enjoy,

-The Apache Maven team

Re: Dependencies - need help/advice: Getting the latest version of a specific (not all) dependencies

[Nils Breunese]

Bruno Melloni  wrote:

> First, you are right... I misread.  When I look at the maven plugins in 
> pluginManagement I see v2 and v3:  clean=3.1.0, compiler=3.8.1, 
> surefire=2.22.1, jar=3.0.2, install=2.5.2, deploy=2.8.2, site=3.7.1, 
> project-info-reports=3.0.0.  Still, it is > 2.0 so LATEST is no longer 
> supported as a version tag.

As far as I know there is no direct relation between Maven plugin versions and 
the version of Maven itself. If you add the -V flag to your build command the 
version of Maven itself will be printed. Or run Maven with just the -v if you 
want the Maven version without running a build.

> (1) IntelliJ is caching the JARs it uses for a project somewhere.  And giving 
> it the commands to reload dependencies or the POM fail if the version number 
> has not changed... since I am seeing a file from January.  Also, the IntelliJ 
> setting "Always update snapshots" fails as well.  This may be a Maven issue 
> or it might be a quirk of IntelliJ, my suspicion is that IntelliJ relied on 
> the old 2.x maven behavior for that setting.  Sadly I am not knowledgeable 
> enough to know.

And what happens when you build the apps using Maven directly instead of using 
IntelliJ?

> (2) Looking for an alternative all I found for 3.0 and above Maven was the 
> use of version ranges in the dependency entry of the app2 POM.  That would 
> require updating the version after even a tiny change in app1, but at least 
> it would not require updating the version in the the pom of the myriad of 
> "app2"s that we have, unless we wanted to.  I suspect this is what 
> versions-maven-plugin does but that I botched it when I tried to use it, as 
> its documentation is very confusing for a beginner and they don't provide a 
> single complete example of a POM that uses it.  The symptom was an error 
> popping up in the POM itself, long before trying to do a build.  I think the 
> error was either the "[0.0.1, 0.0.999)-SNAPSHOT" tag, or 
> my missing something in plugin management.

I don’t know if [0.0.1, 0.0.999)-SNAPSHOT is valid syntax, 
but if it is, then I would recommend not using it. (I generally would stay away 
from using version ranges in general, because it screws up reproducible 
builds.) As long as you’re using a snapshot version for the app1 dependency in 
app2 you should not need to bump the dependency version when making changes to 
app1.

Nils.

P.S. Maybe off-topic, but what is your use case for one app depending on 
another? I’d generally use a library dependency to share functionality between 
multiple apps.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Dependencies - need help/advice: Getting the latest version of a specific (not all) dependencies

[Arnaud bourree]

Hi,

Does yesterday dependency build on an other pc? Then it should be "deploy"
to your company central repository (Artifactory, Nexus, ...) to be fetched
from your pc.

Using version range and snapshot is not good idea. It's better to use
snapshot only.
If you want incremental version from you CI/CD, you should not use snapshot.

Regards,

Arnaud

Le sam. 24 sept. 2022, 08:49, Delany  a écrit :

> > Finally I opened app2-0.0.1-SNAPSHOT.jar and looked for the included
> app1-0.0.1-SNAPSHOT.jar file.
>
> What does this mean?
>
>
> On Sat, 24 Sept 2022 at 00:05, Bruno Melloni  wrote:
>
> > First, you are right... I misread.  When I look at the maven plugins in
> > pluginManagement I see v2 and v3:  clean=3.1.0, compiler=3.8.1,
> > surefire=2.22.1, jar=3.0.2, install=2.5.2, deploy=2.8.2, site=3.7.1,
> > project-info-reports=3.0.0.  Still, it is > 2.0 so LATEST is no longer
> > supported as a version tag.
> >
> > Let's see if I can explain it better:
> >
> > - I emptied the local maven repository of every single one of my
> > projects, literally went in the folder net/myorg and deleted everything
> > from there.
> >
> > - Then I rebuilt in order.  This included app1 and app2 (that has app1
> > as one of its dependencies) which showed up in the local repository
> > folder.  Obviously, both generated snapshot jars had a timestamp of
> > yesterday.
> >
> > - Finally I opened app2-0.0.1-SNAPSHOT.jar and looked for the included
> > app1-0.0.1-SNAPSHOT.jar file.  I expected to see yesterday's timestamp
> > on the JAR file since I had just done a maven clean install.  Nope, it
> > had a January timestamp, and the contents were old.
> >
> > So, it is clear that:
> >
> > (1) IntelliJ is caching the JARs it uses for a project somewhere.  And
> > giving it the commands to reload dependencies or the POM fail if the
> > version number has not changed... since I am seeing a file from
> > January.  Also, the IntelliJ setting "Always update snapshots" fails as
> > well.  This may be an Maven issue or it might be a quirk of IntelliJ, my
> > suspicion is that IntelliJ relied on the old 2.x maven behavior for that
> > setting.  Sadly I am not knowledgeable enough to know.
> >
> > (2) Looking for an alternative all I found for 3.0 and above Maven was
> > the use of version ranges in the dependency entry of the app2 POM.  That
> > would require updating the version after even a tiny change in app1, but
> > at least it would not require updating the version in the the pom of the
> > myriad of "app2"s that we have, unless we wanted to.  I suspect this is
> > what versions-maven-plugin does but that I botched it when I tried to
> > use it, as its documentation is very confusing for a beginner and they
> > don't provide a single complete example of a POM that uses it.  The
> > symptom was an error popping up in the POM itself, long before trying to
> > do a build.  I think the error was either the "[0.0.1,
> > 0.0.999)-SNAPSHOT" tag, or my missing something in plugin
> > management.
> >
> > Conclusion:
> >
> > It seems that the cleanest way to solve this is to use the
> > versions-maven-plugin, but I am not using it right.  Any help on this
> > would be great.  A simple working example of a POM that uses
> > version-maven-plugin with a version range would be ideal.
> >
> >
> > On 9/23/2022 1:25 PM, Nils Breunese wrote:
> > > Hi Bruno,
> > >
> > > It’s not completely clear to me what your issue is exactly. Is ’the old
> > cached version from January’ that you refer to an artifact with a
> snapshot
> > version or a release version? If it is a snapshot version, it depends on
> > the update policy whether Maven will use a locally cached snapshot or
> > whether it will try to fetch an update from the the configured
> repository.
> > If there is no explicit update policy configured, I believe the default
> is
> > to look for updates once a day. You can force Maven to update snapshots
> by
> > using the -U (or --update-snapshots) flag. If your dependency is a
> release
> > version, then there can be only one artifact for that version and if you
> > have it cached locally, it should be identical to that version of the
> > artifact on the repository server.
> > >
> > > Maven 4 has not been released yet, are you sure you are (and should be)
> > using that version? Version 3.8.6 is the current latest release [0].
> > >
> > > To avoid having to manually update dependencies my team has a scheduled

Re: Dependencies - need help/advice: Getting the latest version of a specific (not all) dependencies

[Delany]

> Finally I opened app2-0.0.1-SNAPSHOT.jar and looked for the included
app1-0.0.1-SNAPSHOT.jar file.

What does this mean?


On Sat, 24 Sept 2022 at 00:05, Bruno Melloni  wrote:

> First, you are right... I misread.  When I look at the maven plugins in
> pluginManagement I see v2 and v3:  clean=3.1.0, compiler=3.8.1,
> surefire=2.22.1, jar=3.0.2, install=2.5.2, deploy=2.8.2, site=3.7.1,
> project-info-reports=3.0.0.  Still, it is > 2.0 so LATEST is no longer
> supported as a version tag.
>
> Let's see if I can explain it better:
>
> - I emptied the local maven repository of every single one of my
> projects, literally went in the folder net/myorg and deleted everything
> from there.
>
> - Then I rebuilt in order.  This included app1 and app2 (that has app1
> as one of its dependencies) which showed up in the local repository
> folder.  Obviously, both generated snapshot jars had a timestamp of
> yesterday.
>
> - Finally I opened app2-0.0.1-SNAPSHOT.jar and looked for the included
> app1-0.0.1-SNAPSHOT.jar file.  I expected to see yesterday's timestamp
> on the JAR file since I had just done a maven clean install.  Nope, it
> had a January timestamp, and the contents were old.
>
> So, it is clear that:
>
> (1) IntelliJ is caching the JARs it uses for a project somewhere.  And
> giving it the commands to reload dependencies or the POM fail if the
> version number has not changed... since I am seeing a file from
> January.  Also, the IntelliJ setting "Always update snapshots" fails as
> well.  This may be an Maven issue or it might be a quirk of IntelliJ, my
> suspicion is that IntelliJ relied on the old 2.x maven behavior for that
> setting.  Sadly I am not knowledgeable enough to know.
>
> (2) Looking for an alternative all I found for 3.0 and above Maven was
> the use of version ranges in the dependency entry of the app2 POM.  That
> would require updating the version after even a tiny change in app1, but
> at least it would not require updating the version in the the pom of the
> myriad of "app2"s that we have, unless we wanted to.  I suspect this is
> what versions-maven-plugin does but that I botched it when I tried to
> use it, as its documentation is very confusing for a beginner and they
> don't provide a single complete example of a POM that uses it.  The
> symptom was an error popping up in the POM itself, long before trying to
> do a build.  I think the error was either the "[0.0.1,
> 0.0.999)-SNAPSHOT" tag, or my missing something in plugin
> management.
>
> Conclusion:
>
> It seems that the cleanest way to solve this is to use the
> versions-maven-plugin, but I am not using it right.  Any help on this
> would be great.  A simple working example of a POM that uses
> version-maven-plugin with a version range would be ideal.
>
>
> On 9/23/2022 1:25 PM, Nils Breunese wrote:
> > Hi Bruno,
> >
> > It’s not completely clear to me what your issue is exactly. Is ’the old
> cached version from January’ that you refer to an artifact with a snapshot
> version or a release version? If it is a snapshot version, it depends on
> the update policy whether Maven will use a locally cached snapshot or
> whether it will try to fetch an update from the the configured repository.
> If there is no explicit update policy configured, I believe the default is
> to look for updates once a day. You can force Maven to update snapshots by
> using the -U (or --update-snapshots) flag. If your dependency is a release
> version, then there can be only one artifact for that version and if you
> have it cached locally, it should be identical to that version of the
> artifact on the repository server.
> >
> > Maven 4 has not been released yet, are you sure you are (and should be)
> using that version? Version 3.8.6 is the current latest release [0].
> >
> > To avoid having to manually update dependencies my team has a scheduled
> task to run Renovate [1] in our applications' CI pipelines to check for
> dependency updates. Renovate automatically creates a branch and a merge
> request whenever a dependency update is found. There are more tools like
> Renovate. For instance GitHub also provides Dependabot [2]. Maven Versions
> Plugin [3] can also be used to update dependencies.
> >
> > Nils.
> >
> > [0] https://maven.apache.org/download.cgi
> > [1] https://github.com/renovatebot/renovate
> > [2] https://docs.github.com/en/code-security/dependabot
> > [3] https://www.mojohaus.org/versions-maven-plugin/
> >
> >> Op 23 sep. 2022, om 14:58 heeft Bruno  het
> volgende geschreven:
> >>
> >> I apologize for the length of this email, I could not think of a
> 

Re: Dependencies - need help/advice: Getting the latest version of a specific (not all) dependencies

[Bruno Melloni]

First, you are right... I misread.  When I look at the maven plugins in 
pluginManagement I see v2 and v3:  clean=3.1.0, compiler=3.8.1, 
surefire=2.22.1, jar=3.0.2, install=2.5.2, deploy=2.8.2, site=3.7.1, 
project-info-reports=3.0.0.  Still, it is > 2.0 so LATEST is no longer 
supported as a version tag.


Let's see if I can explain it better:

- I emptied the local maven repository of every single one of my 
projects, literally went in the folder net/myorg and deleted everything 
from there.


- Then I rebuilt in order.  This included app1 and app2 (that has app1 
as one of its dependencies) which showed up in the local repository 
folder.  Obviously, both generated snapshot jars had a timestamp of 
yesterday.


- Finally I opened app2-0.0.1-SNAPSHOT.jar and looked for the included 
app1-0.0.1-SNAPSHOT.jar file.  I expected to see yesterday's timestamp 
on the JAR file since I had just done a maven clean install.  Nope, it 
had a January timestamp, and the contents were old.


So, it is clear that:

(1) IntelliJ is caching the JARs it uses for a project somewhere.  And 
giving it the commands to reload dependencies or the POM fail if the 
version number has not changed... since I am seeing a file from 
January.  Also, the IntelliJ setting "Always update snapshots" fails as 
well.  This may be an Maven issue or it might be a quirk of IntelliJ, my 
suspicion is that IntelliJ relied on the old 2.x maven behavior for that 
setting.  Sadly I am not knowledgeable enough to know.


(2) Looking for an alternative all I found for 3.0 and above Maven was 
the use of version ranges in the dependency entry of the app2 POM.  That 
would require updating the version after even a tiny change in app1, but 
at least it would not require updating the version in the the pom of the 
myriad of "app2"s that we have, unless we wanted to.  I suspect this is 
what versions-maven-plugin does but that I botched it when I tried to 
use it, as its documentation is very confusing for a beginner and they 
don't provide a single complete example of a POM that uses it.  The 
symptom was an error popping up in the POM itself, long before trying to 
do a build.  I think the error was either the "[0.0.1, 
0.0.999)-SNAPSHOT" tag, or my missing something in plugin 
management.


Conclusion:

It seems that the cleanest way to solve this is to use the 
versions-maven-plugin, but I am not using it right.  Any help on this 
would be great.  A simple working example of a POM that uses 
version-maven-plugin with a version range would be ideal.



On 9/23/2022 1:25 PM, Nils Breunese wrote:

Hi Bruno,

It’s not completely clear to me what your issue is exactly. Is ’the old cached 
version from January’ that you refer to an artifact with a snapshot version or 
a release version? If it is a snapshot version, it depends on the update policy 
whether Maven will use a locally cached snapshot or whether it will try to 
fetch an update from the the configured repository. If there is no explicit 
update policy configured, I believe the default is to look for updates once a 
day. You can force Maven to update snapshots by using the -U (or 
--update-snapshots) flag. If your dependency is a release version, then there 
can be only one artifact for that version and if you have it cached locally, it 
should be identical to that version of the artifact on the repository server.

Maven 4 has not been released yet, are you sure you are (and should be) using 
that version? Version 3.8.6 is the current latest release [0].

To avoid having to manually update dependencies my team has a scheduled task to 
run Renovate [1] in our applications' CI pipelines to check for dependency 
updates. Renovate automatically creates a branch and a merge request whenever a 
dependency update is found. There are more tools like Renovate. For instance 
GitHub also provides Dependabot [2]. Maven Versions Plugin [3] can also be used 
to update dependencies.

Nils.

[0] https://maven.apache.org/download.cgi
[1] https://github.com/renovatebot/renovate
[2] https://docs.github.com/en/code-security/dependabot
[3] https://www.mojohaus.org/versions-maven-plugin/


Op 23 sep. 2022, om 14:58 heeft Bruno  het volgende 
geschreven:

I apologize for the length of this email, I could not think of a shorter way to 
present the issue/questions that is clear enough.

---

My environment involves the usual many open source dependencies (which I 
control by specifying the versions to use in a master POM), but also a large 
number of frequently changing internally built dependencies and a huge number 
of applications that rely on these dependencies.

Changes on these internally built dependencies are carefully controlled so that 
they are always backwards compatible.  In over a decade before we used maven we 
had a single instance of these dependencies and we never - not once - had a 
version conflict problem.

But the default mode for Maven is to updat

Re: Dependencies - need help/advice: Getting the latest version of a specific (not all) dependencies

[Nils Breunese]

Hi Bruno,

It’s not completely clear to me what your issue is exactly. Is ’the old cached 
version from January’ that you refer to an artifact with a snapshot version or 
a release version? If it is a snapshot version, it depends on the update policy 
whether Maven will use a locally cached snapshot or whether it will try to 
fetch an update from the the configured repository. If there is no explicit 
update policy configured, I believe the default is to look for updates once a 
day. You can force Maven to update snapshots by using the -U (or 
--update-snapshots) flag. If your dependency is a release version, then there 
can be only one artifact for that version and if you have it cached locally, it 
should be identical to that version of the artifact on the repository server.

Maven 4 has not been released yet, are you sure you are (and should be) using 
that version? Version 3.8.6 is the current latest release [0].

To avoid having to manually update dependencies my team has a scheduled task to 
run Renovate [1] in our applications' CI pipelines to check for dependency 
updates. Renovate automatically creates a branch and a merge request whenever a 
dependency update is found. There are more tools like Renovate. For instance 
GitHub also provides Dependabot [2]. Maven Versions Plugin [3] can also be used 
to update dependencies.

Nils.

[0] https://maven.apache.org/download.cgi
[1] https://github.com/renovatebot/renovate
[2] https://docs.github.com/en/code-security/dependabot
[3] https://www.mojohaus.org/versions-maven-plugin/

> Op 23 sep. 2022, om 14:58 heeft Bruno  het volgende 
> geschreven:
> 
> I apologize for the length of this email, I could not think of a shorter way 
> to present the issue/questions that is clear enough.
> 
> ---
> 
> My environment involves the usual many open source dependencies (which I 
> control by specifying the versions to use in a master POM), but also a large 
> number of frequently changing internally built dependencies and a huge number 
> of applications that rely on these dependencies.
> 
> Changes on these internally built dependencies are carefully controlled so 
> that they are always backwards compatible.  In over a decade before we used 
> maven we had a single instance of these dependencies and we never - not once 
> - had a version conflict problem.
> 
> But the default mode for Maven is to update the version number even for a 
> tiny change and then to manually update the version of the dependency in 
> every single project that depends on it.  Since we have a lot of those, this 
> is a horribly error prone process leading to applications that crash because 
> they are using the wrong version of a dependency.  As an example... one of 
> our crashing applications that was built yesterday was found to contain a 
> dependency JAR from January!!! when it should have contained a JAR that was 
> also built yesterday.
> 
> Things that we tried:
> 
> - Builds and executions *INSIDE* of IntelliJ work beautifully. It always 
> finds the latest code and it always runs on the local integrated server 
> perfectly. _The problem happens in the JARs/WARs of applications placed into 
> the Maven local repository_.
> 
> - In IntelliJ we tried checking 
> Settings/Build,Execution,Deployment/BuildTools/Maven/"Always update 
> snapshots" and not change the version number between releases so that it 
> would include a fresh copy of the dependency during build, but even 
> *completely wiping out* the local repository (the only one in use at this 
> moment) it still used the old cached version from January.
> 
> - Next I tried to use the LATEST syntax in the POM.  But 
> LATEST was removed after Maven 2 and we are using Maven 4.
> 
> - Finally I tried to use [0.0.1, 0.0.999)-SNAPSHOT in the 
> hope of simply updating the version number of the dependency during 
> development/tests and only updating the formal dependency version to 1.0.0 at 
> release time but Maven rejected the syntax.  It is quite possible that the 
> syntax I used is incorrect, but sadly the documentation is not very clear and 
> provides no complete examples that I could inspect or duplicate.
> 
> *QUESTIONS*:
> 
> 1) Was one of the above methods supposed to work?  If yes, what did I do 
> wrong and how do I fix it?
> 
> 2) If none of the above methods is supported anymore (Maven 4), what method 
> should I be using?
> 
> 3) Is there any other tool - besides Maven - that I should be using for these 
> builds.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Dependencies - need help/advice: Getting the latest version of a specific (not all) dependencies

[Bruno]

I apologize for the length of this email, I could not think of a shorter 
way to present the issue/questions that is clear enough.


---

My environment involves the usual many open source dependencies (which I 
control by specifying the versions to use in a master POM), but also a 
large number of frequently changing internally built dependencies and a 
huge number of applications that rely on these dependencies.


Changes on these internally built dependencies are carefully controlled 
so that they are always backwards compatible.  In over a decade before 
we used maven we had a single instance of these dependencies and we 
never - not once - had a version conflict problem.


But the default mode for Maven is to update the version number even for 
a tiny change and then to manually update the version of the dependency 
in every single project that depends on it.  Since we have a lot of 
those, this is a horribly error prone process leading to applications 
that crash because they are using the wrong version of a dependency.  As 
an example... one of our crashing applications that was built yesterday 
was found to contain a dependency JAR from January!!! when it should 
have contained a JAR that was also built yesterday.


Things that we tried:

- Builds and executions *INSIDE* of IntelliJ work beautifully. It always 
finds the latest code and it always runs on the local integrated server 
perfectly. _The problem happens in the JARs/WARs of applications placed 
into the Maven local repository_.


- In IntelliJ we tried checking 
Settings/Build,Execution,Deployment/BuildTools/Maven/"Always update 
snapshots" and not change the version number between releases so that it 
would include a fresh copy of the dependency during build, but even 
*completely wiping out* the local repository (the only one in use at 
this moment) it still used the old cached version from January.


- Next I tried to use the LATEST syntax in the POM.  
But LATEST was removed after Maven 2 and we are using Maven 4.


- Finally I tried to use [0.0.1, 0.0.999)-SNAPSHOT in 
the hope of simply updating the version number of the dependency during 
development/tests and only updating the formal dependency version to 
1.0.0 at release time but Maven rejected the syntax.  It is quite 
possible that the syntax I used is incorrect, but sadly the 
documentation is not very clear and provides no complete examples that I 
could inspect or duplicate.


*QUESTIONS*:

1) Was one of the above methods supposed to work?  If yes, what did I do 
wrong and how do I fix it?


2) If none of the above methods is supported anymore (Maven 4), what 
method should I be using?


3) Is there any other tool - besides Maven - that I should be using for 
these builds.

[ANN] Release Maven Help Plugin 3.3.0 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
Help Plugin version 3.3.0.


This module generates browsable HTML pages from Java source code.

https://maven.apache.org/plugins/maven-help-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-help-plugin
  3.3.0



Release Notes - Maven Help Plugin - Version 3.3.0

** Bug
* [MPH-164] - Effective-pom ignores artifact argument
* [MPH-171] - Plugin repositories are not preserved from project pom

** Improvement
* [MPH-162] - Allow all mojos to be configured to produce 
repeatable output

* [MPH-167] - make build Reproducible
* [MPH-170] - Require Maven 3.1.1 (drop dependency to Maven 3.0)

** Task
* [MPH-187] - Upgrade to JDK minimum
* [MPH-188] - Cleanup - Pom

** Dependency upgrade
* [MPH-174] - Upgrade XStream to 1.4.17
* [MPH-179] - Upgrade XStream to 1.4.18
* [MPH-186] - maven-parent to 37
* [MPH-190] - Upgrade Maven Reporting API to 3.1.1


Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Need help for maven site plugin for Apache Helix

[Olivier Lamy]

Thanks Hervé!.
@Junkai I have merged Hervé's PR



On Sat, 20 Nov 2021 at 20:31, Hervé BOUTEMY  wrote:

> FYI, on the "SiteToolException: Error parsing site descriptor: TEXT must
> beimmediately followed by END_TAG and not START_TAG" error, the key Maven
> Site
> Plugin version is version 3.5, where the parsing of site.xml changed:
> previously it was parser as XML, and since 3.5 it is parsed as text
>
> the consequence is that in general, you need to surround head and footer
> data
> from site.xml (including parents) with 
>
> that's why Apache parent version is related to maven-site-plugin version
>
> HTH
>
> Hervé
>
> Le samedi 20 novembre 2021, 09:19:41 CET Hervé BOUTEMY a écrit :
> > Hi,
> >
> > Apache parent 13 is so old...
> >
> > see https://github.com/apache/helix/pull/1909
> > upgrading both Apache parent POM and maven-site-plugin seems to do the
> job
> >
> > Regards,
> >
> > Hervé
> >
> > Le jeudi 18 novembre 2021, 00:04:03 CET Junkai Xue a écrit :
> > > Hi,
> > >
> > > I was trying to deploy Apache Helix project website for new releases.
> Got
> > > exception on
> > >
> > > *SiteToolException: The site descriptor cannot be resolved from the
> > > repository: ArtifactResolutionException: Unable to locate site
> descriptor:
> > > Could not transfer artifact org.apache:apache:xml:site_en:13 from/to
> > > mvnrepository.com  (
> https://mvnrepository.com
> > > ): Access denied to:
> > > https://mvnrepository.com/org/apache/apache/13/apache-13-site_en.xml
> > > 
> ,
> > > ReasonPhrase:Forbidden.*
> > >
> > > [*ERROR*] *  org.apache:apache:xml:13*
> > >
> > > [*ERROR*]
> > >
> > > [*ERROR*] *from the specified remote repositories:*
> > >
> > > [*ERROR*] *  restlet.talend.com 
> > > (https://maven.restlet.talend.com ,
> > > releases=true, snapshots=false),*
> > >
> > > [*ERROR*] *  mvnrepository.com 
> > > (https://mvnrepository.com , releases=true,
> > > snapshots=false),*
> > >
> > > [*ERROR*] *  central (https://repo.maven.apache.org/maven2
> > > , releases=true,
> snapshots=false),*
> > >
> > > [*ERROR*] *  apache.snapshots (http://repository.apache.org/snapshots
> > > , releases=false,
> snapshots=true)*
> > >
> > >
> > > Was this recent change? I tried to upgrade to maven site plugin to
> 3.9.1.
> > > It got error on parsing:
> > >
> > > *SiteToolException: Error parsing site descriptor*: TEXT must be
> > > immediately followed by END_TAG and not START_TAG (position: START_TAG
> > > seen
> > > ...\n  

Re: Need help for maven site plugin for Apache Helix

[Hervé BOUTEMY]

FYI, on the "SiteToolException: Error parsing site descriptor: TEXT must 
beimmediately followed by END_TAG and not START_TAG" error, the key Maven Site 
Plugin version is version 3.5, where the parsing of site.xml changed: 
previously it was parser as XML, and since 3.5 it is parsed as text

the consequence is that in general, you need to surround head and footer data 
from site.xml (including parents) with 

that's why Apache parent version is related to maven-site-plugin version

HTH

Hervé

Le samedi 20 novembre 2021, 09:19:41 CET Hervé BOUTEMY a écrit :
> Hi,
> 
> Apache parent 13 is so old...
> 
> see https://github.com/apache/helix/pull/1909
> upgrading both Apache parent POM and maven-site-plugin seems to do the job
> 
> Regards,
> 
> Hervé
> 
> Le jeudi 18 novembre 2021, 00:04:03 CET Junkai Xue a écrit :
> > Hi,
> > 
> > I was trying to deploy Apache Helix project website for new releases. Got
> > exception on
> > 
> > *SiteToolException: The site descriptor cannot be resolved from the
> > repository: ArtifactResolutionException: Unable to locate site descriptor:
> > Could not transfer artifact org.apache:apache:xml:site_en:13 from/to
> > mvnrepository.com  (https://mvnrepository.com
> > ): Access denied to:
> > https://mvnrepository.com/org/apache/apache/13/apache-13-site_en.xml
> >  ,
> > ReasonPhrase:Forbidden.*
> > 
> > [*ERROR*] *  org.apache:apache:xml:13*
> > 
> > [*ERROR*]
> > 
> > [*ERROR*] *from the specified remote repositories:*
> > 
> > [*ERROR*] *  restlet.talend.com 
> > (https://maven.restlet.talend.com ,
> > releases=true, snapshots=false),*
> > 
> > [*ERROR*] *  mvnrepository.com 
> > (https://mvnrepository.com , releases=true,
> > snapshots=false),*
> > 
> > [*ERROR*] *  central (https://repo.maven.apache.org/maven2
> > , releases=true, snapshots=false),*
> > 
> > [*ERROR*] *  apache.snapshots (http://repository.apache.org/snapshots
> > , releases=false, snapshots=true)*
> > 
> > 
> > Was this recent change? I tried to upgrade to maven site plugin to 3.9.1.
> > It got error on parsing:
> > 
> > *SiteToolException: Error parsing site descriptor*: TEXT must be
> > immediately followed by END_TAG and not START_TAG (position: START_TAG
> > seen
> > ...\n  

Re: Need help for maven site plugin for Apache Helix

[Hervé BOUTEMY]

Hi,

Apache parent 13 is so old...

see https://github.com/apache/helix/pull/1909
upgrading both Apache parent POM and maven-site-plugin seems to do the job

Regards,

Hervé

Le jeudi 18 novembre 2021, 00:04:03 CET Junkai Xue a écrit :
> Hi,
> 
> I was trying to deploy Apache Helix project website for new releases. Got
> exception on
> 
> *SiteToolException: The site descriptor cannot be resolved from the
> repository: ArtifactResolutionException: Unable to locate site descriptor:
> Could not transfer artifact org.apache:apache:xml:site_en:13 from/to
> mvnrepository.com  (https://mvnrepository.com
> ): Access denied to:
> https://mvnrepository.com/org/apache/apache/13/apache-13-site_en.xml
>  ,
> ReasonPhrase:Forbidden.*
> 
> [*ERROR*] *  org.apache:apache:xml:13*
> 
> [*ERROR*]
> 
> [*ERROR*] *from the specified remote repositories:*
> 
> [*ERROR*] *  restlet.talend.com 
> (https://maven.restlet.talend.com ,
> releases=true, snapshots=false),*
> 
> [*ERROR*] *  mvnrepository.com 
> (https://mvnrepository.com , releases=true,
> snapshots=false),*
> 
> [*ERROR*] *  central (https://repo.maven.apache.org/maven2
> , releases=true, snapshots=false),*
> 
> [*ERROR*] *  apache.snapshots (http://repository.apache.org/snapshots
> , releases=false, snapshots=true)*
> 
> 
> Was this recent change? I tried to upgrade to maven site plugin to 3.9.1.
> It got error on parsing:
> 
> *SiteToolException: Error parsing site descriptor*: TEXT must be
> immediately followed by END_TAG and not START_TAG (position: START_TAG seen
> ...\n  

Re: Help with Shading on ActiveMQ Artemis

[Clebert Suconic]

; > > >
> > > > > On Tue, Nov 16, 2021, 7:48 PM Clebert Suconic <
> > clebert.suco...@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > I am trying to create a component within ActiveMQ Artemis that
> > would
> > > > > > shade johnzon and javax.json.
> > > > > >
> > > > > > That component should then be used by other components within
> > Artemis.
> > > > > >
> > > > > > I'm doing that because some users want to use javax.json and others
> > > > > > want to use jakarta.json on their runtimes. Since we only use json
> > > > > > internally I am trying to shade our own usage and not relay on
> > either
> > > > > > one of these package names.
> > > > > >
> > > > > >
> > > > > > However I'm getting crazy on this. I can't make shade to hide the
> > > > > > dependency. mvn dependency:tree still shows the libraries. and
> > shade
> > > > > > will not work if I make them provided.e.
> > > > > >
> > > > > >
> > > > > > What is the right way to shade within my own project?
> > > > > >
> > > > > >
> > > > > > I have the project available on my own github fork here:
> > > > > >
> > > > > >
> > https://github.com/clebertsuconic/activemq-artemis/tree/commons-json
> > > > > >
> > > > > > (type this if you can download my branch:
> > > > > >
> > > > > > git clone https://github.com/clebertsuconic/activemq-artemis.git
> > > > > > cd activemq-artemis
> > > > > > git clone commons-json
> > > > > > mvn install -DskipTests=true
> > > > > > mvn dependency:tree
> > > > > >
> > > > > > and here is what gets interesting.
> > > > > > if I go to artemis-selector (a package that relied on
> > > > > > artemis-commons-json) and type mvn dependency:tree on that package,
> > > > > > the dependency does not show up.
> > > > > >
> > > > > >
> > > > > > The issue is only when building the whole project...
> > > > > >
> > > > > >
> > > > > > and I have played with quite a few options! )
> > > > > >
> > > > > >
> > > > > >
> > > > > > Any help would be appreciated ! :)
> > > > > >
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > >
> > -
> > > > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > > > > For additional commands, e-mail: users-h...@maven.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > --
> > > > Clebert Suconic
> > > >
> >
> >
> >
> > --
> > Clebert Suconic
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >



-- 
Clebert Suconic

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Help with Shading on ActiveMQ Artemis

[Matt Benson]

oject?
> > > > >
> > > > >
> > > > > I have the project available on my own github fork here:
> > > > >
> > > > >
> https://github.com/clebertsuconic/activemq-artemis/tree/commons-json
> > > > >
> > > > > (type this if you can download my branch:
> > > > >
> > > > > git clone https://github.com/clebertsuconic/activemq-artemis.git
> > > > > cd activemq-artemis
> > > > > git clone commons-json
> > > > > mvn install -DskipTests=true
> > > > > mvn dependency:tree
> > > > >
> > > > > and here is what gets interesting.
> > > > > if I go to artemis-selector (a package that relied on
> > > > > artemis-commons-json) and type mvn dependency:tree on that package,
> > > > > the dependency does not show up.
> > > > >
> > > > >
> > > > > The issue is only when building the whole project...
> > > > >
> > > > >
> > > > > and I have played with quite a few options! )
> > > > >
> > > > >
> > > > >
> > > > > Any help would be appreciated ! :)
> > > > >
> > > > >
> > > > > Thanks
> > > > >
> > > > >
> -
> > > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > > > For additional commands, e-mail: users-h...@maven.apache.org
> > > > >
> > > > >
> > > >
> > > --
> > > Clebert Suconic
> > >
>
>
>
> --
> Clebert Suconic
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Need help for maven site plugin for Apache Helix

[Olivier Lamy]

not sure what is the content of your ~/.m2/settings.xml but it may have
some references to some repositories?
such http://restlet.talend.com , http://repository.apache.org/snapshots.
note this http
the recent change might be you upgrading to the last maven core version?

[*INFO*] Generating "Dependencies" report---
maven-project-info-reports-plugin:2.9

[*WARNING*] The repository url 'https://mvnrepository.com' is invalid -
Repository 'mvnrepository.com' will be blacklisted.

this mean you should add a mirror in your ~/.m2/settings.xml

If you cannot deploy the website. Let me know and I can do it (I may still
have all karma on helix)

cheers
Olivier
On Thu, 18 Nov 2021 at 09:04, Junkai Xue  wrote:

> Hi,
>
> I was trying to deploy Apache Helix project website for new releases. Got
> exception on
>
> *SiteToolException: The site descriptor cannot be resolved from the
> repository: ArtifactResolutionException: Unable to locate site descriptor:
> Could not transfer artifact org.apache:apache:xml:site_en:13 from/to
> mvnrepository.com  (https://mvnrepository.com
> ): Access denied to:
> https://mvnrepository.com/org/apache/apache/13/apache-13-site_en.xml
>  ,
> ReasonPhrase:Forbidden.*
>
> [*ERROR*] *  org.apache:apache:xml:13*
>
> [*ERROR*]
>
> [*ERROR*] *from the specified remote repositories:*
>
> [*ERROR*] *  restlet.talend.com 
> (https://maven.restlet.talend.com ,
> releases=true, snapshots=false),*
>
> [*ERROR*] *  mvnrepository.com 
> (https://mvnrepository.com , releases=true,
> snapshots=false),*
>
> [*ERROR*] *  central (https://repo.maven.apache.org/maven2
> , releases=true, snapshots=false),*
>
> [*ERROR*] *  apache.snapshots (http://repository.apache.org/snapshots
> , releases=false, snapshots=true)*
>
>
> Was this recent change? I tried to upgrade to maven site plugin to 3.9.1.
> It got error on parsing:
>
> *SiteToolException: Error parsing site descriptor*: TEXT must be
> immediately followed by END_TAG and not START_TAG (position: START_TAG seen
> ...\n  

Re: Need help for maven site plugin for Apache Helix

[Martin Gainty]

caused by outdated reference to a dead codehaus repo
setting codehaus repository enabled=false should mitigate e.g.




HTH
martin

From: Junkai Xue 
Sent: Wednesday, November 17, 2021 6:04 PM
To: users@maven.apache.org 
Subject: Need help for maven site plugin for Apache Helix

Hi,

I was trying to deploy Apache Helix project website for new releases. Got
exception on

*SiteToolException: The site descriptor cannot be resolved from the
repository: ArtifactResolutionException: Unable to locate site descriptor:
Could not transfer artifact org.apache:apache:xml:site_en:13 from/to
mvnrepository.com <http://mvnrepository.com> (https://mvnrepository.com
<https://mvnrepository.com>): Access denied to:
https://mvnrepository.com/org/apache/apache/13/apache-13-site_en.xml
<https://mvnrepository.com/org/apache/apache/13/apache-13-site_en.xml> ,
ReasonPhrase:Forbidden.*

[*ERROR*] *  org.apache:apache:xml:13*

[*ERROR*]

[*ERROR*] *from the specified remote repositories:*

[*ERROR*] *  restlet.talend.com <http://restlet.talend.com>
(https://maven.restlet.talend.com <https://maven.restlet.talend.com>,
releases=true, snapshots=false),*

[*ERROR*] *  mvnrepository.com <http://mvnrepository.com>
(https://mvnrepository.com <https://mvnrepository.com>, releases=true,
snapshots=false),*

[*ERROR*] *  central (https://repo.maven.apache.org/maven2
<https://repo.maven.apache.org/maven2>, releases=true, snapshots=false),*

[*ERROR*] *  apache.snapshots (http://repository.apache.org/snapshots
<http://repository.apache.org/snapshots>, releases=false, snapshots=true)*


Was this recent change? I tried to upgrade to maven site plugin to 3.9.1.
It got error on parsing:

*SiteToolException: Error parsing site descriptor*: TEXT must be
immediately followed by END_TAG and not START_TAG (position: START_TAG seen
...\n  

Need help for maven site plugin for Apache Helix

[Junkai Xue]

Hi,

I was trying to deploy Apache Helix project website for new releases. Got
exception on

*SiteToolException: The site descriptor cannot be resolved from the
repository: ArtifactResolutionException: Unable to locate site descriptor:
Could not transfer artifact org.apache:apache:xml:site_en:13 from/to
mvnrepository.com  (https://mvnrepository.com
): Access denied to:
https://mvnrepository.com/org/apache/apache/13/apache-13-site_en.xml
 ,
ReasonPhrase:Forbidden.*

[*ERROR*] *  org.apache:apache:xml:13*

[*ERROR*]

[*ERROR*] *from the specified remote repositories:*

[*ERROR*] *  restlet.talend.com 
(https://maven.restlet.talend.com ,
releases=true, snapshots=false),*

[*ERROR*] *  mvnrepository.com 
(https://mvnrepository.com , releases=true,
snapshots=false),*

[*ERROR*] *  central (https://repo.maven.apache.org/maven2
, releases=true, snapshots=false),*

[*ERROR*] *  apache.snapshots (http://repository.apache.org/snapshots
, releases=false, snapshots=true)*


Was this recent change? I tried to upgrade to maven site plugin to 3.9.1.
It got error on parsing:

*SiteToolException: Error parsing site descriptor*: TEXT must be
immediately followed by END_TAG and not START_TAG (position: START_TAG seen
...\n  

Re: Help with Shading on ActiveMQ Artemis

[Francois Marot]

Hello Clebert

I hope my comment will help you.
In my experience, using the shade plugin is tricky because the rule of
thumb I came up with is: "your shaded artifacts must be the last artifact
to be built in your multi modules Maven project".
Which can read "you must not depend onto your shaded artifact if shading
happens in the same Maven execution (or Maven reactor)".
You have to have a first execution of Maven to install/deploy your shaded
artifact, and then a second execution can depend onto this shaded artifact.
So you must have 2 different project trees.

Why so much trouble ?
because Maven computes the dependency trees for each module right at the
start of the build, whereas the Shade plugin happens to mess with the
dependency tree in the middle of Maven's execution. Shade plugin is a hack
and therefore extreme care must be taken in its use.
At least that's my understanding after using it for years and having been
bitten numerous times.

Hope it helps




*- - - - -François Marot*



Le mer. 17 nov. 2021 à 15:07, Clebert Suconic  a
écrit :

> Right.. This should happen by default. and it will only work if I'm
> using the shaded jar outside of my project. However if I use it within
> my project it will not work at all.
>
>
> I have created a minimal version of my issue on this github project:
>
>
> https://github.com/clebertsuconic/clebert-shade-issue
>
>
>
> I expect the following line to give me a compilation error:
>
>
> https://github.com/clebertsuconic/clebert-shade-issue/blob/main/artemis-commons/src/main/java/org/apache/activemq/artemis/utils/JsonLoader.java#L38
>
>
> And that shading isolation will only work (that means give me the
> compilation error) if I remove this line from the main pom (after mvn
> install on artemis-commons-json of course):
>
> https://github.com/clebertsuconic/clebert-shade-issue/blob/main/pom.xml#L34
>
>
> if I also call "mvn dependency:tree", you will see the dependency
> listed and not giving the isolation I expected:
>
>
> https://gist.github.com/clebertsuconic/cb025175470a0f429582d3f656b48377#file-gistfile1-txt-L5-L6
>
>
>
>
>
> So, in other words, shading does not work internally. The pom
> replacement will not work through the internal dependency list.
>
> It seems like a bug to me, unless someone finds an explanation?
>
> and how I would be able to achieve this? would anybody know?
>
> On Wed, Nov 17, 2021 at 8:39 AM Matt Benson  wrote:
> >
> >
> https://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#createDependencyReducedPom
> >
> > On Tue, Nov 16, 2021, 10:47 PM Clebert Suconic <
> clebert.suco...@gmail.com>
> > wrote:
> >
> > > I’m not sure how you mean.
> > >
> > > Just get the Pom at the source level or am intermediate build process ?
> > >
> > >
> > > How to do that ?
> > >
> > > On Tue, Nov 16, 2021 at 11:34 PM Matt Benson 
> wrote:
> > >
> > > > You probably want to rewrite the pom, using the property provided by
> the
> > > > shade goal for this purpose.
> > > >
> > > > Matt
> > > >
> > > > On Tue, Nov 16, 2021, 7:48 PM Clebert Suconic <
> clebert.suco...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > I am trying to create a component within ActiveMQ Artemis that
> would
> > > > > shade johnzon and javax.json.
> > > > >
> > > > > That component should then be used by other components within
> Artemis.
> > > > >
> > > > > I'm doing that because some users want to use javax.json and others
> > > > > want to use jakarta.json on their runtimes. Since we only use json
> > > > > internally I am trying to shade our own usage and not relay on
> either
> > > > > one of these package names.
> > > > >
> > > > >
> > > > > However I'm getting crazy on this. I can't make shade to hide the
> > > > > dependency. mvn dependency:tree still shows the libraries. and
> shade
> > > > > will not work if I make them provided.e.
> > > > >
> > > > >
> > > > > What is the right way to shade within my own project?
> > > > >
> > > > >
> > > > > I have the project available on my own github fork here:
> > > > >
> > > > >
> https://github.com/clebertsuconic/activemq-artemis/tree/commons-json
> &

Re: Help with Shading on ActiveMQ Artemis

[Clebert Suconic]

> However I'm getting crazy on this. I can't make shade to hide the
> > > > > > > dependency. mvn dependency:tree still shows the libraries. and 
> > > > > > > shade
> > > > > > > will not work if I make them provided.e.
> > > > > > >
> > > > > > >
> > > > > > > What is the right way to shade within my own project?
> > > > > > >
> > > > > > >
> > > > > > > I have the project available on my own github fork here:
> > > > > > >
> > > > > > > https://github.com/clebertsuconic/activemq-artemis/tree/commons-json
> > > > > > >
> > > > > > > (type this if you can download my branch:
> > > > > > >
> > > > > > > git clone https://github.com/clebertsuconic/activemq-artemis.git
> > > > > > > cd activemq-artemis
> > > > > > > git clone commons-json
> > > > > > > mvn install -DskipTests=true
> > > > > > > mvn dependency:tree
> > > > > > >
> > > > > > > and here is what gets interesting.
> > > > > > > if I go to artemis-selector (a package that relied on
> > > > > > > artemis-commons-json) and type mvn dependency:tree on that 
> > > > > > > package,
> > > > > > > the dependency does not show up.
> > > > > > >
> > > > > > >
> > > > > > > The issue is only when building the whole project...
> > > > > > >
> > > > > > >
> > > > > > > and I have played with quite a few options! )
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Any help would be appreciated ! :)
> > > > > > >
> > > > > > >
> > > > > > > Thanks
> > > > > > >
> > > > > > > -
> > > > > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > > > > > For additional commands, e-mail: users-h...@maven.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > --
> > > > > Clebert Suconic
> > > > >
> > >
> > >
> > >
> > > --
> > > Clebert Suconic
> >
> >
> >
> > --
> > Clebert Suconic
>
>
>
> --
> Clebert Suconic



-- 
Clebert Suconic

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Help with Shading on ActiveMQ Artemis

[Clebert Suconic]

well.. that is a bug:

https://issues.apache.org/jira/browse/MSHADE-269

On Wed, Nov 17, 2021 at 10:57 AM Clebert Suconic
 wrote:
>
> I had to play with optional to have the dependency not picked up internally.
>
> It would be a lot easier if shaded worked internally without requiring
> a downstream dependency.
>
> As a matter of fact,  I just looked on Netty, and they shade
> org.jctools into netty-common, which is the same pattern that I'm
> after, and they also have the same issue in there.
>
> On Wed, Nov 17, 2021 at 9:07 AM Clebert Suconic
>  wrote:
> >
> > Right.. This should happen by default. and it will only work if I'm
> > using the shaded jar outside of my project. However if I use it within
> > my project it will not work at all.
> >
> >
> > I have created a minimal version of my issue on this github project:
> >
> >
> > https://github.com/clebertsuconic/clebert-shade-issue
> >
> >
> >
> > I expect the following line to give me a compilation error:
> >
> > https://github.com/clebertsuconic/clebert-shade-issue/blob/main/artemis-commons/src/main/java/org/apache/activemq/artemis/utils/JsonLoader.java#L38
> >
> >
> > And that shading isolation will only work (that means give me the
> > compilation error) if I remove this line from the main pom (after mvn
> > install on artemis-commons-json of course):
> >
> > https://github.com/clebertsuconic/clebert-shade-issue/blob/main/pom.xml#L34
> >
> >
> > if I also call "mvn dependency:tree", you will see the dependency
> > listed and not giving the isolation I expected:
> >
> > https://gist.github.com/clebertsuconic/cb025175470a0f429582d3f656b48377#file-gistfile1-txt-L5-L6
> >
> >
> >
> >
> >
> > So, in other words, shading does not work internally. The pom
> > replacement will not work through the internal dependency list.
> >
> > It seems like a bug to me, unless someone finds an explanation?
> >
> > and how I would be able to achieve this? would anybody know?
> >
> > On Wed, Nov 17, 2021 at 8:39 AM Matt Benson  wrote:
> > >
> > > https://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#createDependencyReducedPom
> > >
> > > On Tue, Nov 16, 2021, 10:47 PM Clebert Suconic 
> > > wrote:
> > >
> > > > I’m not sure how you mean.
> > > >
> > > > Just get the Pom at the source level or am intermediate build process ?
> > > >
> > > >
> > > > How to do that ?
> > > >
> > > > On Tue, Nov 16, 2021 at 11:34 PM Matt Benson  wrote:
> > > >
> > > > > You probably want to rewrite the pom, using the property provided by 
> > > > > the
> > > > > shade goal for this purpose.
> > > > >
> > > > > Matt
> > > > >
> > > > > On Tue, Nov 16, 2021, 7:48 PM Clebert Suconic 
> > > > >  > > > >
> > > > > wrote:
> > > > >
> > > > > > I am trying to create a component within ActiveMQ Artemis that would
> > > > > > shade johnzon and javax.json.
> > > > > >
> > > > > > That component should then be used by other components within 
> > > > > > Artemis.
> > > > > >
> > > > > > I'm doing that because some users want to use javax.json and others
> > > > > > want to use jakarta.json on their runtimes. Since we only use json
> > > > > > internally I am trying to shade our own usage and not relay on 
> > > > > > either
> > > > > > one of these package names.
> > > > > >
> > > > > >
> > > > > > However I'm getting crazy on this. I can't make shade to hide the
> > > > > > dependency. mvn dependency:tree still shows the libraries. and shade
> > > > > > will not work if I make them provided.e.
> > > > > >
> > > > > >
> > > > > > What is the right way to shade within my own project?
> > > > > >
> > > > > >
> > > > > > I have the project available on my own github fork here:
> > > > > >
> > > > > > https://github.com/clebertsuconic/activemq-artemis/tree/commons-json
> > > > > >
> > > > > > (type this if you can download my branch:
> > > > > >
> > > > > >

Re: Help with Shading on ActiveMQ Artemis

[Clebert Suconic]

I had to play with optional to have the dependency not picked up internally.

It would be a lot easier if shaded worked internally without requiring
a downstream dependency.

As a matter of fact,  I just looked on Netty, and they shade
org.jctools into netty-common, which is the same pattern that I'm
after, and they also have the same issue in there.

On Wed, Nov 17, 2021 at 9:07 AM Clebert Suconic
 wrote:
>
> Right.. This should happen by default. and it will only work if I'm
> using the shaded jar outside of my project. However if I use it within
> my project it will not work at all.
>
>
> I have created a minimal version of my issue on this github project:
>
>
> https://github.com/clebertsuconic/clebert-shade-issue
>
>
>
> I expect the following line to give me a compilation error:
>
> https://github.com/clebertsuconic/clebert-shade-issue/blob/main/artemis-commons/src/main/java/org/apache/activemq/artemis/utils/JsonLoader.java#L38
>
>
> And that shading isolation will only work (that means give me the
> compilation error) if I remove this line from the main pom (after mvn
> install on artemis-commons-json of course):
>
> https://github.com/clebertsuconic/clebert-shade-issue/blob/main/pom.xml#L34
>
>
> if I also call "mvn dependency:tree", you will see the dependency
> listed and not giving the isolation I expected:
>
> https://gist.github.com/clebertsuconic/cb025175470a0f429582d3f656b48377#file-gistfile1-txt-L5-L6
>
>
>
>
>
> So, in other words, shading does not work internally. The pom
> replacement will not work through the internal dependency list.
>
> It seems like a bug to me, unless someone finds an explanation?
>
> and how I would be able to achieve this? would anybody know?
>
> On Wed, Nov 17, 2021 at 8:39 AM Matt Benson  wrote:
> >
> > https://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#createDependencyReducedPom
> >
> > On Tue, Nov 16, 2021, 10:47 PM Clebert Suconic 
> > wrote:
> >
> > > I’m not sure how you mean.
> > >
> > > Just get the Pom at the source level or am intermediate build process ?
> > >
> > >
> > > How to do that ?
> > >
> > > On Tue, Nov 16, 2021 at 11:34 PM Matt Benson  wrote:
> > >
> > > > You probably want to rewrite the pom, using the property provided by the
> > > > shade goal for this purpose.
> > > >
> > > > Matt
> > > >
> > > > On Tue, Nov 16, 2021, 7:48 PM Clebert Suconic  > > >
> > > > wrote:
> > > >
> > > > > I am trying to create a component within ActiveMQ Artemis that would
> > > > > shade johnzon and javax.json.
> > > > >
> > > > > That component should then be used by other components within Artemis.
> > > > >
> > > > > I'm doing that because some users want to use javax.json and others
> > > > > want to use jakarta.json on their runtimes. Since we only use json
> > > > > internally I am trying to shade our own usage and not relay on either
> > > > > one of these package names.
> > > > >
> > > > >
> > > > > However I'm getting crazy on this. I can't make shade to hide the
> > > > > dependency. mvn dependency:tree still shows the libraries. and shade
> > > > > will not work if I make them provided.e.
> > > > >
> > > > >
> > > > > What is the right way to shade within my own project?
> > > > >
> > > > >
> > > > > I have the project available on my own github fork here:
> > > > >
> > > > > https://github.com/clebertsuconic/activemq-artemis/tree/commons-json
> > > > >
> > > > > (type this if you can download my branch:
> > > > >
> > > > > git clone https://github.com/clebertsuconic/activemq-artemis.git
> > > > > cd activemq-artemis
> > > > > git clone commons-json
> > > > > mvn install -DskipTests=true
> > > > > mvn dependency:tree
> > > > >
> > > > > and here is what gets interesting.
> > > > > if I go to artemis-selector (a package that relied on
> > > > > artemis-commons-json) and type mvn dependency:tree on that package,
> > > > > the dependency does not show up.
> > > > >
> > > > >
> > > > > The issue is only when building the whole project...
> > > > >
> > > > >
> > > > > and I have played with quite a few options! )
> > > > >
> > > > >
> > > > >
> > > > > Any help would be appreciated ! :)
> > > > >
> > > > >
> > > > > Thanks
> > > > >
> > > > > -
> > > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > > > For additional commands, e-mail: users-h...@maven.apache.org
> > > > >
> > > > >
> > > >
> > > --
> > > Clebert Suconic
> > >
>
>
>
> --
> Clebert Suconic



-- 
Clebert Suconic

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Help with Shading on ActiveMQ Artemis

[Clebert Suconic]

Right.. This should happen by default. and it will only work if I'm
using the shaded jar outside of my project. However if I use it within
my project it will not work at all.


I have created a minimal version of my issue on this github project:


https://github.com/clebertsuconic/clebert-shade-issue



I expect the following line to give me a compilation error:

https://github.com/clebertsuconic/clebert-shade-issue/blob/main/artemis-commons/src/main/java/org/apache/activemq/artemis/utils/JsonLoader.java#L38


And that shading isolation will only work (that means give me the
compilation error) if I remove this line from the main pom (after mvn
install on artemis-commons-json of course):

https://github.com/clebertsuconic/clebert-shade-issue/blob/main/pom.xml#L34


if I also call "mvn dependency:tree", you will see the dependency
listed and not giving the isolation I expected:

https://gist.github.com/clebertsuconic/cb025175470a0f429582d3f656b48377#file-gistfile1-txt-L5-L6





So, in other words, shading does not work internally. The pom
replacement will not work through the internal dependency list.

It seems like a bug to me, unless someone finds an explanation?

and how I would be able to achieve this? would anybody know?

On Wed, Nov 17, 2021 at 8:39 AM Matt Benson  wrote:
>
> https://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#createDependencyReducedPom
>
> On Tue, Nov 16, 2021, 10:47 PM Clebert Suconic 
> wrote:
>
> > I’m not sure how you mean.
> >
> > Just get the Pom at the source level or am intermediate build process ?
> >
> >
> > How to do that ?
> >
> > On Tue, Nov 16, 2021 at 11:34 PM Matt Benson  wrote:
> >
> > > You probably want to rewrite the pom, using the property provided by the
> > > shade goal for this purpose.
> > >
> > > Matt
> > >
> > > On Tue, Nov 16, 2021, 7:48 PM Clebert Suconic  > >
> > > wrote:
> > >
> > > > I am trying to create a component within ActiveMQ Artemis that would
> > > > shade johnzon and javax.json.
> > > >
> > > > That component should then be used by other components within Artemis.
> > > >
> > > > I'm doing that because some users want to use javax.json and others
> > > > want to use jakarta.json on their runtimes. Since we only use json
> > > > internally I am trying to shade our own usage and not relay on either
> > > > one of these package names.
> > > >
> > > >
> > > > However I'm getting crazy on this. I can't make shade to hide the
> > > > dependency. mvn dependency:tree still shows the libraries. and shade
> > > > will not work if I make them provided.e.
> > > >
> > > >
> > > > What is the right way to shade within my own project?
> > > >
> > > >
> > > > I have the project available on my own github fork here:
> > > >
> > > > https://github.com/clebertsuconic/activemq-artemis/tree/commons-json
> > > >
> > > > (type this if you can download my branch:
> > > >
> > > > git clone https://github.com/clebertsuconic/activemq-artemis.git
> > > > cd activemq-artemis
> > > > git clone commons-json
> > > > mvn install -DskipTests=true
> > > > mvn dependency:tree
> > > >
> > > > and here is what gets interesting.
> > > > if I go to artemis-selector (a package that relied on
> > > > artemis-commons-json) and type mvn dependency:tree on that package,
> > > > the dependency does not show up.
> > > >
> > > >
> > > > The issue is only when building the whole project...
> > > >
> > > >
> > > > and I have played with quite a few options! )
> > > >
> > > >
> > > >
> > > > Any help would be appreciated ! :)
> > > >
> > > >
> > > > Thanks
> > > >
> > > > -
> > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: users-h...@maven.apache.org
> > > >
> > > >
> > >
> > --
> > Clebert Suconic
> >



-- 
Clebert Suconic

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Help with Shading on ActiveMQ Artemis

[Matt Benson]

https://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#createDependencyReducedPom

On Tue, Nov 16, 2021, 10:47 PM Clebert Suconic 
wrote:

> I’m not sure how you mean.
>
> Just get the Pom at the source level or am intermediate build process ?
>
>
> How to do that ?
>
> On Tue, Nov 16, 2021 at 11:34 PM Matt Benson  wrote:
>
> > You probably want to rewrite the pom, using the property provided by the
> > shade goal for this purpose.
> >
> > Matt
> >
> > On Tue, Nov 16, 2021, 7:48 PM Clebert Suconic  >
> > wrote:
> >
> > > I am trying to create a component within ActiveMQ Artemis that would
> > > shade johnzon and javax.json.
> > >
> > > That component should then be used by other components within Artemis.
> > >
> > > I'm doing that because some users want to use javax.json and others
> > > want to use jakarta.json on their runtimes. Since we only use json
> > > internally I am trying to shade our own usage and not relay on either
> > > one of these package names.
> > >
> > >
> > > However I'm getting crazy on this. I can't make shade to hide the
> > > dependency. mvn dependency:tree still shows the libraries. and shade
> > > will not work if I make them provided.e.
> > >
> > >
> > > What is the right way to shade within my own project?
> > >
> > >
> > > I have the project available on my own github fork here:
> > >
> > > https://github.com/clebertsuconic/activemq-artemis/tree/commons-json
> > >
> > > (type this if you can download my branch:
> > >
> > > git clone https://github.com/clebertsuconic/activemq-artemis.git
> > > cd activemq-artemis
> > > git clone commons-json
> > > mvn install -DskipTests=true
> > > mvn dependency:tree
> > >
> > > and here is what gets interesting.
> > > if I go to artemis-selector (a package that relied on
> > > artemis-commons-json) and type mvn dependency:tree on that package,
> > > the dependency does not show up.
> > >
> > >
> > > The issue is only when building the whole project...
> > >
> > >
> > > and I have played with quite a few options! )
> > >
> > >
> > >
> > > Any help would be appreciated ! :)
> > >
> > >
> > > Thanks
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> > >
> >
> --
> Clebert Suconic
>

Re: Help with Shading on ActiveMQ Artemis

[Clebert Suconic]

I’m not sure how you mean.

Just get the Pom at the source level or am intermediate build process ?


How to do that ?

On Tue, Nov 16, 2021 at 11:34 PM Matt Benson  wrote:

> You probably want to rewrite the pom, using the property provided by the
> shade goal for this purpose.
>
> Matt
>
> On Tue, Nov 16, 2021, 7:48 PM Clebert Suconic 
> wrote:
>
> > I am trying to create a component within ActiveMQ Artemis that would
> > shade johnzon and javax.json.
> >
> > That component should then be used by other components within Artemis.
> >
> > I'm doing that because some users want to use javax.json and others
> > want to use jakarta.json on their runtimes. Since we only use json
> > internally I am trying to shade our own usage and not relay on either
> > one of these package names.
> >
> >
> > However I'm getting crazy on this. I can't make shade to hide the
> > dependency. mvn dependency:tree still shows the libraries. and shade
> > will not work if I make them provided.e.
> >
> >
> > What is the right way to shade within my own project?
> >
> >
> > I have the project available on my own github fork here:
> >
> > https://github.com/clebertsuconic/activemq-artemis/tree/commons-json
> >
> > (type this if you can download my branch:
> >
> > git clone https://github.com/clebertsuconic/activemq-artemis.git
> > cd activemq-artemis
> > git clone commons-json
> > mvn install -DskipTests=true
> > mvn dependency:tree
> >
> > and here is what gets interesting.
> > if I go to artemis-selector (a package that relied on
> > artemis-commons-json) and type mvn dependency:tree on that package,
> > the dependency does not show up.
> >
> >
> > The issue is only when building the whole project...
> >
> >
> > and I have played with quite a few options! )
> >
> >
> >
> > Any help would be appreciated ! :)
> >
> >
> > Thanks
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>
-- 
Clebert Suconic

Re: Help with Shading on ActiveMQ Artemis

[Matt Benson]

You probably want to rewrite the pom, using the property provided by the
shade goal for this purpose.

Matt

On Tue, Nov 16, 2021, 7:48 PM Clebert Suconic 
wrote:

> I am trying to create a component within ActiveMQ Artemis that would
> shade johnzon and javax.json.
>
> That component should then be used by other components within Artemis.
>
> I'm doing that because some users want to use javax.json and others
> want to use jakarta.json on their runtimes. Since we only use json
> internally I am trying to shade our own usage and not relay on either
> one of these package names.
>
>
> However I'm getting crazy on this. I can't make shade to hide the
> dependency. mvn dependency:tree still shows the libraries. and shade
> will not work if I make them provided.e.
>
>
> What is the right way to shade within my own project?
>
>
> I have the project available on my own github fork here:
>
> https://github.com/clebertsuconic/activemq-artemis/tree/commons-json
>
> (type this if you can download my branch:
>
> git clone https://github.com/clebertsuconic/activemq-artemis.git
> cd activemq-artemis
> git clone commons-json
> mvn install -DskipTests=true
> mvn dependency:tree
>
> and here is what gets interesting.
> if I go to artemis-selector (a package that relied on
> artemis-commons-json) and type mvn dependency:tree on that package,
> the dependency does not show up.
>
>
> The issue is only when building the whole project...
>
>
> and I have played with quite a few options! )
>
>
>
> Any help would be appreciated ! :)
>
>
> Thanks
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Help with Shading on ActiveMQ Artemis

[Clebert Suconic]

I am trying to create a component within ActiveMQ Artemis that would
shade johnzon and javax.json.

That component should then be used by other components within Artemis.

I'm doing that because some users want to use javax.json and others
want to use jakarta.json on their runtimes. Since we only use json
internally I am trying to shade our own usage and not relay on either
one of these package names.


However I'm getting crazy on this. I can't make shade to hide the
dependency. mvn dependency:tree still shows the libraries. and shade
will not work if I make them provided.e.


What is the right way to shade within my own project?


I have the project available on my own github fork here:

https://github.com/clebertsuconic/activemq-artemis/tree/commons-json

(type this if you can download my branch:

git clone https://github.com/clebertsuconic/activemq-artemis.git
cd activemq-artemis
git clone commons-json
mvn install -DskipTests=true
mvn dependency:tree

and here is what gets interesting.
if I go to artemis-selector (a package that relied on
artemis-commons-json) and type mvn dependency:tree on that package,
the dependency does not show up.


The issue is only when building the whole project...


and I have played with quite a few options! )



Any help would be appreciated ! :)


Thanks

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Reporting in maven. help please

[Bernd Eckenfels]

Hello,

There are a number of static code analyses which also happen to have a maven 
plugin (with sire reporting integration), for example pmd, findbugs/spotbugs, 
checker framework, checkstyle, (static-Code-analysis) Javancss, taglist, l10n 
status, jdepend and dependency-Check, and a few external tools with maven 
integration like sonarqube, lgtm or Snyk, see also here 
https://maven.apache.org/code-quality-management.html

Most of those plugins are best used when you have a matching CI plugin to 
record long term trends or if they have their own database (like sonarqube).

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Aitor Iturriondobeitia 
Gesendet: Sunday, November 29, 2020 6:47:13 PM
An: Maven Users List 
Betreff: Reporting in maven. help please

Hello
i am new using maven and i am reading documentation.
Can you say me which plugins can i use for reporting the code quality?
any example?
thanks

Re: Reporting in maven. help please

[John Patrick]

Is this the documentation you said you are reading
https://maven.apache.org/plugins/index.html, as it has a reporting
section for maven maintained plugins.

but to highlight some, take a look at;
checkstyle https://maven.apache.org/plugins/maven-checkstyle-plugin/
pmd/cpd https://maven.apache.org/plugins/maven-pmd-plugin/
spotbugs (was findbugs) https://spotbugs.github.io/spotbugs-maven-plugin/

harder setup as requires installing separate tooling, and most overlap
with checkstyle, pmd and sportbugs in the free version.
sonarqube 
https://docs.sonarqube.org/latest/analysis/scan/sonarscanner-for-maven/

for your dependencies look at owasp and
https://jeremylong.github.io/DependencyCheck/dependency-check-maven/index.html

If you're on github or bitbucket and are an open source project then
they have lots of both apps or integration tooling that can check
dependencies, code coverage. But if it's a closed private repo then it
will cost you something $$$ per month.

John

On Sun, 29 Nov 2020 at 17:47, Aitor Iturriondobeitia
 wrote:
>
> Hello
> i am new using maven and i am reading documentation.
> Can you say me which plugins can i use for reporting the code quality?
> any example?
> thanks

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Reporting in maven. help please

[Aitor Iturriondobeitia]

Hello
i am new using maven and i am reading documentation.
Can you say me which plugins can i use for reporting the code quality?
any example?
thanks

Re: Need help: maven-javadoc-plugin: includeDependencySource: error: module not found on module source path

[Benjamin Marwell]

Hi Thomas,

I investigated a bit further. It seems from the debug output, that the
remote sources were fetched.  Thus, the error seems misleading:

[DEBUG] Expanding:
$USER/.m2/repository/de/uni-stuttgart/informatik/fius/ICGE-Simulation/2.3.6/ICGE-Simulation-2.3.6-sources.jar
into 
$USER/git/apache/jvk/project/target/distro-javadoc-sources/ICGE-Simulation-2.3.6-sources
[DEBUG] Trying to add links for modules...
[ERROR] no reactor project: de.uni-stuttgart.informatik.fius:ICGE-Simulation


So I tried to add this path manually like this:


org.apache.maven.plugins
maven-javadoc-plugin
-   3.1.1
+   3.2.0


--show-packages=all

de.unistuttgart.informatik.fius.jvk.tasks:de.unistuttgart.informatik.fius.jvk.verifier
+
true

true


https://fius.github.io/ICGE2/${icge.version}

+
${sourcepath}:target/distro-javadoc-sources/ICGE-Simulation-2.3.6-sources




And:
BUILD SUCCESS

So I think you found a bug where module sources are not being added to
the javadoc source path AND there is a misleading error message.
Would you kindly open two issues?

Am Mi., 28. Okt. 2020 um 20:18 Uhr schrieb Benjamin Marwell
:
>
> Hi Tim,
>
> this lines makes me wonder:
>
> > [ERROR] no reactor project:  > of my project>
>
> I think this means that  will only work with
> dependencies from the same reactor project. Thus your
> "group_id:artifact_id of the single dependency of my project" seems to
> be a foreign project?
>
> But then from the goal description [1] it does not mention "must be on
> the same reactor project".
> Do you see a message that "group_id:artifact_id:source:jar could not
> be fetched" or similar?
>
>
> [1] https://maven.apache.org/plugins/maven-javadoc-plugin/aggregate-mojo.html
>
> Am Sa., 17. Okt. 2020 um 18:08 Uhr schrieb Tim Neumann
> :
> >
> > Hello everybody,
> >
> > I'm struggling to get javadoc generation with includeDependencySource
> > working in my project.
> >
> > When setting includeDependencySource to true in the pom and running mvn
> > clean install javadoc:aggregate or mvn clean install javadoc:javadoc
> >
> > I get the following errors:
> >
> > First: [ERROR] no reactor project:  > dependency of my project>
> >
> > And a few lines later a BUILD FAILURE because the javadoc tool exited
> > with the following error:
> > Exit code: 1 -
> > /path/to/my/project/target/distro-javadoc-sources/--sources/module-info.java:10:
> > error: module not found on module source path
> >
> > But the source of the dependency seems to be fetched and unpacked
> > correctly to
> > /path/to/my/project/target/distro-javadoc-sources/--sources/
> > The line (10) where the error is is the module definition of the single
> > in that project.
> >
> > The generated javdoc options file contains only one module-source-path:
> > /path/to/my/project/target/site/apidocs/src which contains a single
> > empty folder named like the module of my project (not the dependency).
> >
> > Did anyone have a similar problem before? Any ideas what to try?
> >
> > If anyone wants to look at the whole pom or try to reproduce it, the
> > project is on github: https://github.com/fius/jvk in the folder project.
> > The only dependency of that project is also on github:
> > https://github.com/FIUS/ICGE2
> > For trying to get this to work I made some changes to both, which are
> > not merged yet. See these pull-requests:
> > https://github.com/FIUS/ICGE2/pull/186 and
> > https://github.com/FIUS/jvk/pull/71
> > For this testing I'm using version 2.3.5-Snapshot of the dependency and
> > just locally running mvn clean install in it instead of uploading it to
> > a maven repository.
> >
> > Regards,
> > Tim
> >
> > --
> > Tim Neumann (GPG-Key: B5BD 17C3 BD4A 7BA4)
> > stv. Referent für IT Betreung
> > Studierendenvertretung Uni Stuttgart
> > https://stuvus.uni-stuttgart.de
> >
> >
> >
> > -
> > 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: Need help: maven-javadoc-plugin: includeDependencySource: error: module not found on module source path

[Benjamin Marwell]

Hi Tim,

this lines makes me wonder:

> [ERROR] no reactor project:  my project>

I think this means that  will only work with
dependencies from the same reactor project. Thus your
"group_id:artifact_id of the single dependency of my project" seems to
be a foreign project?

But then from the goal description [1] it does not mention "must be on
the same reactor project".
Do you see a message that "group_id:artifact_id:source:jar could not
be fetched" or similar?


[1] https://maven.apache.org/plugins/maven-javadoc-plugin/aggregate-mojo.html

Am Sa., 17. Okt. 2020 um 18:08 Uhr schrieb Tim Neumann
:
>
> Hello everybody,
>
> I'm struggling to get javadoc generation with includeDependencySource
> working in my project.
>
> When setting includeDependencySource to true in the pom and running mvn
> clean install javadoc:aggregate or mvn clean install javadoc:javadoc
>
> I get the following errors:
>
> First: [ERROR] no reactor project:  dependency of my project>
>
> And a few lines later a BUILD FAILURE because the javadoc tool exited
> with the following error:
> Exit code: 1 -
> /path/to/my/project/target/distro-javadoc-sources/--sources/module-info.java:10:
> error: module not found on module source path
>
> But the source of the dependency seems to be fetched and unpacked
> correctly to
> /path/to/my/project/target/distro-javadoc-sources/--sources/
> The line (10) where the error is is the module definition of the single
> in that project.
>
> The generated javdoc options file contains only one module-source-path:
> /path/to/my/project/target/site/apidocs/src which contains a single
> empty folder named like the module of my project (not the dependency).
>
> Did anyone have a similar problem before? Any ideas what to try?
>
> If anyone wants to look at the whole pom or try to reproduce it, the
> project is on github: https://github.com/fius/jvk in the folder project.
> The only dependency of that project is also on github:
> https://github.com/FIUS/ICGE2
> For trying to get this to work I made some changes to both, which are
> not merged yet. See these pull-requests:
> https://github.com/FIUS/ICGE2/pull/186 and
> https://github.com/FIUS/jvk/pull/71
> For this testing I'm using version 2.3.5-Snapshot of the dependency and
> just locally running mvn clean install in it instead of uploading it to
> a maven repository.
>
> Regards,
> Tim
>
> --
> Tim Neumann (GPG-Key: B5BD 17C3 BD4A 7BA4)
> stv. Referent für IT Betreung
> Studierendenvertretung Uni Stuttgart
> https://stuvus.uni-stuttgart.de
>
>
>
> -
> 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

Need help: maven-javadoc-plugin: includeDependencySource: error: module not found on module source path

[Tim Neumann]

Hello everybody,

I'm struggling to get javadoc generation with includeDependencySource
working in my project.

When setting includeDependencySource to true in the pom and running mvn
clean install javadoc:aggregate or mvn clean install javadoc:javadoc

I get the following errors:

First: [ERROR] no reactor project: 

And a few lines later a BUILD FAILURE because the javadoc tool exited
with the following error:
Exit code: 1 -
/path/to/my/project/target/distro-javadoc-sources/--sources/module-info.java:10:
error: module not found on module source path

But the source of the dependency seems to be fetched and unpacked
correctly to
/path/to/my/project/target/distro-javadoc-sources/--sources/
The line (10) where the error is is the module definition of the single
in that project.

The generated javdoc options file contains only one module-source-path:
/path/to/my/project/target/site/apidocs/src which contains a single
empty folder named like the module of my project (not the dependency).

Did anyone have a similar problem before? Any ideas what to try?

If anyone wants to look at the whole pom or try to reproduce it, the
project is on github: https://github.com/fius/jvk in the folder project.
The only dependency of that project is also on github:
https://github.com/FIUS/ICGE2
For trying to get this to work I made some changes to both, which are
not merged yet. See these pull-requests:
https://github.com/FIUS/ICGE2/pull/186 and
https://github.com/FIUS/jvk/pull/71
For this testing I'm using version 2.3.5-Snapshot of the dependency and
just locally running mvn clean install in it instead of uploading it to
a maven repository.

Regards,
Tim

-- 
Tim Neumann (GPG-Key: B5BD 17C3 BD4A 7BA4)  
stv. Referent für IT Betreung
Studierendenvertretung Uni Stuttgart
https://stuvus.uni-stuttgart.de



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Need help with maven deploy plugin.

[John Patrick]

Which pom are properties beans.version and rest.version defined?

com.blah.nw.libraries:libraries:1.0.0 or it's parent?

Technically what you're deploying and using looks valid, the consumed
using them should resolve those dependencies and pick up your custom
version property and work it out dynamically.

I've just created a mini project and mine seems to be working how you
want it to do, but i'm deploying to a local directory and not into
artifactory/nexus.

Normally in a multi module project, I collate all dependency version
details into the root multi module parent pom under the
dependencyManagement section. So multi module children only define use
x but never use version y of x.

John

On Wed, 19 Aug 2020 at 08:01, Jai Sharma  wrote:
>
> I am trying to upload multiple jar files to artifactory using "mvn deploy" 
> command for a multi module project. Problem I am facing is generated pom 
> files uploaded with jar files to artifactory contains only property name as 
> version.
>
> Example - This is the part of jar file uploaded to artifactory for module 
> "configuration-entity".
> When i am using this as dependency in another project I am getting error 
> cannot resolve dependencies
> com.blah.infra.libraries:rest:jar:${rest.version}
> com.blah.infra.libraries:beans:jar:${beans.version}
>
> 
> 
>
> 4.0.0
>
> 
> com.blah.nw.libraries
> libraries
> 1.0.0
> 
>
> configuration-entity
>
> 
> 
> com.blah.infra.libraries
> rest
> ${rest.version}
> 
> 
> com.blah.infra.libraries
> beans
> ${beans.version}
> 
>
>
>
> -
> 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

Need help with maven deploy plugin.

[Jai Sharma]

I am trying to upload multiple jar files to artifactory using "mvn deploy" 
command for a multi module project. Problem I am facing is generated pom files 
uploaded with jar files to artifactory contains only property name as version.

Example - This is the part of jar file uploaded to artifactory for module 
"configuration-entity".
When i am using this as dependency in another project I am getting error cannot 
resolve dependencies 
com.blah.infra.libraries:rest:jar:${rest.version}
com.blah.infra.libraries:beans:jar:${beans.version}




4.0.0


com.blah.nw.libraries
libraries
1.0.0


configuration-entity



com.blah.infra.libraries
rest
${rest.version}


com.blah.infra.libraries
beans
${beans.version}




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Help with shading jar

[Russell Gold]

Are they part of the same build?

Can you create a minimal example and post it to GitHub? There’s really not 
enough detail to understand what you are trying to do.

> On Jul 2, 2020, at 5:18 PM, Quiyan H  wrote:
> 
> Hi All
> I am stuck with one shading stuff, Need help if there is known way out.
> I have a project module which has bunch of dependencies and I want to shade
> and relocate one of the dependency. I did that, but the problem is the
> other dependency also uses the dependency that I shaded, but that doesn’t
> use the relocated class, is there any way to make the other dependency use
> the relocated shaded class instead of the original.
> The catch is I can’t shade this other dependency due to other conflicts.
> 
> Module
> DependencyA (uses dependency B as well)
> DependencyB (shaded and relocated)
> 
> Want to make dependency A use relocated classes in the Module rather than
> direct dependency B
> 
> Any help, even if it is something which can not be done, Please let me
> know!!!
> 
> Waiting for a response!!!


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Help with shading jar

[Quiyan H]

Any idea or solutions??

On Friday, July 3, 2020, Quiyan H  wrote:

> Hi All
> I am stuck with one shading stuff, Need help if there is known way out.
> I have a project module which has bunch of dependencies and I want to
> shade and relocate one of the dependency. I did that, but the problem is
> the other dependency also uses the dependency that I shaded, but that
> doesn’t use the relocated class, is there any way to make the other
> dependency use the relocated shaded class instead of the original.
> The catch is I can’t shade this other dependency due to other conflicts.
>
> Module
> DependencyA (uses dependency B as well)
> DependencyB (shaded and relocated)
>
> Want to make dependency A use relocated classes in the Module rather than
> direct dependency B
>
> Any help, even if it is something which can not be done, Please let me
> know!!!
>
> Waiting for a response!!!
>

Re: Help with shading jar

[Alexander Kriegisch]

I think some more detail and an actual sample project [1] would be more helpful 
than just prose. I am by no means an expert in the subject matter, but just 
last week I struggled with shading and package relocation too, so from what I 
still remember I might be able to help if I could reproduce your problem.

[1] [MCVE](https://stackoverflow.com/help/mcve)
-- 
Alexander Kriegisch
https://scrum-master.de


Quiyan H schrieb am 03.07.2020 04:18 (GMT +07:00):

> Hi All
> I am stuck with one shading stuff, Need help if there is known way out.
> I have a project module which has bunch of dependencies and I want to shade
> and relocate one of the dependency. I did that, but the problem is the
> other dependency also uses the dependency that I shaded, but that doesn’t
> use the relocated class, is there any way to make the other dependency use
> the relocated shaded class instead of the original.
> The catch is I can’t shade this other dependency due to other conflicts.
> 
> Module
> DependencyA (uses dependency B as well)
> DependencyB (shaded and relocated)
> 
> Want to make dependency A use relocated classes in the Module rather than
> direct dependency B
> 
> Any help, even if it is something which can not be done, Please let me
> know!!!
> 
> Waiting for a response!!!
> 

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Help with shading jar

[Quiyan H]

Hi All
I am stuck with one shading stuff, Need help if there is known way out.
I have a project module which has bunch of dependencies and I want to shade
and relocate one of the dependency. I did that, but the problem is the
other dependency also uses the dependency that I shaded, but that doesn’t
use the relocated class, is there any way to make the other dependency use
the relocated shaded class instead of the original.
The catch is I can’t shade this other dependency due to other conflicts.

Module
DependencyA (uses dependency B as well)
DependencyB (shaded and relocated)

Want to make dependency A use relocated classes in the Module rather than
direct dependency B

Any help, even if it is something which can not be done, Please let me
know!!!

Waiting for a response!!!

[ANN] Apache Maven Help Plugin 3.2.0 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache Maven 
Help Plugin, version 3.2.0

The Maven Help Plugin is used to get relative information about a project or 
the system. It can be used to get a description of a particular plugin, 
including the plugin's goals with their parameters and component requirements, 
the effective POM and effective settings of the current build, and the 
profiles applied to the current project being built.

https://maven.apache.org/plugins/maven-help-plugin/

You should specify the version in your project's plugin configuration:


org.apache.maven.plugins
maven-help-plugin
3.2.0


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/plugins/maven-help-plugin/download.cgi


Release Notes - Maven Help Plugin - Version 3.2.0

** New Feature
* [MPH-160] - help:effective-pom -Dverbose: add source location as 
comments in effective pom.xml

** Improvement
* [MPH-161] - add color to goal or plugin description

Enjoy,

-The Apache Maven team



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Need help.. How to configure POM for multi-module checkout

[garym]

Yeah,  that's a good idea... 

On 2019/03/24 14:38:25, Kyle Marek  wrote: 
> You can arbitrarily switch to other tags and branches with submodules.
> It is just a simple `git checkout X` from the submodule's directory.
> 
> -Kyle
> 
> On 3/24/19 9:51 AM, ga...@oedata.com wrote:
> > Hi Nick,
> >
> > Thank you for that suggestion. That was also suggested on stackoverflow by 
> > Karl. That method is better suited for static-ish configurations.   I need 
> > a BOM type system where I can dynamically switch between tags and branches 
> > for different modules, much like clear case.  I'll be moving to a different 
> > structure and tool chain in 6 months.
> >
> > cheer
> >
> > On 2019/03/24 01:45:50, Kyle Marek  wrote: 
> >> Not sure that it will help with version number matches, but you could
> >> also use Git submodules to bring multiple repositories together in a
> >> single tree.
> >>
> >> See: https://git-scm.com/book/en/v2/Git-Tools-Submodules
> >>
> >> On 3/23/19 9:26 PM, ga...@oedata.com wrote:
> >>> Hi Karl,
> >>>
> >>> Thank you for replying on mail server. and thanks for sending me the 
> >>> links to you project poms. They look awesome.
> >>>
> >>> The is a difference between your projects and my situation. Your projects 
> >>> all the modules reside in the same repository. In my case, they reside in 
> >>> different repositories.  
> >>>
> >>> I elected to use the scm plugin because it allows me to select branches 
> >>> and tags, based on the project and development requirements. I didn't 
> >>> suspect reactor would check for poms before executing the life cycle. 
> >>>
> >>> I'm sure this has been solved  by someone in the past. I just don't know 
> >>> how to solve it using maven. I can solve it with a bunch of execute 
> >>> blocks, but that is very ugly. I'm going to look at the release plugin 
> >>> and a few others
> >>>
> >>> It's likely I'm using the wrong plugin or I'm missing a plugin. 
> >>>
> >>> BTW, I like your iterator plugin 
> >>>
> >>> cheers
> >>> gary
> >>>
> >>>
> >>>
> >>>
> >>> On 2019/03/23 23:56:48, Karl Heinz Marbaise  wrote: 
> >>>> Hi,
> >>>>
> >>>> I will give you the same answer as on StackOverflow.
> >>>>
> >>>> The way you are going sounds wrong...
> >>>>
> >>>> As I already suggested is the way to go creating a multi module build
> >>>> which comprises of several modules which is located within a single Git
> >>>> repository. this can be build by using a single command.
> >>>>
> >>>>
> >>>> mvn clean package
> >>>>
> >>>> from the root location..
> >>>>
> >>>> https://github.com/khmarbaise/javaee
> >>>> https://github.com/khmarbaise/supose
> >>>>
> >>>> Kind regards
> >>>> Karl Heinz Marbaise
> >>>>
> >>>> On 24.03.19 00:35, Gary M wrote:
> >>>>> Hi,
> >>>>>
> >>>>> I need some help with scm checking out multiple modules and building 
> >>>>> them.
> >>>>> I have several projects I'm consolidating into  a single jar.  Reactor
> >>>>> checks for module poms before generate-sources executes.
> >>>>>
> >>>>> How do I fix this issue ?
> >>>>>
> >>>>> thanks..
> >>>>> g
> >>>>>
> >>>>> POM sample to give you an idea of what I've done.
> >>>>>
> >>>>>  
> >>>>>org.apache.maven.plugins
> >>>>>maven-scm-plugin
> >>>>>1.9.4
> >>>>>
> >>>>>  
> >>>>>mod-1
> >>>>>generate-sources
> >>>>>
> >>>>>  ${mod-1.url}
> >>>>>  ${mod-1.versionType}
> >>>>>  ${mod-1.version}
> >>>>>  ${mod-1.directory}
> >>>>>
> >>>>>
> >>>>>  checkout
> >>>>>
> >>>>>  
> >>>>>  
> >>>>>mod-2
> >>>>>generate-sources
> >>>>>
> >>>>>  ${mod-2.url}
> >>>>>  ${mod-2.versionType}
> >>>>>  ${mod-2.version}
> >>>>>  ${mod-2.directory}
> >>>>>
> >>>>>
> >>>>>  checkout
> >>>>>
> >>>>>  
> >>>>>
> >>>>>
> >>>>> .
> >>>>>
> >>>>> 
> >>>>>
> >>>> -
> >>>> 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
> >>
> > -
> > 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: Need help.. How to configure POM for multi-module checkout

[garym]

Hi Karl,

Thank you for the suggestion to use maven-shade/maven-assembly-plugin(s).

I was planning to use them, but haven't gotten around to them yet.  I was hung 
up on the checkout/build thing. :- Maybe on Tuesday.

The libraries are in 7 modules to manage the development cycle, specifically 
functional and unit testing.

The aggregate library.jar will not have test cases other than one per library 
to ensure each module was included in the library.jar.

The BOM file is the way I'm going as per your suggestion. 

cheers,
gary


On 2019/03/24 21:45:37, Karl Heinz Marbaise  wrote: 
> Hi Gary,
> 
> On 24.03.19 17:55, ga...@oedata.com wrote:
> > Hi Nick,
> >
> > Thanks for the questions, I'll try to explain.
> >
> > The parent pom aggregates a library (jar) from different and sometimes 
> > interdependent  modules. The parent pom checks out the module sources with 
> > the poms and compiles them into a single jar.
> 
> 
> Maybe I misunderstand a thing here. But it sounds as if you have a
> resulting library which results in a single jar? Let us ignore at the
> first place the checkout things etc.
> 
> Basicly I would say if your result is a single jar you usually have a
> single maven project?
> 
> If your result is a single jar which is combined from different modules
> I would reconsider the architecture cause usually it's better having
> separated modules like *-api, *-core etc. and may be a supplemental
> thing could be a shaded-jar which combines several of them...
> 
> Having seperated modules make testing easier which means you can put
> your unit tests into the appropriate module etc.
> 
> Do you use maven-shade/maven-assembly-plugin?
> 
> If you like to produce a BOM file. The usualy way is to make a separate
> module which contains simply the dependencyManagement with mentioning
> the modules it should contain.
> 
> Kind regards
> Karl Heinz Marbaise
> 
> 
> -
> 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: Need help.. How to configure POM for multi-module checkout

[Karl Heinz Marbaise]

Hi Gary,

On 24.03.19 17:55, ga...@oedata.com wrote:

Hi Nick,

Thanks for the questions, I'll try to explain.

The parent pom aggregates a library (jar) from different and sometimes 
interdependent  modules. The parent pom checks out the module sources with the 
poms and compiles them into a single jar.



Maybe I misunderstand a thing here. But it sounds as if you have a
resulting library which results in a single jar? Let us ignore at the
first place the checkout things etc.

Basicly I would say if your result is a single jar you usually have a
single maven project?

If your result is a single jar which is combined from different modules
I would reconsider the architecture cause usually it's better having
separated modules like *-api, *-core etc. and may be a supplemental
thing could be a shaded-jar which combines several of them...

Having seperated modules make testing easier which means you can put
your unit tests into the appropriate module etc.

Do you use maven-shade/maven-assembly-plugin?

If you like to produce a BOM file. The usualy way is to make a separate
module which contains simply the dependencyManagement with mentioning
the modules it should contain.

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: Need help.. How to configure POM for multi-module checkout

[garym]

Hi Nick,

Thanks for the questions, I'll try to explain.

The parent pom aggregates a library (jar) from different and sometimes 
interdependent  modules. The parent pom checks out the module sources with the 
poms and compiles them into a single jar.

I was using the modules pattern in in the parent pom to make the BOM easier 
(less confusing) to manage. I was also using scm plugin for multi-module 
checkouts.  Independently, multi-module builds and multi-module checkouts work 
perfectly. 

When I mix the SCM plugin with the multi-module build, reactor first checks if 
the module's poms exist prior to checkout. I was wondering whether there was a 
way to defer the pom check until after checkout. After reviewing reactor code, 
I found that is not possible without changes.

It looks like the release plugin interacts with reactor in a complimentary 
process. 


On 2019/03/24 11:31:28, Nikki Novak  wrote: 
> Gary,
> 
> Having modules residing in other repositories is not a problem...
> 
> ...but why do they not have a pom.xml ?
> 
> ...Is the POM on a different branch ?
> ...Are the modules using ANT or gradle instead ?
> ...Are you auto-generating POMs ?
> 
> Like, I'm really scratching my head trying to figure out what is going on 
> here ?
> 
> If the only thing you need to do is checkout, then you could add a git 
> submodule and add the folder to the maven aggregator ?
> The git submodule always points to a specific commit (until you update the 
> reference).
> 
> Would that be a viable option for your purpose(s) ?
> 
> Nick
> 
> 
> From: garym@ 
> Sent: Sunday, March 24, 2019 1:26 AM
> To: users@maven.apache.org
> Subject: Re: Need help.. How to configure POM for multi-module checkout
> 
> Hi Karl,
> 
> Thank you for replying on mail server. and thanks for sending me the links to 
> you project poms. They look awesome.
> 
> The is a difference between your projects and my situation. Your projects all 
> the modules reside in the same repository. In my case, they reside in 
> different repositories.
> 
> I elected to use the scm plugin because it allows me to select branches and 
> tags, based on the project and development requirements. I didn't suspect 
> reactor would check for poms before executing the life cycle.
> 
> I'm sure this has been solved  by someone in the past. I just don't know how 
> to solve it using maven. I can solve it with a bunch of execute blocks, but 
> that is very ugly. I'm going to look at the release plugin and a few others
> 
> It's likely I'm using the wrong plugin or I'm missing a plugin.
> 
> BTW, I like your iterator plugin
> 
> cheers
> gary
> 
> 
> 
> 
> On 2019/03/23 23:56:48, Karl Heinz Marbaise  wrote:
> > Hi,
> >
> > I will give you the same answer as on StackOverflow.
> >
> > The way you are going sounds wrong...
> >
> > As I already suggested is the way to go creating a multi module build
> > which comprises of several modules which is located within a single Git
> > repository. this can be build by using a single command.
> >
> >
> > mvn clean package
> >
> > from the root location..
> >
> > https://github.com/khmarbaise/javaee
> > https://github.com/khmarbaise/supose
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > On 24.03.19 00:35, Gary M wrote:
> > > Hi,
> > >
> > > I need some help with scm checking out multiple modules and building them.
> > > I have several projects I'm consolidating into  a single jar.  Reactor
> > > checks for module poms before generate-sources executes.
> > >
> > > How do I fix this issue ?
> > >
> > > thanks..
> > > g
> > >
> > > POM sample to give you an idea of what I've done.
> > >
> > >  
> > >org.apache.maven.plugins
> > >maven-scm-plugin
> > >1.9.4
> > >
> > >  
> > >mod-1
> > >generate-sources
> > >
> > >  ${mod-1.url}
> > >  ${mod-1.versionType}
> > >  ${mod-1.version}
> > >  ${mod-1.directory}
> > >
> > >
> > >  checkout
> > >
> > >  
> > >  
> > >mod-2
> > >generate-sources
> > >
> > >  ${mod-2.url}
> > >  ${mod-2.versionType}
> > >

Re: Need help.. How to configure POM for multi-module checkout

[Kyle Marek]

You can arbitrarily switch to other tags and branches with submodules.
It is just a simple `git checkout X` from the submodule's directory.

-Kyle

On 3/24/19 9:51 AM, ga...@oedata.com wrote:
> Hi Nick,
>
> Thank you for that suggestion. That was also suggested on stackoverflow by 
> Karl. That method is better suited for static-ish configurations.   I need a 
> BOM type system where I can dynamically switch between tags and branches for 
> different modules, much like clear case.  I'll be moving to a different 
> structure and tool chain in 6 months.
>
> cheer
>
> On 2019/03/24 01:45:50, Kyle Marek  wrote: 
>> Not sure that it will help with version number matches, but you could
>> also use Git submodules to bring multiple repositories together in a
>> single tree.
>>
>> See: https://git-scm.com/book/en/v2/Git-Tools-Submodules
>>
>> On 3/23/19 9:26 PM, ga...@oedata.com wrote:
>>> Hi Karl,
>>>
>>> Thank you for replying on mail server. and thanks for sending me the links 
>>> to you project poms. They look awesome.
>>>
>>> The is a difference between your projects and my situation. Your projects 
>>> all the modules reside in the same repository. In my case, they reside in 
>>> different repositories.  
>>>
>>> I elected to use the scm plugin because it allows me to select branches and 
>>> tags, based on the project and development requirements. I didn't suspect 
>>> reactor would check for poms before executing the life cycle. 
>>>
>>> I'm sure this has been solved  by someone in the past. I just don't know 
>>> how to solve it using maven. I can solve it with a bunch of execute blocks, 
>>> but that is very ugly. I'm going to look at the release plugin and a few 
>>> others
>>>
>>> It's likely I'm using the wrong plugin or I'm missing a plugin. 
>>>
>>> BTW, I like your iterator plugin 
>>>
>>> cheers
>>> gary
>>>
>>>
>>>
>>>
>>> On 2019/03/23 23:56:48, Karl Heinz Marbaise  wrote: 
>>>> Hi,
>>>>
>>>> I will give you the same answer as on StackOverflow.
>>>>
>>>> The way you are going sounds wrong...
>>>>
>>>> As I already suggested is the way to go creating a multi module build
>>>> which comprises of several modules which is located within a single Git
>>>> repository. this can be build by using a single command.
>>>>
>>>>
>>>> mvn clean package
>>>>
>>>> from the root location..
>>>>
>>>> https://github.com/khmarbaise/javaee
>>>> https://github.com/khmarbaise/supose
>>>>
>>>> Kind regards
>>>> Karl Heinz Marbaise
>>>>
>>>> On 24.03.19 00:35, Gary M wrote:
>>>>> Hi,
>>>>>
>>>>> I need some help with scm checking out multiple modules and building them.
>>>>> I have several projects I'm consolidating into  a single jar.  Reactor
>>>>> checks for module poms before generate-sources executes.
>>>>>
>>>>> How do I fix this issue ?
>>>>>
>>>>> thanks..
>>>>> g
>>>>>
>>>>> POM sample to give you an idea of what I've done.
>>>>>
>>>>>  
>>>>>org.apache.maven.plugins
>>>>>maven-scm-plugin
>>>>>1.9.4
>>>>>
>>>>>  
>>>>>mod-1
>>>>>generate-sources
>>>>>
>>>>>  ${mod-1.url}
>>>>>  ${mod-1.versionType}
>>>>>  ${mod-1.version}
>>>>>  ${mod-1.directory}
>>>>>
>>>>>
>>>>>  checkout
>>>>>
>>>>>  
>>>>>  
>>>>>mod-2
>>>>>generate-sources
>>>>>
>>>>>  ${mod-2.url}
>>>>>  ${mod-2.versionType}
>>>>>  ${mod-2.version}
>>>>>  ${mod-2.directory}
>>>>>
>>>>>
>>>>>  checkout
>>>>>
>>>>>  
>>>>>
>>>>>
>>>>> .
>>>>>
>>>>> 
>>>>>
>>>> -
>>>> 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
>>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org



signature.asc
Description: OpenPGP digital signature

Re: Need help.. How to configure POM for multi-module checkout

[garym]

Hi Nick,

Thank you for that suggestion. That was also suggested on stackoverflow by 
Karl. That method is better suited for static-ish configurations.   I need a 
BOM type system where I can dynamically switch between tags and branches for 
different modules, much like clear case.  I'll be moving to a different 
structure and tool chain in 6 months.

cheer

On 2019/03/24 01:45:50, Kyle Marek  wrote: 
> Not sure that it will help with version number matches, but you could
> also use Git submodules to bring multiple repositories together in a
> single tree.
> 
> See: https://git-scm.com/book/en/v2/Git-Tools-Submodules
> 
> On 3/23/19 9:26 PM, ga...@oedata.com wrote:
> > Hi Karl,
> >
> > Thank you for replying on mail server. and thanks for sending me the links 
> > to you project poms. They look awesome.
> >
> > The is a difference between your projects and my situation. Your projects 
> > all the modules reside in the same repository. In my case, they reside in 
> > different repositories.  
> >
> > I elected to use the scm plugin because it allows me to select branches and 
> > tags, based on the project and development requirements. I didn't suspect 
> > reactor would check for poms before executing the life cycle. 
> >
> > I'm sure this has been solved  by someone in the past. I just don't know 
> > how to solve it using maven. I can solve it with a bunch of execute blocks, 
> > but that is very ugly. I'm going to look at the release plugin and a few 
> > others
> >
> > It's likely I'm using the wrong plugin or I'm missing a plugin. 
> >
> > BTW, I like your iterator plugin 
> >
> > cheers
> > gary
> >
> >
> >
> >
> > On 2019/03/23 23:56:48, Karl Heinz Marbaise  wrote: 
> >> Hi,
> >>
> >> I will give you the same answer as on StackOverflow.
> >>
> >> The way you are going sounds wrong...
> >>
> >> As I already suggested is the way to go creating a multi module build
> >> which comprises of several modules which is located within a single Git
> >> repository. this can be build by using a single command.
> >>
> >>
> >> mvn clean package
> >>
> >> from the root location..
> >>
> >> https://github.com/khmarbaise/javaee
> >> https://github.com/khmarbaise/supose
> >>
> >> Kind regards
> >> Karl Heinz Marbaise
> >>
> >> On 24.03.19 00:35, Gary M wrote:
> >>> Hi,
> >>>
> >>> I need some help with scm checking out multiple modules and building them.
> >>> I have several projects I'm consolidating into  a single jar.  Reactor
> >>> checks for module poms before generate-sources executes.
> >>>
> >>> How do I fix this issue ?
> >>>
> >>> thanks..
> >>> g
> >>>
> >>> POM sample to give you an idea of what I've done.
> >>>
> >>>  
> >>>org.apache.maven.plugins
> >>>maven-scm-plugin
> >>>1.9.4
> >>>
> >>>  
> >>>mod-1
> >>>generate-sources
> >>>
> >>>  ${mod-1.url}
> >>>  ${mod-1.versionType}
> >>>  ${mod-1.version}
> >>>  ${mod-1.directory}
> >>>
> >>>
> >>>  checkout
> >>>
> >>>  
> >>>  
> >>>mod-2
> >>>generate-sources
> >>>
> >>>  ${mod-2.url}
> >>>  ${mod-2.versionType}
> >>>  ${mod-2.version}
> >>>  ${mod-2.directory}
> >>>
> >>>
> >>>  checkout
> >>>
> >>>  
> >>>
> >>>
> >>> .
> >>>
> >>> 
> >>>
> >> -
> >> 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
> 
> 

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Need help.. How to configure POM for multi-module checkout

[Nikki Novak]

Gary,

Having modules residing in other repositories is not a problem...

...but why do they not have a pom.xml ?

...Is the POM on a different branch ?
...Are the modules using ANT or gradle instead ?
...Are you auto-generating POMs ?

Like, I'm really scratching my head trying to figure out what is going on here ?

If the only thing you need to do is checkout, then you could add a git 
submodule and add the folder to the maven aggregator ?
The git submodule always points to a specific commit (until you update the 
reference).

Would that be a viable option for your purpose(s) ?

Nick


From: garym@ 
Sent: Sunday, March 24, 2019 1:26 AM
To: users@maven.apache.org
Subject: Re: Need help.. How to configure POM for multi-module checkout

Hi Karl,

Thank you for replying on mail server. and thanks for sending me the links to 
you project poms. They look awesome.

The is a difference between your projects and my situation. Your projects all 
the modules reside in the same repository. In my case, they reside in different 
repositories.

I elected to use the scm plugin because it allows me to select branches and 
tags, based on the project and development requirements. I didn't suspect 
reactor would check for poms before executing the life cycle.

I'm sure this has been solved  by someone in the past. I just don't know how to 
solve it using maven. I can solve it with a bunch of execute blocks, but that 
is very ugly. I'm going to look at the release plugin and a few others

It's likely I'm using the wrong plugin or I'm missing a plugin.

BTW, I like your iterator plugin

cheers
gary




On 2019/03/23 23:56:48, Karl Heinz Marbaise  wrote:
> Hi,
>
> I will give you the same answer as on StackOverflow.
>
> The way you are going sounds wrong...
>
> As I already suggested is the way to go creating a multi module build
> which comprises of several modules which is located within a single Git
> repository. this can be build by using a single command.
>
>
> mvn clean package
>
> from the root location..
>
> https://github.com/khmarbaise/javaee
> https://github.com/khmarbaise/supose
>
> Kind regards
> Karl Heinz Marbaise
>
> On 24.03.19 00:35, Gary M wrote:
> > Hi,
> >
> > I need some help with scm checking out multiple modules and building them.
> > I have several projects I'm consolidating into  a single jar.  Reactor
> > checks for module poms before generate-sources executes.
> >
> > How do I fix this issue ?
> >
> > thanks..
> > g
> >
> > POM sample to give you an idea of what I've done.
> >
> >  
> >org.apache.maven.plugins
> >maven-scm-plugin
> >1.9.4
> >
> >  
> >mod-1
> >generate-sources
> >
> >  ${mod-1.url}
> >  ${mod-1.versionType}
> >  ${mod-1.version}
> >  ${mod-1.directory}
> >
> >
> >  checkout
> >
> >  
> >  
> >mod-2
> >generate-sources
> >
> >  ${mod-2.url}
> >  ${mod-2.versionType}
> >  ${mod-2.version}
> >  ${mod-2.directory}
> >
> >
> >  checkout
> >
> >  
> >
> >
> > .
> >
> > 
> >
>
> -
> 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: Need help.. How to configure POM for multi-module checkout

[Kyle Marek]

Not sure that it will help with version number matches, but you could
also use Git submodules to bring multiple repositories together in a
single tree.

See: https://git-scm.com/book/en/v2/Git-Tools-Submodules

On 3/23/19 9:26 PM, ga...@oedata.com wrote:
> Hi Karl,
>
> Thank you for replying on mail server. and thanks for sending me the links to 
> you project poms. They look awesome.
>
> The is a difference between your projects and my situation. Your projects all 
> the modules reside in the same repository. In my case, they reside in 
> different repositories.  
>
> I elected to use the scm plugin because it allows me to select branches and 
> tags, based on the project and development requirements. I didn't suspect 
> reactor would check for poms before executing the life cycle. 
>
> I'm sure this has been solved  by someone in the past. I just don't know how 
> to solve it using maven. I can solve it with a bunch of execute blocks, but 
> that is very ugly. I'm going to look at the release plugin and a few others
>
> It's likely I'm using the wrong plugin or I'm missing a plugin. 
>
> BTW, I like your iterator plugin 
>
> cheers
> gary
>
>
>
>
> On 2019/03/23 23:56:48, Karl Heinz Marbaise  wrote: 
>> Hi,
>>
>> I will give you the same answer as on StackOverflow.
>>
>> The way you are going sounds wrong...
>>
>> As I already suggested is the way to go creating a multi module build
>> which comprises of several modules which is located within a single Git
>> repository. this can be build by using a single command.
>>
>>
>> mvn clean package
>>
>> from the root location..
>>
>> https://github.com/khmarbaise/javaee
>> https://github.com/khmarbaise/supose
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>> On 24.03.19 00:35, Gary M wrote:
>>> Hi,
>>>
>>> I need some help with scm checking out multiple modules and building them.
>>> I have several projects I'm consolidating into  a single jar.  Reactor
>>> checks for module poms before generate-sources executes.
>>>
>>> How do I fix this issue ?
>>>
>>> thanks..
>>> g
>>>
>>> POM sample to give you an idea of what I've done.
>>>
>>>  
>>>org.apache.maven.plugins
>>>maven-scm-plugin
>>>1.9.4
>>>
>>>  
>>>mod-1
>>>generate-sources
>>>
>>>  ${mod-1.url}
>>>  ${mod-1.versionType}
>>>  ${mod-1.version}
>>>  ${mod-1.directory}
>>>
>>>
>>>  checkout
>>>
>>>  
>>>  
>>>mod-2
>>>generate-sources
>>>
>>>  ${mod-2.url}
>>>  ${mod-2.versionType}
>>>  ${mod-2.version}
>>>  ${mod-2.directory}
>>>
>>>
>>>  checkout
>>>
>>>  
>>>
>>>
>>> .
>>>
>>> 
>>>
>> -
>> 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



signature.asc
Description: OpenPGP digital signature

Re: Need help.. How to configure POM for multi-module checkout

[garym]

Hi Karl,

Thank you for replying on mail server. and thanks for sending me the links to 
you project poms. They look awesome.

The is a difference between your projects and my situation. Your projects all 
the modules reside in the same repository. In my case, they reside in different 
repositories.  

I elected to use the scm plugin because it allows me to select branches and 
tags, based on the project and development requirements. I didn't suspect 
reactor would check for poms before executing the life cycle. 

I'm sure this has been solved  by someone in the past. I just don't know how to 
solve it using maven. I can solve it with a bunch of execute blocks, but that 
is very ugly. I'm going to look at the release plugin and a few others

It's likely I'm using the wrong plugin or I'm missing a plugin. 

BTW, I like your iterator plugin 

cheers
gary




On 2019/03/23 23:56:48, Karl Heinz Marbaise  wrote: 
> Hi,
> 
> I will give you the same answer as on StackOverflow.
> 
> The way you are going sounds wrong...
> 
> As I already suggested is the way to go creating a multi module build
> which comprises of several modules which is located within a single Git
> repository. this can be build by using a single command.
> 
> 
> mvn clean package
> 
> from the root location..
> 
> https://github.com/khmarbaise/javaee
> https://github.com/khmarbaise/supose
> 
> Kind regards
> Karl Heinz Marbaise
> 
> On 24.03.19 00:35, Gary M wrote:
> > Hi,
> >
> > I need some help with scm checking out multiple modules and building them.
> > I have several projects I'm consolidating into  a single jar.  Reactor
> > checks for module poms before generate-sources executes.
> >
> > How do I fix this issue ?
> >
> > thanks..
> > g
> >
> > POM sample to give you an idea of what I've done.
> >
> >  
> >org.apache.maven.plugins
> >maven-scm-plugin
> >1.9.4
> >
> >  
> >mod-1
> >generate-sources
> >
> >  ${mod-1.url}
> >  ${mod-1.versionType}
> >  ${mod-1.version}
> >  ${mod-1.directory}
> >
> >
> >  checkout
> >
> >  
> >  
> >mod-2
> >generate-sources
> >
> >  ${mod-2.url}
> >  ${mod-2.versionType}
> >  ${mod-2.version}
> >  ${mod-2.directory}
> >
> >
> >  checkout
> >
> >  
> >
> >
> > .
> >
> > 
> >
> 
> -
> 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: Need help.. How to configure POM for multi-module checkout

[Karl Heinz Marbaise]

Hi,

I will give you the same answer as on StackOverflow.

The way you are going sounds wrong...

As I already suggested is the way to go creating a multi module build
which comprises of several modules which is located within a single Git
repository. this can be build by using a single command.


mvn clean package

from the root location..

https://github.com/khmarbaise/javaee
https://github.com/khmarbaise/supose

Kind regards
Karl Heinz Marbaise

On 24.03.19 00:35, Gary M wrote:

Hi,

I need some help with scm checking out multiple modules and building them.
I have several projects I'm consolidating into  a single jar.  Reactor
checks for module poms before generate-sources executes.

How do I fix this issue ?

thanks..
g

POM sample to give you an idea of what I've done.
   
 
   org.apache.maven.plugins
   maven-scm-plugin
   1.9.4
   
 
   mod-1
   generate-sources
   
 ${mod-1.url}
 ${mod-1.versionType}
 ${mod-1.version}
 ${mod-1.directory}
   
   
 checkout
   
 
 
   mod-2
   generate-sources
   
 ${mod-2.url}
 ${mod-2.versionType}
 ${mod-2.version}
 ${mod-2.directory}
   
   
 checkout
   
 
   

.





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Need help.. How to configure POM for multi-module checkout

[Gary M]

Hi,

I need some help with scm checking out multiple modules and building them.
I have several projects I'm consolidating into  a single jar.  Reactor
checks for module poms before generate-sources executes.

How do I fix this issue ?

thanks..
g

POM sample to give you an idea of what I've done.
  

  org.apache.maven.plugins
  maven-scm-plugin
  1.9.4
  

  mod-1
  generate-sources
  
${mod-1.url}
${mod-1.versionType}
${mod-1.version}
${mod-1.directory}
  
  
checkout
  


  mod-2
  generate-sources
  
${mod-2.url}
${mod-2.versionType}
${mod-2.version}
${mod-2.directory}
  
  
checkout
  

  

.

[ANN] Apache Maven Help Plugin Version 3.1.1 Released

[Karl Heinz Marbaise]

The Apache Maven team is pleased to announce the release of the 
Apache Maven Help Plugin Version 3.1.1
 
https://maven.apache.org/plugins/maven-help-plugin/

You should specify the version in your project's plugin configuration:

Important Notes since Version 3.0.0

 * Maven 3+ only
 * JDK 7 minimum requirement
 

  org.apache.maven.plugins
  maven-help-plugin
  3.1.1


You can download the appropriate sources etc. from the download page:
 
https://maven.apache.org/plugins/maven-help-plugin/download.cgi
 
Release Notes Maven Help Plugin 3.1.1

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317522&version=12343422


Improvement:

 * [MPH-154] - The output of the plugin should be flushed when using forceStdout

Dependency upgrades:

 * [MPH-153] - Upgrade maven-plugins parent to version 32
 * [MPH-156] - Upgrade maven-artifact-transfer to 0.10.0
 * [MPH-157] - Upgrade plexus-interactivity-api 1.0-alpha-6
 * [MPH-158] - Upgrade xstream 1.4.11.1
 * [MPH-159] - Upgrade JUnit 4.12

Enjoy,
 
- The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: help on installation issue

[Golan, Yaron]

Can you verify that you have a valid JDK and it is in the path, please?

-Original Message-
From: Marco Stocchi  
Sent: Tuesday, October 23, 2018 10:54 PM
To: users@maven.apache.org
Subject: help on installation issue

Hello...
I have donwloaded and copied the files of maven into my pc. I need to use maven 
to build a java project.
when typing "mvn" on the cmd prompt, I get the following error

Error: -classpath requires class path specification

The internet suggests to mess up with the environment variables, I tried all 
the solutions proposed but nothing worked for me.

Does anyone know what does this message mean?

Thanks

Re: help on installation issue

[Bernd Eckenfels]

Can you please show the whole input and output, what start directory did you 
use (don’t run it in c:\) and also provide the output of the set command.

Gruss
Bernd
--
http://bernd.eckenfels.net


Von: Marco Stocchi 
Gesendet: Dienstag, Oktober 23, 2018 11:20 PM
An: users@maven.apache.org
Betreff: help on installation issue

Hello...
I have donwloaded and copied the files of maven into my pc. I need to use
maven to build a java project.
when typing "mvn" on the cmd prompt, I get the following error

Error: -classpath requires class path specification

The internet suggests to mess up with the environment variables, I tried
all the solutions proposed but nothing worked for me.

Does anyone know what does this message mean?

Thanks

help on installation issue

[Marco Stocchi]

Hello...
I have donwloaded and copied the files of maven into my pc. I need to use
maven to build a java project.
when typing "mvn" on the cmd prompt, I get the following error

Error: -classpath requires class path specification

The internet suggests to mess up with the environment variables, I tried
all the solutions proposed but nothing worked for me.

Does anyone know what does this message mean?

Thanks

Re: Help needed: maven-surefire-plugin is skipping/not finding tests

[Tibor Digana]

There is zero tests to run because you have globally specified a "groups"
but there are no tests annotated with such group in your project
hadoop-hdfs.
Try to come over this issue by specifying empty groups in this child.


Let's go back to your three questions.
1. The pluginManagement should be in parent and children should not
specify/override plugin version, unless necessary.
2. You can use the latest version 2.22.0 but groups is old feature
available in 2.21.0 or 2.20.0 too and earlier.
3. Fix for groups is on your side, since you specify groups in parent POM
it means all children should undergo the same principle and all tests
should be annotated with one group at least. In your case when you still
have test which are not annotated with groups is to make the "groups"
config parameter empty. You can run the Maven in debug mode (mvn -X ...)
and you can see how the parameter is set in this plugin.

T

On Thu, Jul 26, 2018 at 6:15 PM, Jun Huang 
wrote:

> Hi,
>
> Recently in our hadoop project, we added maven-surefire-plugin for running
> unit tests by categories.
>
> in hadoop root pom.xml:
>
>   
> junit
> junit
> 4.11
>   
> :
> :
>
> 
> org.apache.hadoop.classification.
> TestJUnitCategory$AllTests
> 4.11
> 
>
> 
>   org.apache.maven.plugins
>   maven-surefire-plugin
>   2.21.0
>   
> ${test.groups}
>   
> 
>
>
> 
>   flakies
>   
> org.apache.hadoop.classification.
> TestJUnitCategory$FlakiesTest
>   
> 
> 
>   stables
>   
> org.apache.hadoop.classification.
> TestJUnitCategory$StablesTest
>   
> 
> 
>   integrations
>   
> org.apache.hadoop.classification.TestJUnitCategory$
> IntegrationsTest
>   
> 
> 
>   none
>   
> !org.apache.hadoop.classification.
> TestJUnitCategory$AllTest
>   
> 
>   
>
> Invoking tests by category works fine: mvn -P integrations. However, our
> old fashioned unit test execution got skipped by this maven-surefire-plugin:
>
> 13:16:35 [INFO] --- maven-antrun-plugin:1.7:run (create-log-dir) @
> hadoop-hdfs ---
> 13:16:35 [INFO] Executing tasks
> 13:16:35
> 13:16:35 main:
> 13:16:35[delete] Deleting directory /tmp/tmp.o7flMN8505/src/
> ghuang/ghuang/hadoop-hdfs-project/hadoop-hdfs/target/test/data
> 13:16:35 [mkdir] Created dir: /tmp/tmp.o7flMN8505/src/
> ghuang/ghuang/hadoop-hdfs-project/hadoop-hdfs/target/test/data
> 13:16:35  [copy] Copying 16 files to /tmp/tmp.o7flMN8505/src/
> ghuang/ghuang/hadoop-hdfs-project/hadoop-hdfs/target/test-classes/webapps
> 13:16:35 [INFO] Executed tasks
> 13:16:35 [INFO]
> 13:16:35 [INFO] --- maven-compiler-plugin:3.1:testCompile
> (default-testCompile) @ hadoop-hdfs ---
> 13:16:35 [INFO] Nothing to compile - all classes are up to date
> 13:16:35 [INFO]
> 13:16:35 [INFO] --- maven-surefire-plugin:2.20:test (default-test) @
> hadoop-hdfs ---
> 13:16:35 [INFO] Surefire report directory: /tmp/tmp.o7flMN8505/src/
> ghuang/ghuang/hadoop-hdfs-project/hadoop-hdfs/target/surefire-reports
> 13:16:35 [INFO] parallel='none', perCoreThreadCount=true, threadCount=0,
> useUnlimitedThreads=false, threadCountSuites=0, threadCountClasses=0,
> threadCountMethods=0, parallelOptimized=true
> 13:16:35 [INFO]
> 13:16:35 [INFO] ---
> 13:16:35 [INFO]  T E S T S
> 13:16:35 [INFO] ---
> 13:26:01 [INFO]
> 13:26:01 [INFO] Results:
> 13:26:01 [INFO]
> 13:26:01 [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> 13:26:01 [INFO]
> 13:26:01 [INFO]
> 13:26:01 [INFO] --- maven-antrun-plugin:1.7:run (hdfs-test-bats-driver) @
> hadoop-hdfs ---
>
> I also verified that by removing surefire-plugin block in root pom.xml
> file will make these tests executing again as usual. So I have some
> questions here:
>
> 1. I saw the reported surefire-plugin version was 2.20 while I was
> defining 2.21 in my change. This is because it gets overwritten by the
> parent pom. So how do I make it use my customized version.
>
> 2. Is the version 2.21 the right version for this? I saw some post
> indicated version 2.21 might have some bug?
>
> 3. What is the fix for this issue?
>
>
> Many thanks,
> George
>
> See attached pom.xml file.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

[ANN] Apache Maven Help Plugin Version 3.1.0 Released

[Karl Heinz Marbaise]

The Apache Maven team is pleased to announce the release of the 
Apache Maven Help Plugin Version 3.1.0
 
https://maven.apache.org/plugins/maven-help-plugin/

You should specify the version in your project's plugin configuration:

Important Notes since Version 3.0.0

 * Maven 3+ only
 * JDK 7 minimum requirement
 

  org.apache.maven.plugins
  maven-help-plugin
  3.1.0


You can download the appropriate sources etc. from the download page:
 
https://maven.apache.org/plugins/maven-help-plugin/download.cgi
 
Release Notes Maven Help Plugin 3.1.0

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317522&version=12343004


New Feature:

 * [MPH-144] - Add ability to print mvn help:evaluate output to stdout in quiet 
mode

Improvement:

 * [MPH-151] - Add documentation information for GitHub

Tasks:

 * [MPH-145] - Upgrade mave-surefire/failsafe-plugin 2.21.0
 * [MPH-146] - JavaDoc Issues / Code cleanups

Dependency upgrades:

 * [MPH-147] - plexus-interactivity-api to 1.0-alpha-6
 * [MPH-148] - Upgrade xstream to 1.4.10
 * [MPH-149] - Upgrade jdom-legacy to jdom2 2.0.6

Enjoy,
 
- The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Help with MavenSureFire

[Marco Schulz]

may you can use profiles for each environment to iniciate your variables.

Get Outlook for Android<https://aka.ms/ghei36>


From: Michael Sela 
Sent: Friday, May 25, 2018 9:38:10 AM
To: 'users@maven.apache.org'
Subject: Help with MavenSureFire

Hello,

I am trying to run a maven test phase during a bamboo build plan. My tests rely 
on a set of environment variables that I configured in the pom.xml. However, 
those values are only applicable to one environment, and I would like to 
execute the same tests on multiple environments (different host IPS, etc). My 
Pom.xml looks something like this:



org.apache.maven.plugins
maven-surefire-plugin
2.21.0





variablevalue






During the bamboo build plan, I execute mvn clean test. Does anyone know how I 
can configure surefire to possibly read environment variables from a file or 
something and then execute the mvn command line to read the proper file based 
on the environment I feed it in the command line. Example mvn clean -DtestEnv 
test. This way in my build plan I can run the test phase for the environment it 
is relevant for.

Thanks
Michael.

Help with MavenSureFire

[Michael Sela]

Hello,

I am trying to run a maven test phase during a bamboo build plan. My tests rely 
on a set of environment variables that I configured in the pom.xml. However, 
those values are only applicable to one environment, and I would like to 
execute the same tests on multiple environments (different host IPS, etc). My 
Pom.xml looks something like this:



org.apache.maven.plugins
maven-surefire-plugin
2.21.0





variablevalue






During the bamboo build plan, I execute mvn clean test. Does anyone know how I 
can configure surefire to possibly read environment variables from a file or 
something and then execute the mvn command line to read the proper file based 
on the environment I feed it in the command line. Example mvn clean -DtestEnv 
test. This way in my build plan I can run the test phase for the environment it 
is relevant for.

Thanks
Michael.

[ANN] Release Maven Help Plugin 3.0.1 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
Help Plugin version 3.0.1.


This module generates browsable HTML pages from Java source code.

https://maven.apache.org/plugins/maven-help-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-help-plugin
  3.0.1



Release Notes - Maven Help Plugin - Version 3.0.1

** Bug
* [MPH-135] - help:effective-pom crashes with NPE in multi module 
builds with -Doutput set

* [MPH-139] - Invalid default namespace set for effective settings
* [MPH-140] - Multiple XML declarations written

** Task
* [MPH-137] - Use JDOM's PrettyFormatter throughout
* [MPH-138] - Drop AbstractEffectiveMojo#addMavenNamespace()
* [MPH-141] - Use non-deprecated field in DateFormatUtils

** Dependency upgrade
* [MPH-136] - Upgrade JDOM to 1.1.3


Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Release Maven Help Plugin 3.0.0 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
Help Plugin version 3.0.0.


This module generates browsable HTML pages from Java source code.

https://maven.apache.org/plugins/maven-help-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-help-plugin
  3.0.0



Release Notes - Maven Help Plugin - Version 3.0.0

** Bug
* [MPH-53] - mvn help:describe returns the version that is 
specified in metadata instead of  the one in the parent pom
* [MPH-87] - help:effective-pom/effective-settings uses platform 
encoding and garbles non-ASCII characters, emits invalid XML
* [MPH-97] - [Patch] maven-help-plugin does not build with latest 
version of maven-plugin-testing-harness

* [MPH-99] - Evaluate has no output in quiet mode
* [MPH-105] - Effective pom aggregation is not triggered
* [MPH-107] - Mojos use inconsistent line endings throughout
* [MPH-108] - Patch for MPH-72 not fully applied
* [MPH-110] - Cannot run ITs successfully
* [MPH-111] - IT 'effective-pom_properties' fails if run with 
-Dinvoker.mergeUserSettings

* [MPH-114] - Goal fails with “Unable to get the POM for the artifact”
* [MPH-119] - The "artifact" parameter is not taken into account 
with Maven 3

* [MPH-121] - incorrect text in help:describe for cmd
* [MPH-123] - all-profiles does not show right active status

** Improvement
* [MPH-106] - add gav parameter to calculate effective pom for any 
gav, not only reactor

* [MPH-109] - Use ISO 8601 date format for the remaining goals
* [MPH-116] - Printout the information if a goal is a report goal 
or not

* [MPH-120] - Migrate plugin to Maven 3.0
* [MPH-124] - Show parameter aliases in describe goal

** Task
* [MPH-103] - Remove unused dependency maven-monitor
* [MPH-112] - Upgrade to Commons Lang3
* [MPH-126] - Require Java 7
* [MPH-132] - Drop parameter 'medium'
* [MPH-133] - Drop deprecated alias 'full'
* [MPH-134] - Drop deprecated alias 'mojo'

** Dependency upgrade
* [MPH-102] - Upgrade to maven-plugins parent version 27
* [MPH-104] - Upgrade maven-plugin-testing-harness to 1.3
* [MPH-117] - Upgrade plexus-utils to 3.0.22
* [MPH-118] - Upgrade maven-plugins to version 30
* [MPH-125] - Upgrade parent to 31
* [MPH-127] - Upgrade Maven  Artifact Transfer to 0.9.1
* [MPH-128] - Upgrade Maven Reporting Exec to 1.4
* [MPH-129] - Upgrade Plexus Utils to 3.1.0
* [MPH-130] - Upgrade XStream to 1.4.7
* [MPH-131] - Ugprade Commons Lang to 3.7


Enjoy,

-The Apache Maven team


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Reduce verbose for mvn versions:set - help needed

[Anesh Kurian]

Hello Team,

I am new to the mailing list, and apologies if this is not the right forum
for discussion.

I have created a pipeline for automation of Maven build. But the log file
size is exceeding 10Mb and I am unable to display the same efficiently over
Chrome.IE browsers. (FireFox browser is not supported in our Organization)

When I reviewed the logs, I could see there was many log entries for mvn
versions:set command. Lot of INFO Downloading and mainhread entries are
getting recorded in the logs.

*mvn versions:set --batch-mode -s ${SETTINGSPATH}
-DnewVersion=${GO_PIPELINE_VERSION}
-Djavax.net.ssl.trustStore=${SAIL_ETC_DIR}/sailcert/TND-Test-CA.jks
-Djavax.net.ssl.trustStorePassword=${TRUST_STORE_PASS}*

I was trying to find any options for *mvn versions:set *command  to reduce
verbose of logs generated. I referred below link and used options --quite
and --batch-mode to reduce verbose of logs, but still many INFO and
mainheard log entries are getting recorded.

I would appreciate if you can share any details on how I can
reduce/eliminate the downloading, INFO and mainheard entries from the logs.

Much appreciated.
-
Best Regards
Anesh

Help with unresolved file paths during plugin execution for banDuplicateClasses

[sud]

I posted this as an issue on the Github project before I realized the mailing 
list was more appropriate and was more active for this. Apologies for the 
double post.
The Github issue is here along with a link to the demo project that illustrates 
the issue:https://github.com/mojohaus/extra-enforcer-rules/issues/29

It appears that there is a bug when using the banDuplicateClasses rule where 
the file path for the dependency that is being checked hasn't been resolved 
during the plugin execution.

Thanks for advance for any pointers on how I can proceed to resolve this. I 
spent time attempting to debug it, and what I believe I found was that the list 
of dependencyArtifacts that is handed to the plugin has the artifact flagged as 
resolved even though the file attribute hasn't been populated.

Maven Embedder 3.3.9 Functional Example Help

[Mitch Turner]

Hello folks,

I am attempting to use maven-embedder:3.3.9 and have thus far been
unsuccessful.

I forked a functioning repo for Maven version 3.1.1 however I would like to
use 3.3.9 or newer.


My attempt to run 3.3.9 is here:
https://github.com/tc-turner/maven-embedder-otg/tree/339

You can see the full stack trace here:
https://github.com/tc-turner/maven-embedder-otg/issues/1


Here is a portion of the stack trace in case it is obvious to you:

mturner-ol:target mturner$ java -jar
maven-embedder-example-1-jar-with-dependencies.jar
[main] WARN Sisu - Error injecting:
org.apache.maven.project.DefaultProjectBuildingHelper
com.google.inject.ProvisionException: Unable to provision, see the
following errors:

1) No implementation for org.apache.maven.classrealm.ClassRealmManager
was bound.
  while locating org.apache.maven.project.DefaultProjectBuildingHelper

1 error
at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1025)
at 
com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1051)
at 
org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
at 
com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:81)
at 
com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:53)
at 
com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:65)
at 
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115)
at 
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:133)
at 
com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
at 
com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:63)
at 
com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45)
at 
com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
at 
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)



Does anyone have a functional example of using maven-embedder?

Thanks,

Mitchell Turner

Re: [Help] Force maven[-surefire] to run in parallel

[Luis Henrique de Souza Melo]

@Thomas Broyer
Thanks, we will try to run with these args and ignore those who does not
behave like expected...

In parallel, we are still looking for other alternatives if there is any.

@Charles Honton
Thanks for this information.
I am considering that.

Em qua, 15 de mar de 2017 às 11:15, Charles Honton 
escreveu:

You should consider that if the project’s tests were not written with
multi-threading in mind, they may fail.

> On Mar 15, 2017, at 6:56 AM, Thomas Broyer  wrote:
>
> Hi,
>
> On Wed, Mar 15, 2017 at 2:11 PM Luis Henrique de Souza Melo <
> l...@cin.ufpe.br> wrote:
>
>> Hi,
>>
>> I am a student at the Federal University of Pernambuco, and our group is
>> having some issues with Maven to run some tests in a huge amount of
>> projects.
>>
>> We plan to run all theses open-source projects tests in parallel and in
>> sequential using its own maven. However, we cannot change every pom.xml
>> from every module and/or project main pom.xml manually.
>>
>> Is there any way to force maven and/or surefire to run in parallel using
a
>> command line argument, like: mvn test --parallel 3 -fae
>> Or even in sequential mode would help us like: mvn test --sequential -fae
>>
>
> All parallelism-related properties can be set using "user properties",
> which means you can set them from the command line (if they haven't been
> set explicitly in the POMs); e.g. for forkCount [1] you can call Maven as
> "mvn -DforkCount=2 test" to set the forkCount property to 2. If the
> properties have been set in the POM, if they have been set using a
property
> value (e.g. ${some.property}) then you can override
> the property from the command line (i.e. "mvn -Dsome.property=2 test"). If
> the properties have been set with hard-coded values (e.g.
> 1) then you have no other choice than to edit the
> POMs.
>
> And then you can tell Maven to parallelize the build with -T.
>
> Actually, everything seems to be described in the Surefire documentation
[2]
>
> [1]
>
https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#forkCount
>
> [2]
>
https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: [Help] Force maven[-surefire] to run in parallel

[Charles Honton]

You should consider that if the project’s tests were not written with 
multi-threading in mind, they may fail.

> On Mar 15, 2017, at 6:56 AM, Thomas Broyer  wrote:
> 
> Hi,
> 
> On Wed, Mar 15, 2017 at 2:11 PM Luis Henrique de Souza Melo <
> l...@cin.ufpe.br> wrote:
> 
>> Hi,
>> 
>> I am a student at the Federal University of Pernambuco, and our group is
>> having some issues with Maven to run some tests in a huge amount of
>> projects.
>> 
>> We plan to run all theses open-source projects tests in parallel and in
>> sequential using its own maven. However, we cannot change every pom.xml
>> from every module and/or project main pom.xml manually.
>> 
>> Is there any way to force maven and/or surefire to run in parallel using a
>> command line argument, like: mvn test --parallel 3 -fae
>> Or even in sequential mode would help us like: mvn test --sequential -fae
>> 
> 
> All parallelism-related properties can be set using "user properties",
> which means you can set them from the command line (if they haven't been
> set explicitly in the POMs); e.g. for forkCount [1] you can call Maven as
> "mvn -DforkCount=2 test" to set the forkCount property to 2. If the
> properties have been set in the POM, if they have been set using a property
> value (e.g. ${some.property}) then you can override
> the property from the command line (i.e. "mvn -Dsome.property=2 test"). If
> the properties have been set with hard-coded values (e.g.
> 1) then you have no other choice than to edit the
> POMs.
> 
> And then you can tell Maven to parallelize the build with -T.
> 
> Actually, everything seems to be described in the Surefire documentation [2]
> 
> [1]
> https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#forkCount
> 
> [2]
> https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: [Help] Force maven[-surefire] to run in parallel

[Thomas Broyer]

Hi,

On Wed, Mar 15, 2017 at 2:11 PM Luis Henrique de Souza Melo <
l...@cin.ufpe.br> wrote:

> Hi,
>
> I am a student at the Federal University of Pernambuco, and our group is
> having some issues with Maven to run some tests in a huge amount of
> projects.
>
> We plan to run all theses open-source projects tests in parallel and in
> sequential using its own maven. However, we cannot change every pom.xml
> from every module and/or project main pom.xml manually.
>
> Is there any way to force maven and/or surefire to run in parallel using a
> command line argument, like: mvn test --parallel 3 -fae
> Or even in sequential mode would help us like: mvn test --sequential -fae
>

All parallelism-related properties can be set using "user properties",
which means you can set them from the command line (if they haven't been
set explicitly in the POMs); e.g. for forkCount [1] you can call Maven as
"mvn -DforkCount=2 test" to set the forkCount property to 2. If the
properties have been set in the POM, if they have been set using a property
value (e.g. ${some.property}) then you can override
the property from the command line (i.e. "mvn -Dsome.property=2 test"). If
the properties have been set with hard-coded values (e.g.
1) then you have no other choice than to edit the
POMs.

And then you can tell Maven to parallelize the build with -T.

Actually, everything seems to be described in the Surefire documentation [2]

[1]
https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#forkCount

[2]
https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html

[Help] Force maven[-surefire] to run in parallel

[Luis Henrique de Souza Melo]

Hi,

I am a student at the Federal University of Pernambuco, and our group is
having some issues with Maven to run some tests in a huge amount of
projects.

We plan to run all theses open-source projects tests in parallel and in
sequential using its own maven. However, we cannot change every pom.xml
from every module and/or project main pom.xml manually.

Is there any way to force maven and/or surefire to run in parallel using a
command line argument, like: mvn test --parallel 3 -fae
Or even in sequential mode would help us like: mvn test --sequential -fae

Re: [EXTERNAL] Re: help with version range

[Hervé BOUTEMY]

Le vendredi 23 septembre 2016 18:46:36 Manfred Moser a écrit :
> Fair enough. From the purely engineering/mathematical point of view it might
> not make sense. But I dont see a way to get that changed with breaking a
> TON of other stuff.
+1

> And I am not even sure if it would be more intuitive
> instead of just being different.
+1

> 
> Manfred
> 
> Robert Patrick wrote on 2016-09-23 09:38:
> > No, you are making an invalid assumption about what I understand!  I
> > completely understand the relationship of SNAPSHOTs and other pre-release
> > artifacts and released versions.
> > 
> > What I am questioning is the "engineer's approach" to version range
> > resolution without a valid use case for why Maven should consider
> > pre-released versions as within the "not including 2.0" version range
> > semantics.
> > 
> > 
> > -Original Message-
> > From: Manfred Moser [mailto:manf...@simpligility.com]
> > Sent: Friday, September 23, 2016 11:32 AM
> > To: users@maven.apache.org
> > Subject: Re: [EXTERNAL] Re: help with version range
> > 
> > What you are misunderstanding is how snapshots are meant to be used.
> > 2.0-SNAPSHOT means that it is a development version working towards the
> > release of 2.0 and as such the version 2.0-SNAPSHOT is smaller than 2.0.
> > 
> > If you mislike this you can change how you work with your own projects at
> > least. .. you can just call your snapshot version 1.99-SNAPSHOT or
> > whatever
> > while developing and at releas time switch to 2.0 ..
> > 
> > Manfred
> > 
> > Robert Patrick wrote on 2016-09-23 08:56:
> >> This does seem non-intuitive.If I say that I want versions  between
> >> 1.0
> >> and
> >> up to but NOT including 2.0 by saying [1.0,2.0), in what use case
> >> would I ever want this to resolve to 2.0-SNAPSHOT or any other
> >> pre-release 2.0 artifact?
> >> Personally, I cannot think of a single one.
> >> 
> >> Typically, what I mean when I say [1.0,2.0) is any 1.x version but
> >> nothing related to 2.0...
> >> 
> >> -Original Message-
> >> From: Justin Georgeson [mailto:jgeorge...@lgc.com]
> >> Sent: Friday, September 23, 2016 10:11 AM
> >> To: Maven Users List
> >> Subject: RE: [EXTERNAL] Re: help with version range
> >> 
> >> Yeah, I was hoping there was something more elegant like 1.1+ or
> >> something, so I can at least move forward with that.
> >> 
> >> Logically, does it make sense to resolve 1.2.0-alpha-1 when the user
> >> has excluded 1.2.0 from their range? If I explicitly don't want the
> >> release version why would I want the pre-release versions?
> >> 
> >> -Original Message-
> >> From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On
> >> Behalf Of Curtis Rueden
> >> Sent: Friday, September 23, 2016 9:01 AM
> >> To: Maven Users List
> >> Subject: [EXTERNAL] Re: help with version range
> >> 
> >> Hi Justin,
> >> 
> >> You could write "[1.1.0,1.1.9]", no? A bit hacky, but would match
> >> the versions you want in practice.
> >> 
> >> Regards,
> >> Curtis
> >> 
> >> On Sep 23, 2016 8:38 AM, "Justin Georgeson"  wrote:
> >>> I’m using the parent version range feature with “[1.1.0,1.2.0)” and
> >>> it had been going well. However I wanted to start working on 1.2.0 of
> >>> the parent, so I published a 1.2.0-alpha-1 version. And all the
> >>> projects with te “[1.1.0,1.2.0)” picked it up. I recognize that this
> >>> is in keeping with the implementation that x.y.z-(alpha|beta|…)
> >>> precedes x.y.z, but it is unintuitive to me. First in that I’ve
> >>> stated I don’t want 1.2.0, and second that once I do release 1.2.0
> >>> the projects which were receiving the alpha builds will not get
> >>> 1.2.0. I tried with both
> >>> 3.2.5 and 3.3.9. Can the version range syntax express the range I want?
> >>> 
> >>> 
> >>> 
> >>> *Justin Georgeson*
> >>> Landmark Cloud Platforms & DevOps - RM
> >>> 
> >>> Email: *jgeorge...@lgc.com* 
> >>> 
> >>> Follow Halliburton: *LinkedIn*
> >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dho
> >>> s
> >>> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
> >>>

Re: [EXTERNAL] Re: help with version range

[Hervé BOUTEMY]

I worked a lot on this in the past, and the range I found the easiest to write 
is:
[1.0,2.0-a-a)

= "alpha-alpha" trick

yes, this is still a trick, but at least this better shows the intent

Regards,

Hervé

Le vendredi 23 septembre 2016 13:41:37 Robert Patrick a écrit :
> Well...like I said, I understand the relationship but clearly, most people
> that use version ranges that use a non-inclusive top-end specification do
> not want prerelease versions included.  I have yet to hear you or anyone
> else give me a use case where you want this.
> 
> The fact that I have to fight Maven to achieve this is a pain--and I have
> been using Maven for many years now.  There should be a simple way to
> achieve this that does not require me to do something like this:
> 
> [1.0,1.9
> 99)
> 
> 
> -Original Message-
> From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
> Sent: Friday, September 23, 2016 3:30 PM
> To: Maven Users List
> Subject: Re: [EXTERNAL] Re: help with version range
> 
> Hi,
> 
> On 23/09/16 18:38, Robert Patrick wrote:
> > What I am questioning is the "engineer's approach" to version range
> > resolution without
> > 
>  > a valid use case for why Maven should consider  > pre-released versions
>  > as within the "not including 2.0" version  > range semantics.
> The simple answer to this is the timeline of those releases...
> So a pre-release (2.0-alpha-1, 2.0-RC1 etc.) will be done before the final
> release (2.0) so must be defined as before...
> 
> Kind regards
> Karl Heinz Marbaise
> 
> 
> 
> -
> 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


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: [EXTERNAL] Re: help with version range

[Christian Schulte]

Am 09/24/16 um 04:16 schrieb Justin Georgeson:
> I tried these four version ranges with the 3.4.0-SNAPSHOT from your link 
> 
> [1.1.min,1.1.max]
> [1.1.*]
> [1.2.min,1.2.max]
> [1.2.*]
> 
> All four downloaded the expected parent POM without the warnings.

That's expected behaviour. Damn it ;-) ...

Thanks for testing.
-- 
Christian


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: [EXTERNAL] Re: help with version range

[Justin Georgeson]

I tried these four version ranges with the 3.4.0-SNAPSHOT from your link 

[1.1.min,1.1.max]
[1.1.*]
[1.2.min,1.2.max]
[1.2.*]

All four downloaded the expected parent POM without the warnings.

I like the colorized output.

-Original Message-
From: Christian Schulte [mailto:c...@schulte.it] 
Sent: Friday, September 23, 2016 8:47 PM
To: Maven Users List 
Subject: Re: [EXTERNAL] Re: help with version range

Am 09/24/16 um 02:15 schrieb Justin Georgeson:
> The Aether doc shows both bounds being inclusive with the min/max form, but 
> you have an exclusive upper bound. Using "[1.1.min,1.1.max]" is working for 
> me with both 3.2.5 and 3.3.9. So that's awesome! The .* form is working for 
> me too. I'm using JDK 1.8.0_102, and my projects are pretty much all Tycho 
> packaging-types.
> 
> I am seeing these warnings
> 
> [WARNING] Failed to canonicalize path 
> C:\Code\caches\m2\com\lgc\master\[1.1.*]\master-[1.1.*].pom.lastUpdate
> d: The filename, direc tory name, or volume label syntax is incorrect
> Downloading: 
> http://cmartifacts3.lgc.com/artifactory/maven-virtual/com/lgc/master/%
> 5B1.1.*%5D/master-%5B1.1.*%5D.pom [WARNING] Failed to canonicalize 
> path 
> C:\Code\caches\m2\com\lgc\master\[1.1.*]\master-[1.1.*].pom.lastUpdate
> d: Invalid argument [WARNING] Failed to create parent directories for 
> tracking file 
> C:\Code\caches\m2\com\lgc\master\[1.1.*]\master-[1.1.*].pom.lastUp
> dated
> [WARNING] Failed to build parent project for 
> com.lgc.lowest:lowest-parent:pom:10.5.2-SNAPSHOT
> 
> Which are reported in the original JIRA ticket for the feature
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org
> _jira_browse_MNG-2D2199&d=DQICaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2F
> ZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=leobnERpx7eIg
> IvKmjTYhgj8buTHbUXeP5uyujIxsBY&s=WtN5v0mIkuOLd0hI4m_OpYLLsyZGYi6ivI7n6
> lvH6gw&e=
> 
> But it is ultimately working.

Can you please test a recent 3.4.0-SNAPSHOT and report if those messages 
disappear? Parent version ranges are broken in the Maven versions you mentioned.

<https://urldefense.proofpoint.com/v2/url?u=https-3A__builds.apache.org_view_All_job_maven-2D3.3-2Drelease-2Dstatus-2Dbuild_&d=DQICaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=leobnERpx7eIgIvKmjTYhgj8buTHbUXeP5uyujIxsBY&s=R4EYmMCVXobVq6h9SfS4A9EtWGvXSOLvTqmjLIMelbY&e=
 >

Regards,
--
Christian


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


--
This e-mail, including any attached files, may contain confidential and 
privileged information for the sole use of the intended recipient.  Any review, 
use, distribution, or disclosure by others is strictly prohibited.  If you are 
not the intended recipient (or authorized to receive information for the 
intended recipient), please contact the sender by reply e-mail and delete all 
copies of this message.

Re: [EXTERNAL] Re: help with version range

[Christian Schulte]

Am 09/24/16 um 02:15 schrieb Justin Georgeson:
> The Aether doc shows both bounds being inclusive with the min/max form, but 
> you have an exclusive upper bound. Using "[1.1.min,1.1.max]" is working for 
> me with both 3.2.5 and 3.3.9. So that's awesome! The .* form is working for 
> me too. I'm using JDK 1.8.0_102, and my projects are pretty much all Tycho 
> packaging-types.
> 
> I am seeing these warnings
> 
> [WARNING] Failed to canonicalize path 
> C:\Code\caches\m2\com\lgc\master\[1.1.*]\master-[1.1.*].pom.lastUpdated: The 
> filename, direc
> tory name, or volume label syntax is incorrect
> Downloading: 
> http://cmartifacts3.lgc.com/artifactory/maven-virtual/com/lgc/master/%5B1.1.*%5D/master-%5B1.1.*%5D.pom
> [WARNING] Failed to canonicalize path 
> C:\Code\caches\m2\com\lgc\master\[1.1.*]\master-[1.1.*].pom.lastUpdated: 
> Invalid argument
> [WARNING] Failed to create parent directories for tracking file 
> C:\Code\caches\m2\com\lgc\master\[1.1.*]\master-[1.1.*].pom.lastUp
> dated
> [WARNING] Failed to build parent project for 
> com.lgc.lowest:lowest-parent:pom:10.5.2-SNAPSHOT
> 
> Which are reported in the original JIRA ticket for the feature
> 
> https://issues.apache.org/jira/browse/MNG-2199
> 
> But it is ultimately working.

Can you please test a recent 3.4.0-SNAPSHOT and report if those messages
disappear? Parent version ranges are broken in the Maven versions you
mentioned.



Regards,
-- 
Christian


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: [EXTERNAL] Re: help with version range

[Justin Georgeson]

The Aether doc shows both bounds being inclusive with the min/max form, but you 
have an exclusive upper bound. Using "[1.1.min,1.1.max]" is working for me with 
both 3.2.5 and 3.3.9. So that's awesome! The .* form is working for me too. I'm 
using JDK 1.8.0_102, and my projects are pretty much all Tycho packaging-types.

I am seeing these warnings

[WARNING] Failed to canonicalize path 
C:\Code\caches\m2\com\lgc\master\[1.1.*]\master-[1.1.*].pom.lastUpdated: The 
filename, direc
tory name, or volume label syntax is incorrect
Downloading: 
http://cmartifacts3.lgc.com/artifactory/maven-virtual/com/lgc/master/%5B1.1.*%5D/master-%5B1.1.*%5D.pom
[WARNING] Failed to canonicalize path 
C:\Code\caches\m2\com\lgc\master\[1.1.*]\master-[1.1.*].pom.lastUpdated: 
Invalid argument
[WARNING] Failed to create parent directories for tracking file 
C:\Code\caches\m2\com\lgc\master\[1.1.*]\master-[1.1.*].pom.lastUp
dated
[WARNING] Failed to build parent project for 
com.lgc.lowest:lowest-parent:pom:10.5.2-SNAPSHOT

Which are reported in the original JIRA ticket for the feature

https://issues.apache.org/jira/browse/MNG-2199

But it is ultimately working.

-Original Message-
From: Robert Patrick [mailto:robert.patr...@oracle.com] 
Sent: Friday, September 23, 2016 4:39 PM
To: Maven Users List 
Subject: RE: [EXTERNAL] Re: help with version range

This is nice, but it doesn’t work in Maven 3.3.9...

[ERROR] org.apache.maven.project.artifact.InvalidDependencyVersionException: 
Invalid version: [0.8.min,0.8.max] found for: Dependency: myproject:util in 
project: myproject:zip-installer:pom:0.9-SNAPSHOT. Reason: Range defies version 
ordering: [0.8.min,0.8.max) for project 
myproject:zip-installer:pom:0.9-SNAPSHOT at C:\tmp\myproject\zipinstall\pom.xml 
-> [Help 1]

--
Robert Patrick 
<https://urldefense.proofpoint.com/v2/url?u=http-3A__robert.patrick-40oracle.com&d=DQIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=5-lYd2DM46_1xLARlg3yqwPE5xDzWM8s_z59bPNPfQU&s=euuADbCvIIw3JpW95OhsA08qkyKL4qdUHpADVL6v5R0&e=
 > VP, OPC Development, Oracle Corporation
7460 Warren Pkwy, Ste. 300  Office: +1.972.963.2872
Frisco, TX 75034, USA   Mobile: +1.469.556.9450

Professional Oracle WebLogic Server
by Robert Patrick, Gregory Nyberg, and Philip Aston with Josh Bregman and Paul 
Done Book Home Page: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.wrox.com_&d=DQIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=5-lYd2DM46_1xLARlg3yqwPE5xDzWM8s_z59bPNPfQU&s=pyMmnscielr3hC7gWtaVNqyUIqmy1jf4wWg996YlkUI&e=
Kindle Version: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.amazon.com_&d=DQIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=5-lYd2DM46_1xLARlg3yqwPE5xDzWM8s_z59bPNPfQU&s=hTJHlTeI3Pk6q1pSEHNHzc-xHC9n3wIYawL8FK3y5Qk&e=
 


-Original Message-
From: Christian Schulte [mailto:c...@schulte.it] 
Sent: Friday, September 23, 2016 4:23 PM
To: Maven Users List
Cc: i...@soebes.de
Subject: Re: [EXTERNAL] Re: help with version range

Am 09/23/16 um 23:07 schrieb Robert Patrick:
> There is already a syntax to give you pre-release versions, right?  
> According to 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__maven.apache.org_ref_3.3.9_maven-2Dartifact_apidocs_org_apache_m&d=DQIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=5-lYd2DM46_1xLARlg3yqwPE5xDzWM8s_z59bPNPfQU&s=9TNP5ldPDafRzXnPjonmLhbp5M5SK1htUhzsTE-Xp4Y&e=
>  
> aven/artifact/versioning/ComparableVersion.html, the range 
> [1.0,2.0-SNAPSHOT] will give you the newest release including all 2.0 
> prerelease versions but not the 2.0 GA release so there is no reason 
> you need [1.0,2.0) to do the exact same thing... :-)
> 

I haven't tested this but I think what is written here also applies to Maven. 
You would need to test that yourself.

<https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.eclipse.org_Aether_New-5Fand-5FNoteworthy-23Version-5FRanges&d=DQIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=5-lYd2DM46_1xLARlg3yqwPE5xDzWM8s_z59bPNPfQU&s=pL6fPqzqpaj6n6xcY47JGzm-exhIOjBMxuNxWBVBD0U&e=
 >

Regards,
--
Christian


-
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


--
This e-mail, including any attached files, ma

Re: [EXTERNAL] Re: help with version range

[Christian Schulte]

Am 09/24/16 um 00:23 schrieb Robert Patrick:
> That one is even worse, pom parsing fails...
> 
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] 'dependencies.dependency.version' for myproject:util:jar must not 
> contain any of these characters \/:"<>|?* but found * @ 
> myproject:zip-installer:[unknown-version], C:\myproject\zipinsall\pom.xml, 
> line 196, column 22
> 

Damn it :-)


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: [EXTERNAL] Re: help with version range

[Robert Patrick]

That one is even worse, pom parsing fails...

[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[ERROR] 'dependencies.dependency.version' for myproject:util:jar must not 
contain any of these characters \/:"<>|?* but found * @ 
myproject:zip-installer:[unknown-version], C:\myproject\zipinsall\pom.xml, line 
196, column 22



-Original Message-
From: Christian Schulte [mailto:c...@schulte.it] 
Sent: Friday, September 23, 2016 5:17 PM
To: Maven Users List
Subject: Re: [EXTERNAL] Re: help with version range

Am 09/23/16 um 23:38 schrieb Robert Patrick:
> This is nice, but it doesn’t work in Maven 3.3.9...
> 
> [ERROR] org.apache.maven.project.artifact.InvalidDependencyVersionException: 
> Invalid version: [0.8.min,0.8.max] found for: Dependency: myproject:util in 
> project: myproject:zip-installer:pom:0.9-SNAPSHOT. Reason: Range defies 
> version ordering: [0.8.min,0.8.max) for project 
> myproject:zip-installer:pom:0.9-SNAPSHOT at 
> C:\tmp\myproject\zipinstall\pom.xml -> [Help 1]

I have no test project at hand. Did you try "[0.8.*]" as well?

Regards,
-- 
Christian


-
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: [EXTERNAL] Re: help with version range

[Christian Schulte]

Am 09/23/16 um 23:38 schrieb Robert Patrick:
> This is nice, but it doesn’t work in Maven 3.3.9...
> 
> [ERROR] org.apache.maven.project.artifact.InvalidDependencyVersionException: 
> Invalid version: [0.8.min,0.8.max] found for: Dependency: myproject:util in 
> project: myproject:zip-installer:pom:0.9-SNAPSHOT. Reason: Range defies 
> version ordering: [0.8.min,0.8.max) for project 
> myproject:zip-installer:pom:0.9-SNAPSHOT at 
> C:\tmp\myproject\zipinstall\pom.xml -> [Help 1]

I have no test project at hand. Did you try "[0.8.*]" as well?

Regards,
-- 
Christian


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: [EXTERNAL] Re: help with version range

[Robert Patrick]

This is nice, but it doesn’t work in Maven 3.3.9...

[ERROR] org.apache.maven.project.artifact.InvalidDependencyVersionException: 
Invalid version: [0.8.min,0.8.max] found for: Dependency: myproject:util in 
project: myproject:zip-installer:pom:0.9-SNAPSHOT. Reason: Range defies version 
ordering: [0.8.min,0.8.max) for project 
myproject:zip-installer:pom:0.9-SNAPSHOT at C:\tmp\myproject\zipinstall\pom.xml 
-> [Help 1]

--
Robert Patrick 
VP, OPC Development, Oracle Corporation
7460 Warren Pkwy, Ste. 300  Office: +1.972.963.2872
Frisco, TX 75034, USA   Mobile: +1.469.556.9450

Professional Oracle WebLogic Server
by Robert Patrick, Gregory Nyberg, and Philip Aston
with Josh Bregman and Paul Done
Book Home Page: http://www.wrox.com/
Kindle Version: http://www.amazon.com/


-Original Message-
From: Christian Schulte [mailto:c...@schulte.it] 
Sent: Friday, September 23, 2016 4:23 PM
To: Maven Users List
Cc: i...@soebes.de
Subject: Re: [EXTERNAL] Re: help with version range

Am 09/23/16 um 23:07 schrieb Robert Patrick:
> There is already a syntax to give you pre-release versions, right?  
> According to 
> https://maven.apache.org/ref/3.3.9/maven-artifact/apidocs/org/apache/m
> aven/artifact/versioning/ComparableVersion.html, the range 
> [1.0,2.0-SNAPSHOT] will give you the newest release including all 2.0 
> prerelease versions but not the 2.0 GA release so there is no reason 
> you need [1.0,2.0) to do the exact same thing... :-)
> 

I haven't tested this but I think what is written here also applies to Maven. 
You would need to test that yourself.

<http://wiki.eclipse.org/Aether/New_and_Noteworthy#Version_Ranges>

Regards,
--
Christian


-
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: [EXTERNAL] Re: help with version range

[Christian Schulte]

Am 09/23/16 um 23:07 schrieb Robert Patrick:
> There is already a syntax to give you pre-release versions, right?  According 
> to 
> https://maven.apache.org/ref/3.3.9/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html,
>  the range [1.0,2.0-SNAPSHOT] will give you the newest release including all 
> 2.0 prerelease versions but not the 2.0 GA release so there is no reason you 
> need [1.0,2.0) to do the exact same thing... :-)
> 

I haven't tested this but I think what is written here also applies to
Maven. You would need to test that yourself.



Regards,
-- 
Christian


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: [EXTERNAL] Re: help with version range

[Robert Patrick]

There is already a syntax to give you pre-release versions, right?  According 
to 
https://maven.apache.org/ref/3.3.9/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html,
 the range [1.0,2.0-SNAPSHOT] will give you the newest release including all 
2.0 prerelease versions but not the 2.0 GA release so there is no reason you 
need [1.0,2.0) to do the exact same thing... :-)

Mark D's workaround is a pragmatic approach.

As for why I don’t get involved, I tend to be selective about where I spend my 
time and since we eliminated the use of version ranges in our projects for 
multiple reasons, addressing this issue doesn't really meet my bar for 
investing my time to contribute.  I do contribute periodically, still waiting 
on my latest bug fix to be integrated 
(https://issues.apache.org/jira/browse/MNG-5889)... 

Cheers,
Robert

-Original Message-
From: Curtis Rueden [mailto:ctrue...@wisc.edu] 
Sent: Friday, September 23, 2016 3:45 PM
To: Maven Users List
Cc: i...@soebes.de
Subject: Re: [EXTERNAL] Re: help with version range

Hi Robert,

> most people that use version ranges that use a non-inclusive top-end 
> specification do not want prerelease versions included.  I have yet to 
> hear you or anyone else give me a use case where you want this.

Personally, I want prerelease versions included.

I think it is unsubstantiated to claim "most people" here.

> There should be a simple way to achieve this

I agree. Why not propose a new syntax, or even a patch? Maven is open source.

Regards,
Curtis


--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden Did you know 
ImageJ has a forum? http://forum.imagej.net/


On Fri, Sep 23, 2016 at 3:41 PM, Robert Patrick 
wrote:

> Well...like I said, I understand the relationship but clearly, most 
> people that use version ranges that use a non-inclusive top-end 
> specification do not want prerelease versions included.  I have yet to 
> hear you or anyone else give me a use case where you want this.
>
> The fact that I have to fight Maven to achieve this is a pain--and I 
> have been using Maven for many years now.  There should be a simple 
> way to achieve this that does not require me to do something like this:
>
> [1.0,1.
> 999)
>
>
> -Original Message-
> From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
> Sent: Friday, September 23, 2016 3:30 PM
> To: Maven Users List
> Subject: Re: [EXTERNAL] Re: help with version range
>
> Hi,
>
> On 23/09/16 18:38, Robert Patrick wrote:
> >
> > What I am questioning is the "engineer's approach" to version range 
> > resolution without
>  > a valid use case for why Maven should consider  > pre-released 
> versions as within the "not including 2.0" version  > range semantics.
>
> The simple answer to this is the timeline of those releases...
> So a pre-release (2.0-alpha-1, 2.0-RC1 etc.) will be done before the 
> final release (2.0) so must be defined as before...
>
> Kind regards
> Karl Heinz Marbaise
>
>
>
> -
> 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
>
>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: help with version range

[Mark Derricutt]

On 24 Sep 2016, at 1:38, Justin Georgeson wrote:

> ’m using the parent version range feature with “[1.1.0,1.2.0)” and it had 
> been going well. However I wanted to start working on 1.2.0 of the parent, so 
> I published a 1.2.0-alpha-1 version. And all the projects with te 
> “[1.1.0,1.2.0)” picked it up. I recognize that this is in keeping with the 
> implementation that x.y.z-(alpha|beta|…) precedes x.y.z, but it is 
> unintuitive to me. First in that I’ve stated I don’t want 1.2.0, and second 
> that once I do release 1.2.0 the projects which were receiving the alpha 
> builds will not get 1.2.0. I tried with both 3.2.5 and 3.3.9. Can the version 
> range syntax express the range I want?

We have a standing practise of NEVER releasing .0 releases for this very 
reason.  Our ranges tend to be [1.0.0,2.0.0)  but the first version would 
always be 2.0.1-SNAPSHOT.

Thinking about it, I should write an enforcement plugin rule that also traps 
that.


-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

Re: [EXTERNAL] Re: help with version range

[Curtis Rueden]

Hi Robert,

> most people that use version ranges that use a non-inclusive top-end
> specification do not want prerelease versions included.  I have yet to
> hear you or anyone else give me a use case where you want this.

Personally, I want prerelease versions included.

I think it is unsubstantiated to claim "most people" here.

> There should be a simple way to achieve this

I agree. Why not propose a new syntax, or even a patch? Maven is open
source.

Regards,
Curtis


--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
Did you know ImageJ has a forum? http://forum.imagej.net/


On Fri, Sep 23, 2016 at 3:41 PM, Robert Patrick 
wrote:

> Well...like I said, I understand the relationship but clearly, most people
> that use version ranges that use a non-inclusive top-end specification do
> not want prerelease versions included.  I have yet to hear you or anyone
> else give me a use case where you want this.
>
> The fact that I have to fight Maven to achieve this is a pain--and I have
> been using Maven for many years now.  There should be a simple way to
> achieve this that does not require me to do something like this:
>
> [1.0,1.
> 999)
>
>
> -Original Message-
> From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
> Sent: Friday, September 23, 2016 3:30 PM
> To: Maven Users List
> Subject: Re: [EXTERNAL] Re: help with version range
>
> Hi,
>
> On 23/09/16 18:38, Robert Patrick wrote:
> >
> > What I am questioning is the "engineer's approach" to version range
> > resolution without
>  > a valid use case for why Maven should consider  > pre-released versions
> as within the "not including 2.0" version  > range semantics.
>
> The simple answer to this is the timeline of those releases...
> So a pre-release (2.0-alpha-1, 2.0-RC1 etc.) will be done before the final
> release (2.0) so must be defined as before...
>
> Kind regards
> Karl Heinz Marbaise
>
>
>
> -
> 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: [EXTERNAL] Re: help with version range

[Robert Patrick]

Well...like I said, I understand the relationship but clearly, most people that 
use version ranges that use a non-inclusive top-end specification do not want 
prerelease versions included.  I have yet to hear you or anyone else give me a 
use case where you want this.

The fact that I have to fight Maven to achieve this is a pain--and I have been 
using Maven for many years now.  There should be a simple way to achieve this 
that does not require me to do something like this:

[1.0,1.999)


-Original Message-
From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de] 
Sent: Friday, September 23, 2016 3:30 PM
To: Maven Users List
Subject: Re: [EXTERNAL] Re: help with version range

Hi,

On 23/09/16 18:38, Robert Patrick wrote:
>
> What I am questioning is the "engineer's approach" to version range 
> resolution without
 > a valid use case for why Maven should consider  > pre-released versions as 
 > within the "not including 2.0" version  > range semantics.

The simple answer to this is the timeline of those releases...
So a pre-release (2.0-alpha-1, 2.0-RC1 etc.) will be done before the final 
release (2.0) so must be defined as before...

Kind regards
Karl Heinz Marbaise



-
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: [EXTERNAL] Re: help with version range

[Karl Heinz Marbaise]

Hi,

BTW the behaviour of Maven's version comparision can be simply
shown by using the following:

java -jar /usr/local/apache-maven-3.3.9/lib/maven-artifact-3.3.9.jar 
2.0-alpha-1 2.0-SNAPSHOT
Display parameters as parsed by Maven (in canonical form) and comparison 
result:

1. 2.0-alpha-1 == 2-alpha-1
   2.0-alpha-1 < 2.0-SNAPSHOT
2. 2.0-SNAPSHOT == 2-snapshot

Kind regards
Karl Heinz Marbaise

PS.: This is part of Maven since Maven 
3.2.5(https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12330189).




On 23/09/16 22:29, Karl Heinz Marbaise wrote:

Hi,

On 23/09/16 18:38, Robert Patrick wrote:


What I am questioning is the "engineer's approach" to version range
resolution without
a valid use case for why Maven should consider
pre-released versions as within the "not including 2.0" version
range semantics.


The simple answer to this is the timeline of those releases...
So a pre-release (2.0-alpha-1, 2.0-RC1 etc.) will be done before the
final release (2.0) so must be defined as before...

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: [EXTERNAL] Re: help with version range

[Karl Heinz Marbaise]

Hi,

On 23/09/16 18:38, Robert Patrick wrote:


What I am questioning is the "engineer's approach" to version range resolution 
without

> a valid use case for why Maven should consider
> pre-released versions as within the "not including 2.0" version
> range semantics.

The simple answer to this is the timeline of those releases...
So a pre-release (2.0-alpha-1, 2.0-RC1 etc.) will be done before the 
final release (2.0) so must be defined as before...


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: [EXTERNAL] Re: help with version range

[Robert Scholte]

(2|2.0|2.0.0)-(a|alpha)-SNAPSHOT


Verzonden vanaf Samsung Mobile.

 Oorspronkelijk bericht Van: Robert Patrick 
 Datum:23-09-2016  11:18  (GMT-08:00) 
Aan: Maven Users List  Onderwerp: 
RE: [EXTERNAL] Re: help with version range 
So then the right range to keep all 2.0 pre-release artifacts out of the 
build is [1.0,2.0-a)?



-Original Message-
From: Guillaume Boué [mailto:gb...@apache.org] 
Sent: Friday, September 23, 2016 12:12 PM
To: users@maven.apache.org
Subject: Re: [EXTERNAL] Re: help with version range

Maven will consider 2.0-alpha-1 to be before 2.0-SNAPSHOT. This is documented 
in ComparableVersion: 
https://maven.apache.org/ref/3.3.9/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html.

Guillaume

Le 23/09/2016 à 18:49, Robert Patrick a écrit :
> I was not suggesting that it could be changed...only that it doesn't make 
> sense (except from a pure mathematical point of view).
>
> Given this "engineer's approach" to version range resolution, it seems like a 
> better idea is simply to say [1.0,2.0-SNAPSHOT).  I have verified that this 
> eliminates 2.0-SNAPSHOT versions.  However, what I have not verified is what 
> happens when you have other pre-release versions (e.g., 2.0-alpha-1).  Is 
> 2.0-SNAPSHOT always considered as older than non-SNAPSHOT pre-release 
> versions like alpha, beta, etc?
>
>
> -Original Message-
> From: Manfred Moser [mailto:manf...@simpligility.com]
> Sent: Friday, September 23, 2016 11:47 AM
> To: users@maven.apache.org
> Subject: Re: [EXTERNAL] Re: help with version range
>
> Fair enough. From the purely engineering/mathematical point of view it might 
> not make sense. But I dont see a way to get that changed with breaking a TON 
> of other stuff. And I am not even sure if it would be more intuitive instead 
> of just being different.
>
> Manfred
>
> Robert Patrick wrote on 2016-09-23 09:38:
>
>> No, you are making an invalid assumption about what I understand!  I 
>> completely understand the relationship of SNAPSHOTs and other 
>> pre-release artifacts and released versions.
>>
>> What I am questioning is the "engineer's approach" to version range 
>> resolution without a valid use case for why Maven should consider 
>> pre-released versions as within the "not including 2.0" version range 
>> semantics.
>>
>>
>> -Original Message-
>> From: Manfred Moser [mailto:manf...@simpligility.com]
>> Sent: Friday, September 23, 2016 11:32 AM
>> To: users@maven.apache.org
>> Subject: Re: [EXTERNAL] Re: help with version range
>>
>> What you are misunderstanding is how snapshots are meant to be used.
>> 2.0-SNAPSHOT means that it is a development version working towards 
>> the release of 2.0 and as such the version 2.0-SNAPSHOT is smaller than 2.0.
>>
>> If you mislike this you can change how you work with your own 
>> projects at least. .. you can just call your snapshot version 
>> 1.99-SNAPSHOT or whatever while developing and at releas time switch to 2.0 
>> ..
>>
>> Manfred
>>
>> Robert Patrick wrote on 2016-09-23 08:56:
>>
>>> This does seem non-intuitive.If I say that I want versions  between 1.0
>>> and
>>> up to but NOT including 2.0 by saying [1.0,2.0), in what use case 
>>> would I ever want this to resolve to 2.0-SNAPSHOT or any other 
>>> pre-release 2.0 artifact?
>>> Personally, I cannot think of a single one.
>>>
>>> Typically, what I mean when I say [1.0,2.0) is any 1.x version but 
>>> nothing related to 2.0...
>>>
>>> -Original Message-
>>> From: Justin Georgeson [mailto:jgeorge...@lgc.com]
>>> Sent: Friday, September 23, 2016 10:11 AM
>>> To: Maven Users List
>>> Subject: RE: [EXTERNAL] Re: help with version range
>>>
>>> Yeah, I was hoping there was something more elegant like 1.1+ or 
>>> something, so I can at least move forward with that.
>>>
>>> Logically, does it make sense to resolve 1.2.0-alpha-1 when the user 
>>> has excluded 1.2.0 from their range? If I explicitly don't want the 
>>> release version why would I want the pre-release versions?
>>>
>>> -Original Message-
>>> From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On 
>>> Behalf Of Curtis Rueden
>>> Sent: Friday, September 23, 2016 9:01 AM
>>> To: Maven Users List
>>> Subject: [EXTERNAL] Re: help with version range
>>>
>>> Hi Justin,
>>>
>>> You could write "[1.1.0,1.1.9]", no? A bit 

RE: [EXTERNAL] Re: help with version range

[Robert Patrick]

So then the right range to keep all 2.0 pre-release artifacts out of the build 
is [1.0,2.0-a)?



-Original Message-
From: Guillaume Boué [mailto:gb...@apache.org] 
Sent: Friday, September 23, 2016 12:12 PM
To: users@maven.apache.org
Subject: Re: [EXTERNAL] Re: help with version range

Maven will consider 2.0-alpha-1 to be before 2.0-SNAPSHOT. This is documented 
in ComparableVersion: 
https://maven.apache.org/ref/3.3.9/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html.

Guillaume

Le 23/09/2016 à 18:49, Robert Patrick a écrit :
> I was not suggesting that it could be changed...only that it doesn't make 
> sense (except from a pure mathematical point of view).
>
> Given this "engineer's approach" to version range resolution, it seems like a 
> better idea is simply to say [1.0,2.0-SNAPSHOT).  I have verified that this 
> eliminates 2.0-SNAPSHOT versions.  However, what I have not verified is what 
> happens when you have other pre-release versions (e.g., 2.0-alpha-1).  Is 
> 2.0-SNAPSHOT always considered as older than non-SNAPSHOT pre-release 
> versions like alpha, beta, etc?
>
>
> -Original Message-
> From: Manfred Moser [mailto:manf...@simpligility.com]
> Sent: Friday, September 23, 2016 11:47 AM
> To: users@maven.apache.org
> Subject: Re: [EXTERNAL] Re: help with version range
>
> Fair enough. From the purely engineering/mathematical point of view it might 
> not make sense. But I dont see a way to get that changed with breaking a TON 
> of other stuff. And I am not even sure if it would be more intuitive instead 
> of just being different.
>
> Manfred
>
> Robert Patrick wrote on 2016-09-23 09:38:
>
>> No, you are making an invalid assumption about what I understand!  I 
>> completely understand the relationship of SNAPSHOTs and other 
>> pre-release artifacts and released versions.
>>
>> What I am questioning is the "engineer's approach" to version range 
>> resolution without a valid use case for why Maven should consider 
>> pre-released versions as within the "not including 2.0" version range 
>> semantics.
>>
>>
>> -Original Message-
>> From: Manfred Moser [mailto:manf...@simpligility.com]
>> Sent: Friday, September 23, 2016 11:32 AM
>> To: users@maven.apache.org
>> Subject: Re: [EXTERNAL] Re: help with version range
>>
>> What you are misunderstanding is how snapshots are meant to be used.
>> 2.0-SNAPSHOT means that it is a development version working towards 
>> the release of 2.0 and as such the version 2.0-SNAPSHOT is smaller than 2.0.
>>
>> If you mislike this you can change how you work with your own 
>> projects at least. .. you can just call your snapshot version 
>> 1.99-SNAPSHOT or whatever while developing and at releas time switch to 2.0 
>> ..
>>
>> Manfred
>>
>> Robert Patrick wrote on 2016-09-23 08:56:
>>
>>> This does seem non-intuitive.If I say that I want versions  between 1.0
>>> and
>>> up to but NOT including 2.0 by saying [1.0,2.0), in what use case 
>>> would I ever want this to resolve to 2.0-SNAPSHOT or any other 
>>> pre-release 2.0 artifact?
>>> Personally, I cannot think of a single one.
>>>
>>> Typically, what I mean when I say [1.0,2.0) is any 1.x version but 
>>> nothing related to 2.0...
>>>
>>> -Original Message-
>>> From: Justin Georgeson [mailto:jgeorge...@lgc.com]
>>> Sent: Friday, September 23, 2016 10:11 AM
>>> To: Maven Users List
>>> Subject: RE: [EXTERNAL] Re: help with version range
>>>
>>> Yeah, I was hoping there was something more elegant like 1.1+ or 
>>> something, so I can at least move forward with that.
>>>
>>> Logically, does it make sense to resolve 1.2.0-alpha-1 when the user 
>>> has excluded 1.2.0 from their range? If I explicitly don't want the 
>>> release version why would I want the pre-release versions?
>>>
>>> -Original Message-
>>> From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On 
>>> Behalf Of Curtis Rueden
>>> Sent: Friday, September 23, 2016 9:01 AM
>>> To: Maven Users List
>>> Subject: [EXTERNAL] Re: help with version range
>>>
>>> Hi Justin,
>>>
>>> You could write "[1.1.0,1.1.9]", no? A bit hacky, but would 
>>> match the versions you want in practice.
>>>
>>> Regards,
>>> Curtis
>>>
>>> On Sep 23, 2016 8:38 AM, "Justin Georgeson"  wrote:
>>>
&

Re: [EXTERNAL] Re: help with version range

[Guillaume Boué]

Maven will consider 2.0-alpha-1 to be before 2.0-SNAPSHOT. This is 
documented in ComparableVersion: 
https://maven.apache.org/ref/3.3.9/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html.


Guillaume

Le 23/09/2016 à 18:49, Robert Patrick a écrit :

I was not suggesting that it could be changed...only that it doesn't make sense 
(except from a pure mathematical point of view).

Given this "engineer's approach" to version range resolution, it seems like a 
better idea is simply to say [1.0,2.0-SNAPSHOT).  I have verified that this eliminates 
2.0-SNAPSHOT versions.  However, what I have not verified is what happens when you have 
other pre-release versions (e.g., 2.0-alpha-1).  Is 2.0-SNAPSHOT always considered as 
older than non-SNAPSHOT pre-release versions like alpha, beta, etc?


-Original Message-
From: Manfred Moser [mailto:manf...@simpligility.com]
Sent: Friday, September 23, 2016 11:47 AM
To: users@maven.apache.org
Subject: Re: [EXTERNAL] Re: help with version range

Fair enough. From the purely engineering/mathematical point of view it might 
not make sense. But I dont see a way to get that changed with breaking a TON of 
other stuff. And I am not even sure if it would be more intuitive instead of 
just being different.

Manfred

Robert Patrick wrote on 2016-09-23 09:38:


No, you are making an invalid assumption about what I understand!  I
completely understand the relationship of SNAPSHOTs and other
pre-release artifacts and released versions.

What I am questioning is the "engineer's approach" to version range
resolution without a valid use case for why Maven should consider
pre-released versions as within the "not including 2.0" version range semantics.


-Original Message-
From: Manfred Moser [mailto:manf...@simpligility.com]
Sent: Friday, September 23, 2016 11:32 AM
To: users@maven.apache.org
Subject: Re: [EXTERNAL] Re: help with version range

What you are misunderstanding is how snapshots are meant to be used.
2.0-SNAPSHOT means that it is a development version working towards
the release of 2.0 and as such the version 2.0-SNAPSHOT is smaller than 2.0.

If you mislike this you can change how you work with your own projects
at least. .. you can just call your snapshot version 1.99-SNAPSHOT or
whatever while developing and at releas time switch to 2.0 ..

Manfred

Robert Patrick wrote on 2016-09-23 08:56:


This does seem non-intuitive.If I say that I want versions  between 1.0
and
up to but NOT including 2.0 by saying [1.0,2.0), in what use case
would I ever want this to resolve to 2.0-SNAPSHOT or any other
pre-release 2.0 artifact?
Personally, I cannot think of a single one.

Typically, what I mean when I say [1.0,2.0) is any 1.x version but
nothing related to 2.0...

-Original Message-
From: Justin Georgeson [mailto:jgeorge...@lgc.com]
Sent: Friday, September 23, 2016 10:11 AM
To: Maven Users List
Subject: RE: [EXTERNAL] Re: help with version range

Yeah, I was hoping there was something more elegant like 1.1+ or
something, so I can at least move forward with that.

Logically, does it make sense to resolve 1.2.0-alpha-1 when the user
has excluded 1.2.0 from their range? If I explicitly don't want the
release version why would I want the pre-release versions?

-Original Message-
From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On
Behalf Of Curtis Rueden
Sent: Friday, September 23, 2016 9:01 AM
To: Maven Users List
Subject: [EXTERNAL] Re: help with version range

Hi Justin,

You could write "[1.1.0,1.1.9]", no? A bit hacky, but would match
the versions you want in practice.

Regards,
Curtis

On Sep 23, 2016 8:38 AM, "Justin Georgeson"  wrote:


I’m using the parent version range feature with “[1.1.0,1.2.0)” and
it had been going well. However I wanted to start working on 1.2.0
of the parent, so I published a 1.2.0-alpha-1 version. And all the
projects with te “[1.1.0,1.2.0)” picked it up. I recognize that this
is in keeping with the implementation that x.y.z-(alpha|beta|…)
precedes x.y.z, but it is unintuitive to me. First in that I’ve
stated I don’t want 1.2.0, and second that once I do release 1.2.0
the projects which were receiving the alpha builds will not get
1.2.0. I tried with both
3.2.5 and 3.3.9. Can the version range syntax express the range I want?



*Justin Georgeson*
Landmark Cloud Platforms & DevOps - RM

Email: *jgeorge...@lgc.com* 

Follow Halliburton: *LinkedIn*
<https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dh
o
s
t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatu
r
e
s-255d-26url-3Dhttp-3A__www.linkedin.com_company_halliburton&d=DQIFa
Q
&
c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_
O
V
ZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&
s = 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM&e= >
| *Facebook*

RE: [EXTERNAL] Re: help with version range

[Robert Patrick]

I was not suggesting that it could be changed...only that it doesn't make sense 
(except from a pure mathematical point of view).

Given this "engineer's approach" to version range resolution, it seems like a 
better idea is simply to say [1.0,2.0-SNAPSHOT).  I have verified that this 
eliminates 2.0-SNAPSHOT versions.  However, what I have not verified is what 
happens when you have other pre-release versions (e.g., 2.0-alpha-1).  Is 
2.0-SNAPSHOT always considered as older than non-SNAPSHOT pre-release versions 
like alpha, beta, etc?


-Original Message-
From: Manfred Moser [mailto:manf...@simpligility.com] 
Sent: Friday, September 23, 2016 11:47 AM
To: users@maven.apache.org
Subject: Re: [EXTERNAL] Re: help with version range

Fair enough. From the purely engineering/mathematical point of view it might 
not make sense. But I dont see a way to get that changed with breaking a TON of 
other stuff. And I am not even sure if it would be more intuitive instead of 
just being different.

Manfred

Robert Patrick wrote on 2016-09-23 09:38:

> No, you are making an invalid assumption about what I understand!  I 
> completely understand the relationship of SNAPSHOTs and other 
> pre-release artifacts and released versions.
> 
> What I am questioning is the "engineer's approach" to version range 
> resolution without a valid use case for why Maven should consider 
> pre-released versions as within the "not including 2.0" version range 
> semantics.
> 
> 
> -Original Message-
> From: Manfred Moser [mailto:manf...@simpligility.com]
> Sent: Friday, September 23, 2016 11:32 AM
> To: users@maven.apache.org
> Subject: Re: [EXTERNAL] Re: help with version range
> 
> What you are misunderstanding is how snapshots are meant to be used.
> 2.0-SNAPSHOT means that it is a development version working towards 
> the release of 2.0 and as such the version 2.0-SNAPSHOT is smaller than 2.0.
> 
> If you mislike this you can change how you work with your own projects 
> at least. .. you can just call your snapshot version 1.99-SNAPSHOT or 
> whatever while developing and at releas time switch to 2.0 ..
> 
> Manfred
> 
> Robert Patrick wrote on 2016-09-23 08:56:
> 
>> This does seem non-intuitive.If I say that I want versions  between 1.0
>> and
>> up to but NOT including 2.0 by saying [1.0,2.0), in what use case 
>> would I ever want this to resolve to 2.0-SNAPSHOT or any other 
>> pre-release 2.0 artifact?
>> Personally, I cannot think of a single one.
>> 
>> Typically, what I mean when I say [1.0,2.0) is any 1.x version but 
>> nothing related to 2.0...
>> 
>> -Original Message-
>> From: Justin Georgeson [mailto:jgeorge...@lgc.com]
>> Sent: Friday, September 23, 2016 10:11 AM
>> To: Maven Users List
>> Subject: RE: [EXTERNAL] Re: help with version range
>> 
>> Yeah, I was hoping there was something more elegant like 1.1+ or 
>> something, so I can at least move forward with that.
>> 
>> Logically, does it make sense to resolve 1.2.0-alpha-1 when the user 
>> has excluded 1.2.0 from their range? If I explicitly don't want the 
>> release version why would I want the pre-release versions?
>> 
>> -Original Message-
>> From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On 
>> Behalf Of Curtis Rueden
>> Sent: Friday, September 23, 2016 9:01 AM
>> To: Maven Users List
>> Subject: [EXTERNAL] Re: help with version range
>> 
>> Hi Justin,
>> 
>> You could write "[1.1.0,1.1.9]", no? A bit hacky, but would match 
>> the versions you want in practice.
>> 
>> Regards,
>> Curtis
>> 
>> On Sep 23, 2016 8:38 AM, "Justin Georgeson"  wrote:
>> 
>>> I’m using the parent version range feature with “[1.1.0,1.2.0)” and 
>>> it had been going well. However I wanted to start working on 1.2.0 
>>> of the parent, so I published a 1.2.0-alpha-1 version. And all the 
>>> projects with te “[1.1.0,1.2.0)” picked it up. I recognize that this 
>>> is in keeping with the implementation that x.y.z-(alpha|beta|…) 
>>> precedes x.y.z, but it is unintuitive to me. First in that I’ve 
>>> stated I don’t want 1.2.0, and second that once I do release 1.2.0 
>>> the projects which were receiving the alpha builds will not get 
>>> 1.2.0. I tried with both
>>> 3.2.5 and 3.3.9. Can the version range syntax express the range I want?
>>>
>>>
>>>
>>> *Justin Georgeson*
>>> Landmark Cloud Platforms & DevOps - RM
>>>
>>> Email: *jgeorge...@lgc.com* 
>>>
>>> Fo

Re: [EXTERNAL] Re: help with version range

[Manfred Moser]

Fair enough. From the purely engineering/mathematical point of view it might 
not make sense. But I dont see a way to get that changed with breaking a TON of 
other stuff. And I am not even sure if it would be more intuitive instead of 
just being different.

Manfred

Robert Patrick wrote on 2016-09-23 09:38:

> No, you are making an invalid assumption about what I understand!  I 
> completely
> understand the relationship of SNAPSHOTs and other pre-release artifacts and
> released versions.  
> 
> What I am questioning is the "engineer's approach" to version range resolution
> without a valid use case for why Maven should consider pre-released versions 
> as
> within the "not including 2.0" version range semantics.
> 
> 
> -Original Message-
> From: Manfred Moser [mailto:manf...@simpligility.com] 
> Sent: Friday, September 23, 2016 11:32 AM
> To: users@maven.apache.org
> Subject: Re: [EXTERNAL] Re: help with version range
> 
> What you are misunderstanding is how snapshots are meant to be used.
> 2.0-SNAPSHOT means that it is a development version working towards the 
> release
> of 2.0 and as such the version 2.0-SNAPSHOT is smaller than 2.0.
> 
> If you mislike this you can change how you work with your own projects at
> least. .. you can just call your snapshot version 1.99-SNAPSHOT or whatever
> while developing and at releas time switch to 2.0 .. 
> 
> Manfred
> 
> Robert Patrick wrote on 2016-09-23 08:56:
> 
>> This does seem non-intuitive.If I say that I want versions  between 1.0
>> and
>> up to but NOT including 2.0 by saying [1.0,2.0), in what use case 
>> would I ever want this to resolve to 2.0-SNAPSHOT or any other pre-release 
>> 2.0
>> artifact?
>> Personally, I cannot think of a single one.
>> 
>> Typically, what I mean when I say [1.0,2.0) is any 1.x version but 
>> nothing related to 2.0...
>> 
>> -Original Message-
>> From: Justin Georgeson [mailto:jgeorge...@lgc.com]
>> Sent: Friday, September 23, 2016 10:11 AM
>> To: Maven Users List
>> Subject: RE: [EXTERNAL] Re: help with version range
>> 
>> Yeah, I was hoping there was something more elegant like 1.1+ or 
>> something, so I can at least move forward with that.
>> 
>> Logically, does it make sense to resolve 1.2.0-alpha-1 when the user 
>> has excluded 1.2.0 from their range? If I explicitly don't want the 
>> release version why would I want the pre-release versions?
>> 
>> -Original Message-
>> From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On 
>> Behalf Of Curtis Rueden
>> Sent: Friday, September 23, 2016 9:01 AM
>> To: Maven Users List
>> Subject: [EXTERNAL] Re: help with version range
>> 
>> Hi Justin,
>> 
>> You could write "[1.1.0,1.1.9]", no? A bit hacky, but would match 
>> the versions you want in practice.
>> 
>> Regards,
>> Curtis
>> 
>> On Sep 23, 2016 8:38 AM, "Justin Georgeson"  wrote:
>> 
>>> I’m using the parent version range feature with “[1.1.0,1.2.0)” and 
>>> it had been going well. However I wanted to start working on 1.2.0 of 
>>> the parent, so I published a 1.2.0-alpha-1 version. And all the 
>>> projects with te “[1.1.0,1.2.0)” picked it up. I recognize that this 
>>> is in keeping with the implementation that x.y.z-(alpha|beta|…) 
>>> precedes x.y.z, but it is unintuitive to me. First in that I’ve 
>>> stated I don’t want 1.2.0, and second that once I do release 1.2.0 
>>> the projects which were receiving the alpha builds will not get 
>>> 1.2.0. I tried with both
>>> 3.2.5 and 3.3.9. Can the version range syntax express the range I want?
>>>
>>>
>>>
>>> *Justin Georgeson*
>>> Landmark Cloud Platforms & DevOps - RM
>>>
>>> Email: *jgeorge...@lgc.com* 
>>>
>>> Follow Halliburton: *LinkedIn*
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dho
>>> s 
>>> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
>>> e 
>>> s-255d-26url-3Dhttp-3A__www.linkedin.com_company_halliburton&d=DQIFaQ
>>> & 
>>> c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_O
>>> V 
>>> ZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s
>>> = 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM&e= >
>>> | *Facebook*
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dh
>>> o 
>>> st.net_gopc.url-

Re: [EXTERNAL] Re: help with version range

[Curtis Rueden]

Hi Justin,

> Logically, does it make sense to resolve 1.2.0-alpha-1 when the user
> has excluded 1.2.0 from their range? If I explicitly don't want the
> release version why would I want the pre-release versions?

I think it really depends how you use those version suffixes. For example,
I have a component which is currently at 2.0.0-rc-55 (yeah, yeah, 55
"release candidates" is insane, I know). To me, it makes sense that
[1.0.0,2.0.0-rc-55) should match 2.0.0-rc-54.

Anyway, it is way too late to change the behavior. But you're right that an
enhancement to the syntax here might be doable. I leave it to the Maven
core folks to comment on that though.

Regards,
Curtis



On Fri, Sep 23, 2016 at 10:11 AM, Justin Georgeson 
wrote:

> Yeah, I was hoping there was something more elegant like 1.1+ or
> something, so I can at least move forward with that.
>
> Logically, does it make sense to resolve 1.2.0-alpha-1 when the user has
> excluded 1.2.0 from their range? If I explicitly don't want the release
> version why would I want the pre-release versions?
>
> -Original Message-
> From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On Behalf
> Of Curtis Rueden
> Sent: Friday, September 23, 2016 9:01 AM
> To: Maven Users List
> Subject: [EXTERNAL] Re: help with version range
>
> Hi Justin,
>
> You could write "[1.1.0,1.1.9]", no? A bit hacky, but would match the
> versions you want in practice.
>
> Regards,
> Curtis
>
> On Sep 23, 2016 8:38 AM, "Justin Georgeson"  wrote:
>
> > I’m using the parent version range feature with “[1.1.0,1.2.0)” and it
> > had been going well. However I wanted to start working on 1.2.0 of the
> > parent, so I published a 1.2.0-alpha-1 version. And all the projects
> > with te “[1.1.0,1.2.0)” picked it up. I recognize that this is in
> > keeping with the implementation that x.y.z-(alpha|beta|…) precedes
> > x.y.z, but it is unintuitive to me. First in that I’ve stated I don’t
> > want 1.2.0, and second that once I do release 1.2.0 the projects which
> > were receiving the alpha builds will not get 1.2.0. I tried with both
> > 3.2.5 and 3.3.9. Can the version range syntax express the range I want?
> >
> >
> >
> > *Justin Georgeson*
> > Landmark Cloud Platforms & DevOps - RM
> >
> > Email: *jgeorge...@lgc.com* 
> >
> > Follow Halliburton: *LinkedIn*
> > <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
> > t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
> > s-255d-26url-3Dhttp-3A__www.linkedin.com_company_halliburton&d=DQIFaQ&
> > c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OV
> > ZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=
> > 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM&e= >
> > | *Facebook*
> > <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dho
> > st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
> > es-255d-26url-3Dhttps-3A__www.facebook.com_halliburton&d=DQIFaQ&c=Pskv
> > ixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyu
> > i4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=NgT-wO
> > jrb7gpKDJVcRDMmKUQqGfR-PSnXe3I98Lp1c4&e= >
> > | *Twitter*
> > <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dho
> > st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
> > es-255d-26url-3Dhttps-3A__twitter.com_halliburton&d=DQIFaQ&c=PskvixtEU
> > DK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoE
> > mBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=-swEvm-8NW2
> > 18tPAkOpg46kdPblTNts2y7dbe_w82wM&e= >
> > | *YouTube*
> > <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
> > t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
> > s-255d-26url-3Dhttp-3A__youtube.com_halliburton&d=DQIFaQ&c=PskvixtEUDK
> > 7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmB
> > CjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=dTvvV1RKdjYSK
> > _Hc5JX55QI7b2j-A4O9RAX2Dg9qbrU&e= >
> > | *Blog*
> > <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
> > t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
> > s-255d-26url-3Dhttp-3A__halliburtonblog.com&d=DQIFaQ&c=PskvixtEUDK7wuW
> > U-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCm
> > EiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCp

RE: [EXTERNAL] Re: help with version range

[Robert Patrick]

No, you are making an invalid assumption about what I understand!  I completely 
understand the relationship of SNAPSHOTs and other pre-release artifacts and 
released versions.  

What I am questioning is the "engineer's approach" to version range resolution 
without a valid use case for why Maven should consider pre-released versions as 
within the "not including 2.0" version range semantics.


-Original Message-
From: Manfred Moser [mailto:manf...@simpligility.com] 
Sent: Friday, September 23, 2016 11:32 AM
To: users@maven.apache.org
Subject: Re: [EXTERNAL] Re: help with version range

What you are misunderstanding is how snapshots are meant to be used. 
2.0-SNAPSHOT means that it is a development version working towards the release 
of 2.0 and as such the version 2.0-SNAPSHOT is smaller than 2.0.

If you mislike this you can change how you work with your own projects at 
least. .. you can just call your snapshot version 1.99-SNAPSHOT or whatever 
while developing and at releas time switch to 2.0 .. 

Manfred

Robert Patrick wrote on 2016-09-23 08:56:

> This does seem non-intuitive.If I say that I want versions  between 1.0 
> and
> up to but NOT including 2.0 by saying [1.0,2.0), in what use case 
> would I ever want this to resolve to 2.0-SNAPSHOT or any other pre-release 
> 2.0 artifact?
> Personally, I cannot think of a single one.
> 
> Typically, what I mean when I say [1.0,2.0) is any 1.x version but 
> nothing related to 2.0...
> 
> -Original Message-
> From: Justin Georgeson [mailto:jgeorge...@lgc.com]
> Sent: Friday, September 23, 2016 10:11 AM
> To: Maven Users List
> Subject: RE: [EXTERNAL] Re: help with version range
> 
> Yeah, I was hoping there was something more elegant like 1.1+ or 
> something, so I can at least move forward with that.
> 
> Logically, does it make sense to resolve 1.2.0-alpha-1 when the user 
> has excluded 1.2.0 from their range? If I explicitly don't want the 
> release version why would I want the pre-release versions?
> 
> -Original Message-
> From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On 
> Behalf Of Curtis Rueden
> Sent: Friday, September 23, 2016 9:01 AM
> To: Maven Users List
> Subject: [EXTERNAL] Re: help with version range
> 
> Hi Justin,
> 
> You could write "[1.1.0,1.1.9]", no? A bit hacky, but would match 
> the versions you want in practice.
> 
> Regards,
> Curtis
> 
> On Sep 23, 2016 8:38 AM, "Justin Georgeson"  wrote:
> 
>> I’m using the parent version range feature with “[1.1.0,1.2.0)” and 
>> it had been going well. However I wanted to start working on 1.2.0 of 
>> the parent, so I published a 1.2.0-alpha-1 version. And all the 
>> projects with te “[1.1.0,1.2.0)” picked it up. I recognize that this 
>> is in keeping with the implementation that x.y.z-(alpha|beta|…) 
>> precedes x.y.z, but it is unintuitive to me. First in that I’ve 
>> stated I don’t want 1.2.0, and second that once I do release 1.2.0 
>> the projects which were receiving the alpha builds will not get 
>> 1.2.0. I tried with both
>> 3.2.5 and 3.3.9. Can the version range syntax express the range I want?
>>
>>
>>
>> *Justin Georgeson*
>> Landmark Cloud Platforms & DevOps - RM
>>
>> Email: *jgeorge...@lgc.com* 
>>
>> Follow Halliburton: *LinkedIn*
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dho
>> s 
>> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
>> e 
>> s-255d-26url-3Dhttp-3A__www.linkedin.com_company_halliburton&d=DQIFaQ
>> & 
>> c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_O
>> V 
>> ZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s
>> = 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM&e= >
>> | *Facebook*
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dh
>> o 
>> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatu
>> r 
>> es-255d-26url-3Dhttps-3A__www.facebook.com_halliburton&d=DQIFaQ&c=Psk
>> v 
>> ixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uy
>> u 
>> i4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=NgT-w
>> O jrb7gpKDJVcRDMmKUQqGfR-PSnXe3I98Lp1c4&e= >
>> | *Twitter*
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dh
>> o 
>> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatu
>> r 
>> es-255d-26url-3Dhttps-3A__twitter.com_halliburton&d=DQIFaQ&c=PskvixtE
>> U 
>> DK7wuWU-tIg6oKuGYBRbr

Re: [EXTERNAL] Re: help with version range

[Manfred Moser]

What you are misunderstanding is how snapshots are meant to be used. 
2.0-SNAPSHOT means that it is a development version working towards the release 
of 2.0 and as such the version 2.0-SNAPSHOT is smaller than 2.0.

If you mislike this you can change how you work with your own projects at 
least. .. you can just call your snapshot version 1.99-SNAPSHOT or whatever 
while developing and at releas time switch to 2.0 .. 

Manfred

Robert Patrick wrote on 2016-09-23 08:56:

> This does seem non-intuitive.If I say that I want versions  between 1.0 
> and
> up to but NOT including 2.0 by saying [1.0,2.0), in what use case would I ever
> want this to resolve to 2.0-SNAPSHOT or any other pre-release 2.0 artifact? 
> Personally, I cannot think of a single one.
> 
> Typically, what I mean when I say [1.0,2.0) is any 1.x version but nothing
> related to 2.0...
> 
> -Original Message-
> From: Justin Georgeson [mailto:jgeorge...@lgc.com] 
> Sent: Friday, September 23, 2016 10:11 AM
> To: Maven Users List
> Subject: RE: [EXTERNAL] Re: help with version range
> 
> Yeah, I was hoping there was something more elegant like 1.1+ or something, so
> I can at least move forward with that.
> 
> Logically, does it make sense to resolve 1.2.0-alpha-1 when the user has
> excluded 1.2.0 from their range? If I explicitly don't want the release 
> version
> why would I want the pre-release versions?
> 
> -Original Message-
> From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On Behalf Of
> Curtis Rueden
> Sent: Friday, September 23, 2016 9:01 AM
> To: Maven Users List
> Subject: [EXTERNAL] Re: help with version range
> 
> Hi Justin,
> 
> You could write "[1.1.0,1.1.9]", no? A bit hacky, but would match the
> versions you want in practice.
> 
> Regards,
> Curtis
> 
> On Sep 23, 2016 8:38 AM, "Justin Georgeson"  wrote:
> 
>> I’m using the parent version range feature with “[1.1.0,1.2.0)” and it 
>> had been going well. However I wanted to start working on 1.2.0 of the 
>> parent, so I published a 1.2.0-alpha-1 version. And all the projects 
>> with te “[1.1.0,1.2.0)” picked it up. I recognize that this is in 
>> keeping with the implementation that x.y.z-(alpha|beta|…) precedes 
>> x.y.z, but it is unintuitive to me. First in that I’ve stated I don’t 
>> want 1.2.0, and second that once I do release 1.2.0 the projects which 
>> were receiving the alpha builds will not get 1.2.0. I tried with both
>> 3.2.5 and 3.3.9. Can the version range syntax express the range I want?
>>
>>
>>
>> *Justin Georgeson*
>> Landmark Cloud Platforms & DevOps - RM
>>
>> Email: *jgeorge...@lgc.com* 
>>
>> Follow Halliburton: *LinkedIn*
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
>> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
>> s-255d-26url-3Dhttp-3A__www.linkedin.com_company_halliburton&d=DQIFaQ&
>> c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OV
>> ZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=
>> 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM&e= >
>> | *Facebook*
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dho
>> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
>> es-255d-26url-3Dhttps-3A__www.facebook.com_halliburton&d=DQIFaQ&c=Pskv
>> ixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyu
>> i4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=NgT-wO
>> jrb7gpKDJVcRDMmKUQqGfR-PSnXe3I98Lp1c4&e= >
>> | *Twitter*
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dho
>> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
>> es-255d-26url-3Dhttps-3A__twitter.com_halliburton&d=DQIFaQ&c=PskvixtEU
>> DK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoE
>> mBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=-swEvm-8NW2
>> 18tPAkOpg46kdPblTNts2y7dbe_w82wM&e= >
>> | *YouTube*
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
>> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
>> s-255d-26url-3Dhttp-3A__youtube.com_halliburton&d=DQIFaQ&c=PskvixtEUDK
>> 7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmB
>> CjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=dTvvV1RKdjYSK
>> _Hc5JX55QI7b2j-A4O9RAX2Dg9qbrU&e= >
>> | *Blog*
>> <https://urldefense.proofpoint.com/v2/url?u=http

RE: [EXTERNAL] Re: help with version range

[Justin Georgeson]

Similarly I wouldn't want a range like "[1.2.0,1.3.0)" to give me a pre-release 
1.2.0 artifact. 

-Original Message-
From: Robert Patrick [mailto:robert.patr...@oracle.com] 
Sent: Friday, September 23, 2016 10:56 AM
To: Maven Users List
Subject: RE: [EXTERNAL] Re: help with version range

This does seem non-intuitive.If I say that I want versions  between 1.0 and 
up to but NOT including 2.0 by saying [1.0,2.0), in what use case would I ever 
want this to resolve to 2.0-SNAPSHOT or any other pre-release 2.0 artifact?  
Personally, I cannot think of a single one.

Typically, what I mean when I say [1.0,2.0) is any 1.x version but nothing 
related to 2.0...

-Original Message-
From: Justin Georgeson [mailto:jgeorge...@lgc.com]
Sent: Friday, September 23, 2016 10:11 AM
To: Maven Users List
Subject: RE: [EXTERNAL] Re: help with version range

Yeah, I was hoping there was something more elegant like 1.1+ or something, so 
I can at least move forward with that.

Logically, does it make sense to resolve 1.2.0-alpha-1 when the user has 
excluded 1.2.0 from their range? If I explicitly don't want the release version 
why would I want the pre-release versions?

-Original Message-
From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On Behalf Of 
Curtis Rueden
Sent: Friday, September 23, 2016 9:01 AM
To: Maven Users List
Subject: [EXTERNAL] Re: help with version range

Hi Justin,

You could write "[1.1.0,1.1.9]", no? A bit hacky, but would match the 
versions you want in practice.

Regards,
Curtis

On Sep 23, 2016 8:38 AM, "Justin Georgeson"  wrote:

> I’m using the parent version range feature with “[1.1.0,1.2.0)” and it 
> had been going well. However I wanted to start working on 1.2.0 of the 
> parent, so I published a 1.2.0-alpha-1 version. And all the projects 
> with te “[1.1.0,1.2.0)” picked it up. I recognize that this is in 
> keeping with the implementation that x.y.z-(alpha|beta|…) precedes 
> x.y.z, but it is unintuitive to me. First in that I’ve stated I don’t 
> want 1.2.0, and second that once I do release 1.2.0 the projects which 
> were receiving the alpha builds will not get 1.2.0. I tried with both
> 3.2.5 and 3.3.9. Can the version range syntax express the range I want?
>
>
>
> *Justin Georgeson*
> Landmark Cloud Platforms & DevOps - RM
>
> Email: *jgeorge...@lgc.com* 
>
> Follow Halliburton: *LinkedIn*
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
> s-255d-26url-3Dhttp-3A__www.linkedin.com_company_halliburton&d=DQIFaQ&
> c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OV
> ZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=
> 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM&e= >
> | *Facebook*
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dho
> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
> es-255d-26url-3Dhttps-3A__www.facebook.com_halliburton&d=DQIFaQ&c=Pskv
> ixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyu
> i4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=NgT-wO
> jrb7gpKDJVcRDMmKUQqGfR-PSnXe3I98Lp1c4&e= >
> | *Twitter*
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dho
> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
> es-255d-26url-3Dhttps-3A__twitter.com_halliburton&d=DQIFaQ&c=PskvixtEU
> DK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoE
> mBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=-swEvm-8NW2
> 18tPAkOpg46kdPblTNts2y7dbe_w82wM&e= >
> | *YouTube*
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
> s-255d-26url-3Dhttp-3A__youtube.com_halliburton&d=DQIFaQ&c=PskvixtEUDK
> 7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmB
> CjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=dTvvV1RKdjYSK
> _Hc5JX55QI7b2j-A4O9RAX2Dg9qbrU&e= >
> | *Blog*
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
> s-255d-26url-3Dhttp-3A__halliburtonblog.com&d=DQIFaQ&c=PskvixtEUDK7wuW
> U-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCm
> EiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=Or-LJ9tIt99DaFT0-
> BpnvVYmC73xtz0gLUBwIg5Woho&e= >
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.landmark.sol
> utions_&d=DQIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0U

RE: [EXTERNAL] Re: help with version range

[Robert Patrick]

This does seem non-intuitive.If I say that I want versions  between 1.0 and 
up to but NOT including 2.0 by saying [1.0,2.0), in what use case would I ever 
want this to resolve to 2.0-SNAPSHOT or any other pre-release 2.0 artifact?  
Personally, I cannot think of a single one.

Typically, what I mean when I say [1.0,2.0) is any 1.x version but nothing 
related to 2.0...

-Original Message-
From: Justin Georgeson [mailto:jgeorge...@lgc.com] 
Sent: Friday, September 23, 2016 10:11 AM
To: Maven Users List
Subject: RE: [EXTERNAL] Re: help with version range

Yeah, I was hoping there was something more elegant like 1.1+ or something, so 
I can at least move forward with that.

Logically, does it make sense to resolve 1.2.0-alpha-1 when the user has 
excluded 1.2.0 from their range? If I explicitly don't want the release version 
why would I want the pre-release versions?

-Original Message-
From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On Behalf Of 
Curtis Rueden
Sent: Friday, September 23, 2016 9:01 AM
To: Maven Users List
Subject: [EXTERNAL] Re: help with version range

Hi Justin,

You could write "[1.1.0,1.1.9]", no? A bit hacky, but would match the 
versions you want in practice.

Regards,
Curtis

On Sep 23, 2016 8:38 AM, "Justin Georgeson"  wrote:

> I’m using the parent version range feature with “[1.1.0,1.2.0)” and it 
> had been going well. However I wanted to start working on 1.2.0 of the 
> parent, so I published a 1.2.0-alpha-1 version. And all the projects 
> with te “[1.1.0,1.2.0)” picked it up. I recognize that this is in 
> keeping with the implementation that x.y.z-(alpha|beta|…) precedes 
> x.y.z, but it is unintuitive to me. First in that I’ve stated I don’t 
> want 1.2.0, and second that once I do release 1.2.0 the projects which 
> were receiving the alpha builds will not get 1.2.0. I tried with both
> 3.2.5 and 3.3.9. Can the version range syntax express the range I want?
>
>
>
> *Justin Georgeson*
> Landmark Cloud Platforms & DevOps - RM
>
> Email: *jgeorge...@lgc.com* 
>
> Follow Halliburton: *LinkedIn*
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
> s-255d-26url-3Dhttp-3A__www.linkedin.com_company_halliburton&d=DQIFaQ&
> c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OV
> ZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=
> 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM&e= >
> | *Facebook*
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dho
> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
> es-255d-26url-3Dhttps-3A__www.facebook.com_halliburton&d=DQIFaQ&c=Pskv
> ixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyu
> i4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=NgT-wO
> jrb7gpKDJVcRDMmKUQqGfR-PSnXe3I98Lp1c4&e= >
> | *Twitter*
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dho
> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
> es-255d-26url-3Dhttps-3A__twitter.com_halliburton&d=DQIFaQ&c=PskvixtEU
> DK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoE
> mBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=-swEvm-8NW2
> 18tPAkOpg46kdPblTNts2y7dbe_w82wM&e= >
> | *YouTube*
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
> s-255d-26url-3Dhttp-3A__youtube.com_halliburton&d=DQIFaQ&c=PskvixtEUDK
> 7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmB
> CjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=dTvvV1RKdjYSK
> _Hc5JX55QI7b2j-A4O9RAX2Dg9qbrU&e= >
> | *Blog*
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
> s-255d-26url-3Dhttp-3A__halliburtonblog.com&d=DQIFaQ&c=PskvixtEUDK7wuW
> U-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCm
> EiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=Or-LJ9tIt99DaFT0-
> BpnvVYmC73xtz0gLUBwIg5Woho&e= >
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.landmark.sol
> utions_&d=DQIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM
> 3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDD
> ZjCpFKXFWCrmu8&s=f4P54iKSAZYutrqVX1iHAWO9C7nP1vrd3OJGBT9g4LE&e= >
>
>
>
>
> --
> This e-mail, i

RE: [EXTERNAL] Re: help with version range

[Justin Georgeson]

Yeah, I was hoping there was something more elegant like 1.1+ or something, so 
I can at least move forward with that.

Logically, does it make sense to resolve 1.2.0-alpha-1 when the user has 
excluded 1.2.0 from their range? If I explicitly don't want the release version 
why would I want the pre-release versions?

-Original Message-
From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On Behalf Of 
Curtis Rueden
Sent: Friday, September 23, 2016 9:01 AM
To: Maven Users List
Subject: [EXTERNAL] Re: help with version range

Hi Justin,

You could write "[1.1.0,1.1.9]", no? A bit hacky, but would match the 
versions you want in practice.

Regards,
Curtis

On Sep 23, 2016 8:38 AM, "Justin Georgeson"  wrote:

> I’m using the parent version range feature with “[1.1.0,1.2.0)” and it 
> had been going well. However I wanted to start working on 1.2.0 of the 
> parent, so I published a 1.2.0-alpha-1 version. And all the projects 
> with te “[1.1.0,1.2.0)” picked it up. I recognize that this is in 
> keeping with the implementation that x.y.z-(alpha|beta|…) precedes 
> x.y.z, but it is unintuitive to me. First in that I’ve stated I don’t 
> want 1.2.0, and second that once I do release 1.2.0 the projects which 
> were receiving the alpha builds will not get 1.2.0. I tried with both 
> 3.2.5 and 3.3.9. Can the version range syntax express the range I want?
>
>
>
> *Justin Georgeson*
> Landmark Cloud Platforms & DevOps - RM
>
> Email: *jgeorge...@lgc.com* 
>
> Follow Halliburton: *LinkedIn*
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
> s-255d-26url-3Dhttp-3A__www.linkedin.com_company_halliburton&d=DQIFaQ&
> c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OV
> ZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=
> 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM&e= >
> | *Facebook*
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dho
> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
> es-255d-26url-3Dhttps-3A__www.facebook.com_halliburton&d=DQIFaQ&c=Pskv
> ixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyu
> i4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=NgT-wO
> jrb7gpKDJVcRDMmKUQqGfR-PSnXe3I98Lp1c4&e= >
> | *Twitter*
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logw332.ati-2Dho
> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
> es-255d-26url-3Dhttps-3A__twitter.com_halliburton&d=DQIFaQ&c=PskvixtEU
> DK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoE
> mBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=-swEvm-8NW2
> 18tPAkOpg46kdPblTNts2y7dbe_w82wM&e= >
> | *YouTube*
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
> s-255d-26url-3Dhttp-3A__youtube.com_halliburton&d=DQIFaQ&c=PskvixtEUDK
> 7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmB
> CjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=dTvvV1RKdjYSK
> _Hc5JX55QI7b2j-A4O9RAX2Dg9qbrU&e= >
> | *Blog*
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__logw332.ati-2Dhos
> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignature
> s-255d-26url-3Dhttp-3A__halliburtonblog.com&d=DQIFaQ&c=PskvixtEUDK7wuW
> U-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCm
> EiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8&s=Or-LJ9tIt99DaFT0-
> BpnvVYmC73xtz0gLUBwIg5Woho&e= >
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.landmark.sol
> utions_&d=DQIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM
> 3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=y4-iycjs7jCDUAa82A-SQP4DqefDD
> ZjCpFKXFWCrmu8&s=f4P54iKSAZYutrqVX1iHAWO9C7nP1vrd3OJGBT9g4LE&e= >
>
>
>
>
> --
> This e-mail, including any attached files, may contain confidential 
> and privileged information for the sole use of the intended recipient. 
> Any review, use, distribution, or disclosure by others is strictly prohibited.
> If you are not the intended recipient (or authorized to receive 
> information for the intended recipient), please contact the sender by 
> reply e-mail and delete all copies of this message.
>

Re: help with version range

[Curtis Rueden]

Hi Justin,

You could write "[1.1.0,1.1.9]", no? A bit hacky, but would match the
versions you want in practice.

Regards,
Curtis

On Sep 23, 2016 8:38 AM, "Justin Georgeson"  wrote:

> I’m using the parent version range feature with “[1.1.0,1.2.0)” and it had
> been going well. However I wanted to start working on 1.2.0 of the parent,
> so I published a 1.2.0-alpha-1 version. And all the projects with te
> “[1.1.0,1.2.0)” picked it up. I recognize that this is in keeping with the
> implementation that x.y.z-(alpha|beta|…) precedes x.y.z, but it is
> unintuitive to me. First in that I’ve stated I don’t want 1.2.0, and second
> that once I do release 1.2.0 the projects which were receiving the alpha
> builds will not get 1.2.0. I tried with both 3.2.5 and 3.3.9. Can the
> version range syntax express the range I want?
>
>
>
> *Justin Georgeson*
> Landmark Cloud Platforms & DevOps - RM
>
> Email: *jgeorge...@lgc.com* 
>
> Follow Halliburton: *LinkedIn*
> 
> | *Facebook*
> 
> | *Twitter*
> 
> | *YouTube*
> 
> | *Blog*
> 
>
>
> 
>
>
>
>
> --
> This e-mail, including any attached files, may contain confidential and
> privileged information for the sole use of the intended recipient. Any
> review, use, distribution, or disclosure by others is strictly prohibited.
> If you are not the intended recipient (or authorized to receive information
> for the intended recipient), please contact the sender by reply e-mail and
> delete all copies of this message.
>

help with version range

[Justin Georgeson]

I'm using the parent version range feature with "[1.1.0,1.2.0)" and it had been 
going well. However I wanted to start working on 1.2.0 of the parent, so I 
published a 1.2.0-alpha-1 version. And all the projects with te "[1.1.0,1.2.0)" 
picked it up. I recognize that this is in keeping with the implementation that 
x.y.z-(alpha|beta|...) precedes x.y.z, but it is unintuitive to me. First in 
that I've stated I don't want 1.2.0, and second that once I do release 1.2.0 
the projects which were receiving the alpha builds will not get 1.2.0. I tried 
with both 3.2.5 and 3.3.9. Can the version range syntax express the range I 
want?



Justin Georgeson
Landmark Cloud Platforms & DevOps - RM

Email: jgeorge...@lgc.com


Follow Halliburton: 
LinkedIn
 | 
Facebook
 | 
Twitter
 | 
YouTube
 | 
Blog



 
[http://www.halliburton.com/public/pubsdata/social_media/images/hal_lmk-200x15.jpg]
 




--
This e-mail, including any attached files, may contain confidential and 
privileged information for the sole use of the intended recipient.  Any review, 
use, distribution, or disclosure by others is strictly prohibited.  If you are 
not the intended recipient (or authorized to receive information for the 
intended recipient), please contact the sender by reply e-mail and delete all 
copies of this message.