Re: Failures building Eclipse 4.13 with maven-3.6.2
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
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
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: Same snapshot deploy number for entire build - possible
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
Re: Same snapshot deploy number for entire build - possible
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
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 > >