Re: Failures building Eclipse 4.13 with maven-3.6.2

[Jeff MAURY]

This is a know case between tycho pomless and maven 3.6.2

Le sam. 14 sept. 2019 à 05:26, Jonathan Chen  a écrit :

> Hi,
>
> I'm currently attempting to build Eclipse 4.13 from source using
> maven-3.6.2, and I'm seeing these current failures:
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] Non-readable POM
>
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.cdcfoundation10/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
>
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.cdcfoundation11/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
>
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.feature/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
>
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se12/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
>
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se13/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
>
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se14/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
>
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se15/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
>
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.javase16/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
>
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.javase17/.polyglot.build.properties:
> input contained no data @
> ...
>
> It appears that the pom-less builds are failing due to a missing
> .polyglot.build.properties. These are transient files that are removed
> once the compiling JVM exits. Something in the 3.6.2 lifecycle has
> changed such that the files are not staying long enough to be
> available for dependency-resolution.
>
> If I downgrade to maven-3.6.1 or maven-3.6.0, these errors do not arise.
>
> Cheers.
> --
> Jonathan Chen 
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Same snapshot deploy number for entire build - possible

[Dan Tran]

Hi Jason,

There is no problem having maven to maven snapshot dependencies between
teams.

The problem arises when you have 3 to 4 installer type artifacts landing on
QA  teams who have to install/deploy and coordinate

 Having the same snapshot number at the end of each installer artifact
helps.  Knowing all coming from same build

Still waiting for the maven dev team to chime in if there is possible
solution :-)

Thanks for all feedbacks

-D




On Fri, Sep 13, 2019 at 5:33 PM Jason Young 
wrote:

> Dan,
>
> Why are people asking about anything after `SNAPSHOT` in the version
> number, i.e. why do they care? Are discrepancies causing build failures
> somehow?
>
> My team's projects depend on each other with `SNAPSHOT` versions but
> without specifying a build number or timestamp, e.g.
> `1.2.3-SNAPSHOT`. This, combined with a policy to always
> get the latest SNAPSHOT (just like the `-U` argument only applied
> implicitly), makes every build use the latest SNAPSHOT of any dependencies
> it does not build from source. Nobody ever asks me about timestamps or
> build numbers that e.g. Nexus keeps up with.
>
> Regarding the policy or the -U argument, IMO these are necessary for
> correct builds because the default policy, last I checked, is to download
> the latest SNAPSHOT only if Maven hasn't checked in the last 24 hours,
> which I find bewildering.
>
> Again, you can define the version _once for all projects_ in a parent
> pom.xml. Let us know if that makes sense or if it is not an option for some
> reason.
>
> HTH. Sorry if I still don't understand the problem.
>
> On Fri, Sep 13, 2019 at 6:22 PM Dan Tran  wrote:
>
> > @ Tamás Cservenák you read my mind thanks
> >
> > The problem I am facing is, out of a few hundred artifacts deployed every
> > build.
> > There is a handful of artifacts that landed on QA side. By having the
> same
> > 'buildNo/snapshotNo'
> >  ( ie artifactId-version-timestamp-buildNo.xx)  it is much easier to
> > communicate,
> > otherwise, it is a constant problem explaining why they are not the same
> >
> > This is an ongoing problem at my workplace.
> >
> > deployAtEnd never work for us
> > https://issues.apache.org/jira/projects/MDEPLOY especially this one
> > https://issues.apache.org/jira/projects/MDEPLOY/issues/MDEPLOY-226
> >
> > We can switch to release build but that is not an option since we would
> run
> > out  of storage quickly and have to purge ourselves
> >
> > The question here what is the best way to implement an option asking
> > maven-deploy-plugin to use the same provided 'buildNo' ? possible?
> >
> > Thanks
> >
> > -D
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Fri, Sep 13, 2019 at 1:53 PM Francois Marot  >
> > wrote:
> >
> > > OK, I get the "problem" but in fact I do not think this is a problem.
> > > How those files (with the number suffix) are named, whether you deploy
> > (to
> > > a remote repo) or install (to a local folder), is just an
> implementation
> > > detail. You should never end up accessing those files by their name.
> > > Let me explain: if you want to get all the 3 latest artifacts, whatever
> > the
> > > file name and the timestamp version, you can just create a pom having
> > those
> > > 3 artifacts declared as dependencies and use maven dependency plugin (
> > >
> >
> https://maven.apache.org/plugins/maven-dependency-plugin/plugin-info.html
> > > )
> > > to copy those artifacts in a directory. Use the "-U" flag to make sure
> to
> > > get the latest version. This way, maven will care about the file names,
> > but
> > > you will not.
> > >
> > > I hope I can help
> > >
> > >
> > >
> > >
> > >
> > > On Fri, 13 Sep 2019 at 22:42, Tamás Cservenák 
> > wrote:
> > >
> > > > Howdy,
> > > >
> > > > so what Dan is asking for is I think the following thing:
> > > > On multi module snapshot deploy, the last bit of snapshot timestamped
> > > > version is "buildNo".
> > > >
> > > > Consider following scenario: you have a 3 module reactor build:
> > > > i) you deploy first time: the buildNo is -1
> > > > ii) you deploy second time, and 2nd module UT fails: result in repo
> is
> > > 1st
> > > > module has -2, while the rest, as module2 failed, is not deployed
> > > > iii) you deploy third time: the build No is -3 for 1st module, while
> it
> > > is
> > > > -2 for the rest.
> > > >
> > > > All sounds great ("as it should be"), but buildNo has "fall apart".
> 3rd
> > > > deployment will have snapshots that will have their version like
> > > > 1.0-mmdd.hhmmss-3 while the rest version is
> 1.0-mmdd.hhmmss-2.
> > > >
> > > > Determining buildNo is possible only from maven metadata.xml, that
> may
> > be
> > > > overkill. Nothing logically "groups" the two version above, even if
> > they
> > > > were deployed at same time, by the same build.
> > > >
> > > > Deploy at end may help here, yes, but personally, I dislike the fact
> > how
> > > > buildNo is calculated (md get, buildNo++ jar put,, modified md put).
> > > >
> > > > Also, this topic seems to me, 

Failures building Eclipse 4.13 with maven-3.6.2

[Jonathan Chen]

Hi,

I'm currently attempting to build Eclipse 4.13 from source using
maven-3.6.2, and I'm seeing these current failures:
[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[FATAL] Non-readable POM
/home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.cdcfoundation10/.polyglot.build.properties:
input contained no data @
[FATAL] Non-readable POM
/home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.cdcfoundation11/.polyglot.build.properties:
input contained no data @
[FATAL] Non-readable POM
/home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.feature/.polyglot.build.properties:
input contained no data @
[FATAL] Non-readable POM
/home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se12/.polyglot.build.properties:
input contained no data @
[FATAL] Non-readable POM
/home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se13/.polyglot.build.properties:
input contained no data @
[FATAL] Non-readable POM
/home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se14/.polyglot.build.properties:
input contained no data @
[FATAL] Non-readable POM
/home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se15/.polyglot.build.properties:
input contained no data @
[FATAL] Non-readable POM
/home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.javase16/.polyglot.build.properties:
input contained no data @
[FATAL] Non-readable POM
/home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.javase17/.polyglot.build.properties:
input contained no data @
...

It appears that the pom-less builds are failing due to a missing
.polyglot.build.properties. These are transient files that are removed
once the compiling JVM exits. Something in the 3.6.2 lifecycle has
changed such that the files are not staying long enough to be
available for dependency-resolution.

If I downgrade to maven-3.6.1 or maven-3.6.0, these errors do not arise.

Cheers.
-- 
Jonathan Chen 

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

Re: Same snapshot deploy number for entire build - possible

[Jason Young]

Dan,

Why are people asking about anything after `SNAPSHOT` in the version
number, i.e. why do they care? Are discrepancies causing build failures
somehow?

My team's projects depend on each other with `SNAPSHOT` versions but
without specifying a build number or timestamp, e.g.
`1.2.3-SNAPSHOT`. This, combined with a policy to always
get the latest SNAPSHOT (just like the `-U` argument only applied
implicitly), makes every build use the latest SNAPSHOT of any dependencies
it does not build from source. Nobody ever asks me about timestamps or
build numbers that e.g. Nexus keeps up with.

Regarding the policy or the -U argument, IMO these are necessary for
correct builds because the default policy, last I checked, is to download
the latest SNAPSHOT only if Maven hasn't checked in the last 24 hours,
which I find bewildering.

Again, you can define the version _once for all projects_ in a parent
pom.xml. Let us know if that makes sense or if it is not an option for some
reason.

HTH. Sorry if I still don't understand the problem.

On Fri, Sep 13, 2019 at 6:22 PM Dan Tran  wrote:

> @ Tamás Cservenák you read my mind thanks
>
> The problem I am facing is, out of a few hundred artifacts deployed every
> build.
> There is a handful of artifacts that landed on QA side. By having the same
> 'buildNo/snapshotNo'
>  ( ie artifactId-version-timestamp-buildNo.xx)  it is much easier to
> communicate,
> otherwise, it is a constant problem explaining why they are not the same
>
> This is an ongoing problem at my workplace.
>
> deployAtEnd never work for us
> https://issues.apache.org/jira/projects/MDEPLOY especially this one
> https://issues.apache.org/jira/projects/MDEPLOY/issues/MDEPLOY-226
>
> We can switch to release build but that is not an option since we would run
> out  of storage quickly and have to purge ourselves
>
> The question here what is the best way to implement an option asking
> maven-deploy-plugin to use the same provided 'buildNo' ? possible?
>
> Thanks
>
> -D
>
>
>
>
>
>
>
>
>
> On Fri, Sep 13, 2019 at 1:53 PM Francois Marot 
> wrote:
>
> > OK, I get the "problem" but in fact I do not think this is a problem.
> > How those files (with the number suffix) are named, whether you deploy
> (to
> > a remote repo) or install (to a local folder), is just an implementation
> > detail. You should never end up accessing those files by their name.
> > Let me explain: if you want to get all the 3 latest artifacts, whatever
> the
> > file name and the timestamp version, you can just create a pom having
> those
> > 3 artifacts declared as dependencies and use maven dependency plugin (
> >
> https://maven.apache.org/plugins/maven-dependency-plugin/plugin-info.html
> > )
> > to copy those artifacts in a directory. Use the "-U" flag to make sure to
> > get the latest version. This way, maven will care about the file names,
> but
> > you will not.
> >
> > I hope I can help
> >
> >
> >
> >
> >
> > On Fri, 13 Sep 2019 at 22:42, Tamás Cservenák 
> wrote:
> >
> > > Howdy,
> > >
> > > so what Dan is asking for is I think the following thing:
> > > On multi module snapshot deploy, the last bit of snapshot timestamped
> > > version is "buildNo".
> > >
> > > Consider following scenario: you have a 3 module reactor build:
> > > i) you deploy first time: the buildNo is -1
> > > ii) you deploy second time, and 2nd module UT fails: result in repo is
> > 1st
> > > module has -2, while the rest, as module2 failed, is not deployed
> > > iii) you deploy third time: the build No is -3 for 1st module, while it
> > is
> > > -2 for the rest.
> > >
> > > All sounds great ("as it should be"), but buildNo has "fall apart". 3rd
> > > deployment will have snapshots that will have their version like
> > > 1.0-mmdd.hhmmss-3 while the rest version is 1.0-mmdd.hhmmss-2.
> > >
> > > Determining buildNo is possible only from maven metadata.xml, that may
> be
> > > overkill. Nothing logically "groups" the two version above, even if
> they
> > > were deployed at same time, by the same build.
> > >
> > > Deploy at end may help here, yes, but personally, I dislike the fact
> how
> > > buildNo is calculated (md get, buildNo++ jar put,, modified md put).
> > >
> > > Also, this topic seems to me, like somewhat related to the overall
> issue
> > of
> > > https://issues.apache.org/jira/browse/MNG-6581
> > >
> > > Thanks,
> > > T
> > >
> > >
> > >
> > > On Fri, Sep 13, 2019 at 8:32 PM Francois Marot <
> francois.ma...@gmail.com
> > >
> > > wrote:
> > >
> > > >  can you tell us a little bit more about your problem please ?
> > > > You say "Currently, artifact deployed as snapshot at Maven repository
> > has
> > > > the following format: artifactId-version-timestamp-NN ". Do youmean
> the
> > > > filename in the repo ? If so, why is it a problem for you ?
> > > > Share more with us and I think we'll suggest solution more adapted
> for
> > > your
> > > > use case  ;)
> > > >
> > > > Regards,
> > > > Francois
> > > >
> > > >
> > > >
> > > > On Thu, 12 

Re: Same snapshot deploy number for entire build - possible

[Dan Tran]

@ Tamás Cservenák you read my mind thanks

The problem I am facing is, out of a few hundred artifacts deployed every
build.
There is a handful of artifacts that landed on QA side. By having the same
'buildNo/snapshotNo'
 ( ie artifactId-version-timestamp-buildNo.xx)  it is much easier to
communicate,
otherwise, it is a constant problem explaining why they are not the same

This is an ongoing problem at my workplace.

deployAtEnd never work for us
https://issues.apache.org/jira/projects/MDEPLOY especially this one
https://issues.apache.org/jira/projects/MDEPLOY/issues/MDEPLOY-226

We can switch to release build but that is not an option since we would run
out  of storage quickly and have to purge ourselves

The question here what is the best way to implement an option asking
maven-deploy-plugin to use the same provided 'buildNo' ? possible?

Thanks

-D









On Fri, Sep 13, 2019 at 1:53 PM Francois Marot 
wrote:

> OK, I get the "problem" but in fact I do not think this is a problem.
> How those files (with the number suffix) are named, whether you deploy (to
> a remote repo) or install (to a local folder), is just an implementation
> detail. You should never end up accessing those files by their name.
> Let me explain: if you want to get all the 3 latest artifacts, whatever the
> file name and the timestamp version, you can just create a pom having those
> 3 artifacts declared as dependencies and use maven dependency plugin (
> https://maven.apache.org/plugins/maven-dependency-plugin/plugin-info.html
> )
> to copy those artifacts in a directory. Use the "-U" flag to make sure to
> get the latest version. This way, maven will care about the file names, but
> you will not.
>
> I hope I can help
>
>
>
>
>
> On Fri, 13 Sep 2019 at 22:42, Tamás Cservenák  wrote:
>
> > Howdy,
> >
> > so what Dan is asking for is I think the following thing:
> > On multi module snapshot deploy, the last bit of snapshot timestamped
> > version is "buildNo".
> >
> > Consider following scenario: you have a 3 module reactor build:
> > i) you deploy first time: the buildNo is -1
> > ii) you deploy second time, and 2nd module UT fails: result in repo is
> 1st
> > module has -2, while the rest, as module2 failed, is not deployed
> > iii) you deploy third time: the build No is -3 for 1st module, while it
> is
> > -2 for the rest.
> >
> > All sounds great ("as it should be"), but buildNo has "fall apart". 3rd
> > deployment will have snapshots that will have their version like
> > 1.0-mmdd.hhmmss-3 while the rest version is 1.0-mmdd.hhmmss-2.
> >
> > Determining buildNo is possible only from maven metadata.xml, that may be
> > overkill. Nothing logically "groups" the two version above, even if they
> > were deployed at same time, by the same build.
> >
> > Deploy at end may help here, yes, but personally, I dislike the fact how
> > buildNo is calculated (md get, buildNo++ jar put,, modified md put).
> >
> > Also, this topic seems to me, like somewhat related to the overall issue
> of
> > https://issues.apache.org/jira/browse/MNG-6581
> >
> > Thanks,
> > T
> >
> >
> >
> > On Fri, Sep 13, 2019 at 8:32 PM Francois Marot  >
> > wrote:
> >
> > >  can you tell us a little bit more about your problem please ?
> > > You say "Currently, artifact deployed as snapshot at Maven repository
> has
> > > the following format: artifactId-version-timestamp-NN ". Do youmean the
> > > filename in the repo ? If so, why is it a problem for you ?
> > > Share more with us and I think we'll suggest solution more adapted for
> > your
> > > use case  ;)
> > >
> > > Regards,
> > > Francois
> > >
> > >
> > >
> > > On Thu, 12 Sep 2019 at 04:07, Dan Tran  wrote:
> > >
> > > > Hello Maven Users and Development Team
> > > >
> > > > Currently, artifact deployed as snapshot at Maven repository has the
> > > > following format
> > > >
> > > >  artifactId-version-timestamp-NN
> > > >
> > > > where NN auto-incremented at each maven module and the number varies
> > > >
> > > > Is there a way to use same snapshot NN for the entire multi-module
> > maven
> > > > build?
> > > >
> > > > If I have to implement a solution, would it be as an extension or I
> > have
> > > to
> > > > tinker with maven-deploy-plugin?
> > > >
> > > > Very appreciated any advice
> > > >
> > > > -D
> > > >
> > >
> >
>

Re: Same snapshot deploy number for entire build - possible

[Francois Marot]

OK, I get the "problem" but in fact I do not think this is a problem.
How those files (with the number suffix) are named, whether you deploy (to
a remote repo) or install (to a local folder), is just an implementation
detail. You should never end up accessing those files by their name.
Let me explain: if you want to get all the 3 latest artifacts, whatever the
file name and the timestamp version, you can just create a pom having those
3 artifacts declared as dependencies and use maven dependency plugin (
https://maven.apache.org/plugins/maven-dependency-plugin/plugin-info.html )
to copy those artifacts in a directory. Use the "-U" flag to make sure to
get the latest version. This way, maven will care about the file names, but
you will not.

I hope I can help





On Fri, 13 Sep 2019 at 22:42, Tamás Cservenák  wrote:

> Howdy,
>
> so what Dan is asking for is I think the following thing:
> On multi module snapshot deploy, the last bit of snapshot timestamped
> version is "buildNo".
>
> Consider following scenario: you have a 3 module reactor build:
> i) you deploy first time: the buildNo is -1
> ii) you deploy second time, and 2nd module UT fails: result in repo is 1st
> module has -2, while the rest, as module2 failed, is not deployed
> iii) you deploy third time: the build No is -3 for 1st module, while it is
> -2 for the rest.
>
> All sounds great ("as it should be"), but buildNo has "fall apart". 3rd
> deployment will have snapshots that will have their version like
> 1.0-mmdd.hhmmss-3 while the rest version is 1.0-mmdd.hhmmss-2.
>
> Determining buildNo is possible only from maven metadata.xml, that may be
> overkill. Nothing logically "groups" the two version above, even if they
> were deployed at same time, by the same build.
>
> Deploy at end may help here, yes, but personally, I dislike the fact how
> buildNo is calculated (md get, buildNo++ jar put,, modified md put).
>
> Also, this topic seems to me, like somewhat related to the overall issue of
> https://issues.apache.org/jira/browse/MNG-6581
>
> Thanks,
> T
>
>
>
> On Fri, Sep 13, 2019 at 8:32 PM Francois Marot 
> wrote:
>
> >  can you tell us a little bit more about your problem please ?
> > You say "Currently, artifact deployed as snapshot at Maven repository has
> > the following format: artifactId-version-timestamp-NN ". Do youmean the
> > filename in the repo ? If so, why is it a problem for you ?
> > Share more with us and I think we'll suggest solution more adapted for
> your
> > use case  ;)
> >
> > Regards,
> > Francois
> >
> >
> >
> > On Thu, 12 Sep 2019 at 04:07, Dan Tran  wrote:
> >
> > > Hello Maven Users and Development Team
> > >
> > > Currently, artifact deployed as snapshot at Maven repository has the
> > > following format
> > >
> > >  artifactId-version-timestamp-NN
> > >
> > > where NN auto-incremented at each maven module and the number varies
> > >
> > > Is there a way to use same snapshot NN for the entire multi-module
> maven
> > > build?
> > >
> > > If I have to implement a solution, would it be as an extension or I
> have
> > to
> > > tinker with maven-deploy-plugin?
> > >
> > > Very appreciated any advice
> > >
> > > -D
> > >
> >
>

Re: Same snapshot deploy number for entire build - possible

[Tibor Digana]

I think the timestamp after "-SNAPSHOT" is something which should not be
customized as by Maven design.
The version before "-SNAPSHOT"is something which is up to you.
Some companies customize the version to *--* executed on Jenkins CI.
If it is a problem in multimodule project with messy timestamp then it is
strange bug. You can configure installAtEnd=true
https://maven.apache.org/plugins/maven-install-plugin/install-mojo.html#installAtEnd
but it is only a workaround.

On Fri, Sep 13, 2019 at 10:42 PM Tamás Cservenák 
wrote:

> Howdy,
>
> so what Dan is asking for is I think the following thing:
> On multi module snapshot deploy, the last bit of snapshot timestamped
> version is "buildNo".
>
> Consider following scenario: you have a 3 module reactor build:
> i) you deploy first time: the buildNo is -1
> ii) you deploy second time, and 2nd module UT fails: result in repo is 1st
> module has -2, while the rest, as module2 failed, is not deployed
> iii) you deploy third time: the build No is -3 for 1st module, while it is
> -2 for the rest.
>
> All sounds great ("as it should be"), but buildNo has "fall apart". 3rd
> deployment will have snapshots that will have their version like
> 1.0-mmdd.hhmmss-3 while the rest version is 1.0-mmdd.hhmmss-2.
>
> Determining buildNo is possible only from maven metadata.xml, that may be
> overkill. Nothing logically "groups" the two version above, even if they
> were deployed at same time, by the same build.
>
> Deploy at end may help here, yes, but personally, I dislike the fact how
> buildNo is calculated (md get, buildNo++ jar put,, modified md put).
>
> Also, this topic seems to me, like somewhat related to the overall issue of
> https://issues.apache.org/jira/browse/MNG-6581
>
> Thanks,
> T
>
>
>
> On Fri, Sep 13, 2019 at 8:32 PM Francois Marot 
> wrote:
>
> >  can you tell us a little bit more about your problem please ?
> > You say "Currently, artifact deployed as snapshot at Maven repository has
> > the following format: artifactId-version-timestamp-NN ". Do youmean the
> > filename in the repo ? If so, why is it a problem for you ?
> > Share more with us and I think we'll suggest solution more adapted for
> your
> > use case  ;)
> >
> > Regards,
> > Francois
> >
> >
> >
> > On Thu, 12 Sep 2019 at 04:07, Dan Tran  wrote:
> >
> > > Hello Maven Users and Development Team
> > >
> > > Currently, artifact deployed as snapshot at Maven repository has the
> > > following format
> > >
> > >  artifactId-version-timestamp-NN
> > >
> > > where NN auto-incremented at each maven module and the number varies
> > >
> > > Is there a way to use same snapshot NN for the entire multi-module
> maven
> > > build?
> > >
> > > If I have to implement a solution, would it be as an extension or I
> have
> > to
> > > tinker with maven-deploy-plugin?
> > >
> > > Very appreciated any advice
> > >
> > > -D
> > >
> >
>

Re: Same snapshot deploy number for entire build - possible

[Tamás Cservenák]

Howdy,

so what Dan is asking for is I think the following thing:
On multi module snapshot deploy, the last bit of snapshot timestamped
version is "buildNo".

Consider following scenario: you have a 3 module reactor build:
i) you deploy first time: the buildNo is -1
ii) you deploy second time, and 2nd module UT fails: result in repo is 1st
module has -2, while the rest, as module2 failed, is not deployed
iii) you deploy third time: the build No is -3 for 1st module, while it is
-2 for the rest.

All sounds great ("as it should be"), but buildNo has "fall apart". 3rd
deployment will have snapshots that will have their version like
1.0-mmdd.hhmmss-3 while the rest version is 1.0-mmdd.hhmmss-2.

Determining buildNo is possible only from maven metadata.xml, that may be
overkill. Nothing logically "groups" the two version above, even if they
were deployed at same time, by the same build.

Deploy at end may help here, yes, but personally, I dislike the fact how
buildNo is calculated (md get, buildNo++ jar put,, modified md put).

Also, this topic seems to me, like somewhat related to the overall issue of
https://issues.apache.org/jira/browse/MNG-6581

Thanks,
T



On Fri, Sep 13, 2019 at 8:32 PM Francois Marot 
wrote:

>  can you tell us a little bit more about your problem please ?
> You say "Currently, artifact deployed as snapshot at Maven repository has
> the following format: artifactId-version-timestamp-NN ". Do youmean the
> filename in the repo ? If so, why is it a problem for you ?
> Share more with us and I think we'll suggest solution more adapted for your
> use case  ;)
>
> Regards,
> Francois
>
>
>
> On Thu, 12 Sep 2019 at 04:07, Dan Tran  wrote:
>
> > Hello Maven Users and Development Team
> >
> > Currently, artifact deployed as snapshot at Maven repository has the
> > following format
> >
> >  artifactId-version-timestamp-NN
> >
> > where NN auto-incremented at each maven module and the number varies
> >
> > Is there a way to use same snapshot NN for the entire multi-module maven
> > build?
> >
> > If I have to implement a solution, would it be as an extension or I have
> to
> > tinker with maven-deploy-plugin?
> >
> > Very appreciated any advice
> >
> > -D
> >
>

Re: Same snapshot deploy number for entire build - possible

[Francois Marot]

 can you tell us a little bit more about your problem please ?
You say "Currently, artifact deployed as snapshot at Maven repository has
the following format: artifactId-version-timestamp-NN ". Do youmean the
filename in the repo ? If so, why is it a problem for you ?
Share more with us and I think we'll suggest solution more adapted for your
use case  ;)

Regards,
Francois



On Thu, 12 Sep 2019 at 04:07, Dan Tran  wrote:

> Hello Maven Users and Development Team
>
> Currently, artifact deployed as snapshot at Maven repository has the
> following format
>
>  artifactId-version-timestamp-NN
>
> where NN auto-incremented at each maven module and the number varies
>
> Is there a way to use same snapshot NN for the entire multi-module maven
> build?
>
> If I have to implement a solution, would it be as an extension or I have to
> tinker with maven-deploy-plugin?
>
> Very appreciated any advice
>
> -D
>

Re: Same snapshot deploy number for entire build - possible

[Jason Young]

You never established that you're talking about the projects' versions, as
in the part between the  tags. Is that what you're talking about?
If so, did you say the artifactId is part of the version? Can you take
artifactId out of the version and make all projects in your reactor have
the same version, not just the same incremented part?

You can ensure that the whole version is the same throughout the reactor
most easily by:
1. making a parent pom for all projects to inherit from to define things
common to all projects, including the version.
2. inheriting from that pom from all modules.
3. Don't define  in any modules inheriting from that parent.
4. Adjust your version-incrementing script or Maven plugin accordingly.

NOTE that IME not all plugins, including official ones, understand the
difference between a parent pom and a multi-module pom, so to ensure
compatibility, please _make the multi-module pom also the parent of its
modules_.

HTH.

On Fri, Sep 13, 2019 at 5:50 AM Thomas Broyer  wrote:

> Maybe you'd want to deployAtEnd?
>
> https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html#deployAtEnd
>
> On Fri, Sep 13, 2019 at 12:03 PM Dan Tran  wrote:
>
> > Looks like I need to clear thing a little bit
> >
> > Assume I have a reactor of few hundreds of maven modules and my CI
> > build deploys snapshots, first few good builds, each module deployed to
> > maven repository have same snapshot number
> >
> > Once we encounter a build failure at a module,  the snapshot number
> begins
> > to vary and over time, all modules no longer have the same snapshot
> number
> > anymore
> >
> > To be able to determine a consistent snapshot number at each build,  I
> > would like to have an ability the tell deploy maven plugin to use an
> > assigned number for all modules.
> >
> > Possible?
> >
> > Thanks
> >
> > -D
> >
> >
> >
> >
> >
> >
> > On Thu, Sep 12, 2019 at 11:31 PM Enrico Olivelli 
> > wrote:
> >
> > > Dan,
> > > Are you running a single 'mvn deploy' or do you have multiple runs?
> > > I have never seen weird behaviours in multi module projects
> > >
> > > Cheers
> > > Enrico
> > >
> > > Il ven 13 set 2019, 08:19 Dan Tran  ha scritto:
> > >
> > > > Hello, Maven dev
> > > >
> > > > any suggestion/thoughts on this issue are very much appreciated
> > > >
> > > > Regards
> > > >
> > > > -D
> > > >
> > > > On Wed, Sep 11, 2019 at 7:06 PM Dan Tran  wrote:
> > > >
> > > > > Hello Maven Users and Development Team
> > > > >
> > > > > Currently, artifact deployed as snapshot at Maven repository has
> the
> > > > > following format
> > > > >
> > > > >  artifactId-version-timestamp-NN
> > > > >
> > > > > where NN auto-incremented at each maven module and the number
> varies
> > > > >
> > > > > Is there a way to use same snapshot NN for the entire multi-module
> > > maven
> > > > > build?
> > > > >
> > > > > If I have to implement a solution, would it be as an extension or I
> > > have
> > > > > to tinker with maven-deploy-plugin?
> > > > >
> > > > > Very appreciated any advice
> > > > >
> > > > > -D
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
>
> --
> Thomas Broyer
> /tɔ.ma.bʁwa.je/  <
> http://xn--nna.ma.xn--bwa-xxb.je/>
>


--

Re: Same snapshot deploy number for entire build - possible

[Thomas Broyer]

Maybe you'd want to deployAtEnd?
https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html#deployAtEnd

On Fri, Sep 13, 2019 at 12:03 PM Dan Tran  wrote:

> Looks like I need to clear thing a little bit
>
> Assume I have a reactor of few hundreds of maven modules and my CI
> build deploys snapshots, first few good builds, each module deployed to
> maven repository have same snapshot number
>
> Once we encounter a build failure at a module,  the snapshot number begins
> to vary and over time, all modules no longer have the same snapshot number
> anymore
>
> To be able to determine a consistent snapshot number at each build,  I
> would like to have an ability the tell deploy maven plugin to use an
> assigned number for all modules.
>
> Possible?
>
> Thanks
>
> -D
>
>
>
>
>
>
> On Thu, Sep 12, 2019 at 11:31 PM Enrico Olivelli 
> wrote:
>
> > Dan,
> > Are you running a single 'mvn deploy' or do you have multiple runs?
> > I have never seen weird behaviours in multi module projects
> >
> > Cheers
> > Enrico
> >
> > Il ven 13 set 2019, 08:19 Dan Tran  ha scritto:
> >
> > > Hello, Maven dev
> > >
> > > any suggestion/thoughts on this issue are very much appreciated
> > >
> > > Regards
> > >
> > > -D
> > >
> > > On Wed, Sep 11, 2019 at 7:06 PM Dan Tran  wrote:
> > >
> > > > Hello Maven Users and Development Team
> > > >
> > > > Currently, artifact deployed as snapshot at Maven repository has the
> > > > following format
> > > >
> > > >  artifactId-version-timestamp-NN
> > > >
> > > > where NN auto-incremented at each maven module and the number varies
> > > >
> > > > Is there a way to use same snapshot NN for the entire multi-module
> > maven
> > > > build?
> > > >
> > > > If I have to implement a solution, would it be as an extension or I
> > have
> > > > to tinker with maven-deploy-plugin?
> > > >
> > > > Very appreciated any advice
> > > >
> > > > -D
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
>


-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ 

Re: Same snapshot deploy number for entire build - possible

[Dan Tran]

Looks like I need to clear thing a little bit

Assume I have a reactor of few hundreds of maven modules and my CI
build deploys snapshots, first few good builds, each module deployed to
maven repository have same snapshot number

Once we encounter a build failure at a module,  the snapshot number begins
to vary and over time, all modules no longer have the same snapshot number
anymore

To be able to determine a consistent snapshot number at each build,  I
would like to have an ability the tell deploy maven plugin to use an
assigned number for all modules.

Possible?

Thanks

-D






On Thu, Sep 12, 2019 at 11:31 PM Enrico Olivelli 
wrote:

> Dan,
> Are you running a single 'mvn deploy' or do you have multiple runs?
> I have never seen weird behaviours in multi module projects
>
> Cheers
> Enrico
>
> Il ven 13 set 2019, 08:19 Dan Tran  ha scritto:
>
> > Hello, Maven dev
> >
> > any suggestion/thoughts on this issue are very much appreciated
> >
> > Regards
> >
> > -D
> >
> > On Wed, Sep 11, 2019 at 7:06 PM Dan Tran  wrote:
> >
> > > Hello Maven Users and Development Team
> > >
> > > Currently, artifact deployed as snapshot at Maven repository has the
> > > following format
> > >
> > >  artifactId-version-timestamp-NN
> > >
> > > where NN auto-incremented at each maven module and the number varies
> > >
> > > Is there a way to use same snapshot NN for the entire multi-module
> maven
> > > build?
> > >
> > > If I have to implement a solution, would it be as an extension or I
> have
> > > to tinker with maven-deploy-plugin?
> > >
> > > Very appreciated any advice
> > >
> > > -D
> > >
> > >
> > >
> > >
> > >
> >
>

Re: Same snapshot deploy number for entire build - possible

[Enrico Olivelli]

Dan,
Are you running a single 'mvn deploy' or do you have multiple runs?
I have never seen weird behaviours in multi module projects

Cheers
Enrico

Il ven 13 set 2019, 08:19 Dan Tran  ha scritto:

> Hello, Maven dev
>
> any suggestion/thoughts on this issue are very much appreciated
>
> Regards
>
> -D
>
> On Wed, Sep 11, 2019 at 7:06 PM Dan Tran  wrote:
>
> > Hello Maven Users and Development Team
> >
> > Currently, artifact deployed as snapshot at Maven repository has the
> > following format
> >
> >  artifactId-version-timestamp-NN
> >
> > where NN auto-incremented at each maven module and the number varies
> >
> > Is there a way to use same snapshot NN for the entire multi-module maven
> > build?
> >
> > If I have to implement a solution, would it be as an extension or I have
> > to tinker with maven-deploy-plugin?
> >
> > Very appreciated any advice
> >
> > -D
> >
> >
> >
> >
> >
>

Re: Same snapshot deploy number for entire build - possible

[Dan Tran]

Hello, Maven dev

any suggestion/thoughts on this issue are very much appreciated

Regards

-D

On Wed, Sep 11, 2019 at 7:06 PM Dan Tran  wrote:

> Hello Maven Users and Development Team
>
> Currently, artifact deployed as snapshot at Maven repository has the
> following format
>
>  artifactId-version-timestamp-NN
>
> where NN auto-incremented at each maven module and the number varies
>
> Is there a way to use same snapshot NN for the entire multi-module maven
> build?
>
> If I have to implement a solution, would it be as an extension or I have
> to tinker with maven-deploy-plugin?
>
> Very appreciated any advice
>
> -D
>
>
>
>
>