Re: Same snapshot deploy number for entire build - possible
as stated before we are not cutting RC build at CI level. We must stay with snapshot until it is closed to release date, this is where we will use CI friendly RC ( ie no more snaphots) Clarification of to your problem statements: 1. QA needs projects built from the same revision and each snapshot uploaded to maven repo must end with same snapshot buildNum 2. When the projects are built from the same revision, no one can verify that easily when the build numbers are different. -D On Mon, Sep 16, 2019 at 11:46 AM Jason Young wrote: > Dan, > > Thank you for clarifying the problem more. I think I understand better now. > > It sounds like there are really 2 problems: > 1. QA needs projects built from the same revision. > 2. When the projects are built from the same revision, no one can verify > that easily because the build numbers are different. > > Is that correct? > > For the first problem, I think Tibor's example of using a CI pipeline to > use the artifacts only if the whole reactor succeeds is what will work for > most people (it's what my team does, in effect, just with a different CI > tool). > > On Sun, Sep 15, 2019 at 5:35 PM Dan Tran wrote: > > > Please keep in mind QA is not a maven user. All download/deployment and > > testing are mostly automated, however, when come to reporting they have > to > > use something concrete which is the exact snapshot downloaded for them > > > > They also come to accept that each artifact has its own > buildNo/snapshotNo, > > but the same conversation keeps repeating about version inconsistency. ( > > if you add Jenkins build number it does get worse). My take here is to > > find a way to unify the snapshotNum for the entire build, then the > ongoing > > problem will be fixed > > > > Speaking of implementation, I dig a litter deeper by debugging thru maven > > deploy, but my IDE (eclipse) step debugger is out of syn ( maven deploy > > 2.8.2 --> artifact-transfier-->maven-resolver) > > so I dont have much luck getting more understanding of the code. > Basically > > I am looking for the exact place where Maven calculate the next snapshot > > number > > > > Thanks > > > > -D > > > > > > > > On Sun, Sep 15, 2019 at 1:57 PM Tibor Digana > > wrote: > > > > > Hi Francois and Dan, > > > > > > I understood it the same way as Francois mentioned. Not sure if NN in > the > > > format "artifactId-version-timestamp-NN" is a bug. Who cares is > probably > > > someone who downloads the artifact manually, maybe the QA. > > > Also downloading the artifacts from Nexus never was so trivial for QA > and > > > development team. > > > There's Nexus Proffessional and the Staging Repos but I found it useful > > > only in OSS developers. > > > > > > What was found acceptable was the solution where the QA does not > traverse > > > the path of groupId/artifactId in the repo, and it was a simple button > in > > > GUI and automatic deployment. Something where nobody downloads the > > artifact > > > directly. > > > My colleagues like integrating release candidates and not the > Snapsthots > > > because Snapshots are very volatile and the RCs are positively deployed > > > ones or two times a month - rarely. > > > > > > If the Snapshots must be downloaded every day then the question is why > > such > > > processes exist in the company or what's wrong with the project > > structures, > > > and what is missing in the automatic deployment. > > > > > > Cheers > > > Tibor17 > > > > > > > > > > > > On Sun, Sep 15, 2019 at 10:15 PM Francois Marot < > > francois.ma...@gmail.com> > > > wrote: > > > > > > > I'm sorry to insist but nevertheless I insist ;). I may have > > > misunderstood > > > > the problem but as I understand it, the whole problem can be sumed up > > by: > > > > " the fact that the repository adds a number at the end of the > deployed > > > > files is a problem because not all artifacts deployed from the same > > > reactor > > > > may not get the same suffix/number if some previous build failed half > > > way". > > > > I still do not see how it is a problem as it is only a problem if one > > > wants > > > > to get each files manually from the filesystem. In this case he does > > not > > > > know the *right* number for each artifact. > > > > But if the QA want to download all the artifacts belonging to the > > latest > > > > build, all he has to do is create a pom.xml referencing all those > > > artifact, > > > > use a variable as the version number and use the dependency plugin ( > > > > > > > > > > > > > > https://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html > > > > ) to retrieve the artifacts locally. > > > > > > > > This way, what you see as a problem is hust an internal > implementation > > > > detail of Maven/repository that you can circumvent easily. > > > > > > > > Again, I may have misunderstood so please excuse me if I'm talking > > > nonsense > > > > but I thought it could help. > > > > > > > > Regards > > > > > > > > > > > > > > > > > > >
Re: Failures building Eclipse 4.13 with maven-3.6.2
Hello, it looks like maven-3.6.2 really introduced a non compatible change with [core?] extensions and not just on polyglot-maven. In my own core extension project (jgitver-maven-plugin), when using maven-3.6.2, the ModelProcessor that I provide is not called anymore. Hope that helps to track down the culprit change. Matthieu On Sat, Sep 14, 2019 at 10:53 AM Enrico Olivelli wrote: > 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, Thank you for clarifying the problem more. I think I understand better now. It sounds like there are really 2 problems: 1. QA needs projects built from the same revision. 2. When the projects are built from the same revision, no one can verify that easily because the build numbers are different. Is that correct? For the first problem, I think Tibor's example of using a CI pipeline to use the artifacts only if the whole reactor succeeds is what will work for most people (it's what my team does, in effect, just with a different CI tool). On Sun, Sep 15, 2019 at 5:35 PM Dan Tran wrote: > Please keep in mind QA is not a maven user. All download/deployment and > testing are mostly automated, however, when come to reporting they have to > use something concrete which is the exact snapshot downloaded for them > > They also come to accept that each artifact has its own buildNo/snapshotNo, > but the same conversation keeps repeating about version inconsistency. ( > if you add Jenkins build number it does get worse). My take here is to > find a way to unify the snapshotNum for the entire build, then the ongoing > problem will be fixed > > Speaking of implementation, I dig a litter deeper by debugging thru maven > deploy, but my IDE (eclipse) step debugger is out of syn ( maven deploy > 2.8.2 --> artifact-transfier-->maven-resolver) > so I dont have much luck getting more understanding of the code. Basically > I am looking for the exact place where Maven calculate the next snapshot > number > > Thanks > > -D > > > > On Sun, Sep 15, 2019 at 1:57 PM Tibor Digana > wrote: > > > Hi Francois and Dan, > > > > I understood it the same way as Francois mentioned. Not sure if NN in the > > format "artifactId-version-timestamp-NN" is a bug. Who cares is probably > > someone who downloads the artifact manually, maybe the QA. > > Also downloading the artifacts from Nexus never was so trivial for QA and > > development team. > > There's Nexus Proffessional and the Staging Repos but I found it useful > > only in OSS developers. > > > > What was found acceptable was the solution where the QA does not traverse > > the path of groupId/artifactId in the repo, and it was a simple button in > > GUI and automatic deployment. Something where nobody downloads the > artifact > > directly. > > My colleagues like integrating release candidates and not the Snapsthots > > because Snapshots are very volatile and the RCs are positively deployed > > ones or two times a month - rarely. > > > > If the Snapshots must be downloaded every day then the question is why > such > > processes exist in the company or what's wrong with the project > structures, > > and what is missing in the automatic deployment. > > > > Cheers > > Tibor17 > > > > > > > > On Sun, Sep 15, 2019 at 10:15 PM Francois Marot < > francois.ma...@gmail.com> > > wrote: > > > > > I'm sorry to insist but nevertheless I insist ;). I may have > > misunderstood > > > the problem but as I understand it, the whole problem can be sumed up > by: > > > " the fact that the repository adds a number at the end of the deployed > > > files is a problem because not all artifacts deployed from the same > > reactor > > > may not get the same suffix/number if some previous build failed half > > way". > > > I still do not see how it is a problem as it is only a problem if one > > wants > > > to get each files manually from the filesystem. In this case he does > not > > > know the *right* number for each artifact. > > > But if the QA want to download all the artifacts belonging to the > latest > > > build, all he has to do is create a pom.xml referencing all those > > artifact, > > > use a variable as the version number and use the dependency plugin ( > > > > > > > > > https://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html > > > ) to retrieve the artifacts locally. > > > > > > This way, what you see as a problem is hust an internal implementation > > > detail of Maven/repository that you can circumvent easily. > > > > > > Again, I may have misunderstood so please excuse me if I'm talking > > nonsense > > > but I thought it could help. > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > > *- - - - -François Marot06 50 91 96 38* > > > > > > > > > > > > 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 > > > > > > > > > > --
