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
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
@Dan see here
https://github.com/apache/maven/blob/master/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/RemoteSnapshotMetadata.java
On Mon, Sep 16, 2019, 00:35 Dan Tran wrote:
> Please keep in mind QA is not a maven user. All download/deployment and
> testing are
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,
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
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
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
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
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
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.
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`.
@ 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
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
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
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
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
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
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
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
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
>
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
>
>
21 matches
Mail list logo