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. `<version>1.2.3-SNAPSHOT</version>`. 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 <dant...@gmail.com> 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 <ta...@cservenak.net> > 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-yyyymmdd.hhmmss-3 while the rest version is 1.0-yyyymmdd.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 Sep 2019 at 04:07, Dan Tran <dant...@gmail.com> 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 > > > > > > > > > > > > > > > --
