Re: Same snapshot deploy number for entire build - possible

2019-09-14 Thread Dan Tran
Found  this JIRA at MDEPLOY

   * https://issues.apache.org/jira/projects/MDEPLOY/issues/MDEPLOY-217
   * https://issues.apache.org/jira/projects/MDEPLOY/issues/MDEPLOY-199

Looks the place to look for is at maven-resolver? which responsible to
download maven-metadata and calculate next build number

Thanks

-D


On Sat, Sep 14, 2019 at 2:52 AM Robert Scholte  wrote:

> On Sat, 14 Sep 2019 07:17:16 +0200, Dan Tran  wrote:
>
> > Still waiting for the maven dev team to chime in if there is possible
> > solution
>
> Tamás is dev team member :)
>
> I don't know which code is responsible for adding the buildnumer.
> Personally I'd like to invest in MNG-5666[1], which should already be
> huge
> help for a lot of people.
> It might even reduce your problem. And afterwards, depending on where the
> buildnumber calculation is done, it should be easier to implement it per
> "deploymentgroup".
>
> thanks,
> Robert
>
> [1] https://issues.apache.org/jira/browse/MNG-5666
>
> -
> 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

2019-09-14 Thread Robert Scholte

On Sat, 14 Sep 2019 07:17:16 +0200, Dan Tran  wrote:


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


Tamás is dev team member :)

I don't know which code is responsible for adding the buildnumer.
Personally I'd like to invest in MNG-5666[1], which should already be huge  
help for a lot of people.
It might even reduce your problem. And afterwards, depending on where the  
buildnumber calculation is done, it should be easier to implement it per  
"deploymentgroup".


thanks,
Robert

[1] https://issues.apache.org/jira/browse/MNG-5666

-
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

2019-09-14 Thread Tibor Digana
Dan, you know how we solved this problem, we wrote Jenkinsfile with
interactive GUI. The release manager of QA filled out the items in web GUI
of Jenkins, means Version, Deployment IP in QA machines and some build
options. Simply we moved the responsibility to the person who argued the
most about the builds with different versions.

On Sat, Sep 14, 2019 at 7:17 AM Dan Tran  wrote:

> 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 <
> francois.ma...@gmail.com
> > >
> > > 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 

Re: Failures building Eclipse 4.13 with maven-3.6.2

2019-09-14 Thread Enrico Olivelli
Any volunteer to work on a fix?

Enrico

Il sab 14 set 2019, 10:08 Jonathan Chen  ha scritto:

> Hi,
>
> I didn't find a matching issue, so I raised MNG-6765 so that it can be
> tracked.
> https://issues.apache.org/jira/browse/MNG-6765
>
> Cheers.
> --
> Jonathan Chen 
>
> On Sat, 14 Sep 2019 at 19:47, Jonathan Chen  wrote:
> >
> > Hi,
> >
> > Thanks for that. Is there a JIRA reference for this bug?
> >
> > Cheers.
> > --
> > Jonathan Chen 
> >
> > On Sat, 14 Sep 2019 at 17:39, Jeff MAURY  wrote:
> > >
> > > 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
> > > >
> > > >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


Re: Failures building Eclipse 4.13 with maven-3.6.2

2019-09-14 Thread Jonathan Chen
Hi,

I didn't find a matching issue, so I raised MNG-6765 so that it can be tracked.
https://issues.apache.org/jira/browse/MNG-6765

Cheers.
-- 
Jonathan Chen 

On Sat, 14 Sep 2019 at 19:47, Jonathan Chen  wrote:
>
> Hi,
>
> Thanks for that. Is there a JIRA reference for this bug?
>
> Cheers.
> --
> Jonathan Chen 
>
> On Sat, 14 Sep 2019 at 17:39, Jeff MAURY  wrote:
> >
> > 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
> > >
> > >

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



Re: Failures building Eclipse 4.13 with maven-3.6.2

2019-09-14 Thread Jonathan Chen
Hi,

Thanks for that. Is there a JIRA reference for this bug?

Cheers.
-- 
Jonathan Chen 

On Sat, 14 Sep 2019 at 17:39, Jeff MAURY  wrote:
>
> 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
> >
> >

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