Hi Hervé, I'm sorry for the late reply > introducing new status, with pseudo-pom property and so on seems irrealistic, > at least to me: the concept is interesting, but I doubt it can fit into the > actual code Do you think it is feasible to add such status info as some plugin config? > Perhaps with Maven 3.2 (precise version and feature definition hypothetical), > since decoupling dependency resolution in a work in progress because really > needed: started in Maven 3.0 with a first extration into Aether, will > continue > in 3.1 with some experience in evolutions. An evolution like yours could be > imagined only after, IMHO When the 3.2 can be expected approx? Within one year?
Here I inserted my question into the original discussion. I hope it is still readable... >> Context: we have several modules which are built on top of each other. >> The build pipeline: >> - developer commits his/her changes to the SVN > ok, standard SNAPSHOT source >> - the Jenkins server checks out from SVN, compiles and runs the unit >> tests; finally, the jar artifacts are created and published with >> "integration" status > ok, publishing the SNAPSHOT binary to an integration repository >> - a Jenkins job retrieves this artifact from an Ivy repository and >> checks out secondary tests from the SVN; runs the secondary tests; if >> all tests pass, the description of the artifact is re-published with >> "milestone" status > this one can be done by copying the SNAPSHOT artifact from integration > repository to a milestone repository >> - other jobs grab only the artifact if it has least "milestone" status > other jobs, which refer to the SNAPSHOT with its "-SNAPSHOT" in the version > only use the milestone repository, not the integration one: fine Yep, but: is it possible to use mixed repository references i.e. one dependency references to integration and an other dependency references to milestone? I see here the first issue. >> - on the end of the pipeline "milestone" artifacts can be promoted >> manually to "release" if the manual tests are successful > that's the tricky part: you're changing a SNAPSHOT artifact to a release > do you expect build reproducibility of the release? (even if your objective is > to promote the pre-built binary, not to deploy a rebuild) I expect reproducible build, but in practice we experienced slight changes in the build environment, which in practice results pseudo reproducible build. E.g.: os/jdk updates, even if they are done in a controlled manner. > what about copying the binary into the same repo, ony changing its version > coordinates: of course, its content (META-INF/maven/$gid/$aid/pom.xml) won't > be consistent > >> - other loosely coupled projects reference only to artifacts with >> "release" status > ok, they reference release versions in the release repo > >> Promotion is handled completely by the apache-ivy. It allows you not >> only to reference snapshot as maven do, but you can specify >> "latest.integration" or "latest.release" as version. > without any version? and not "latest.milestone"? Yes, I mean "latest.milestone". Ivy is tricky as it can use 4th coordinate namely: branch, then it makes sense to reference latest.release from a specific branch. > with Maven and previous repo, you can write an unbounded range: [minimal,) Is "[minimal,)" means the latest, or any from the specified range? > activating integration consists in adding the integration repo > Notice: you might require separate integration or milestone repos to > distinguish which dependency can include milestone > would that make sense? Generally, yes. I have commented the problematic points. Regards, Gabor --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
