You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Gábor Guta <th...@gmail.com> on 2012/12/19 15:37:18 UTC
Is there any on-going work to implement standard build
promotion/staging mechanism?
Can you give me feedback feedback / recommendation about how can I
write extensions for Maven to support a build pipeline and artifact
promotion in a "standard" way. As far as understand these issues are
common problems, because I have found many blogs describing hacks and
workarounds. I also have to mention that nexus and artifactory provide
custom fixes for these problems, but I would prefer not to be locked
to a specific vendor. I built an ant/ivy build pipeline implementing
promotion with the help of my team mates. My primary motivation is to
enable the mixing of artifacts from ant and maven builds through a
central maven repository.
I have two main issues with the current Maven model:
- no standard way to handle traceable snapshot i.e. snapshots are
temporary and I can't push them through on the testing pipeline by
referencing to them by a unique id (build number);
- no standard way to reference to staged/promoted artifact in the
dynamic version number i.e. I can't specify in a standard way that I
want the latest artifact which passed the integration test and has
version from a specific branch.
Proposal for promotion model:
- store status information in a POM property (introducing standard
meta data in the POM would be much nicer) e.g. integration, milestone
- write an extension which can interpret and resolve "3.3.?
latest.milestone" like notation in the version number
Proposal for staging model:
- status information is identified by the repository location, so I
have to be able to add multiple repositories with meta data about the
status of the stored artifacts
- write an extension which can interpret and resolve "3.3.?,
latest.milestone" like notation in the version number
Gabor
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Is there any on-going work to implement standard build
promotion/staging mechanism?
Posted by Gábor Guta <th...@gmail.com>.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Is there any on-going work to implement standard build promotion/staging mechanism?
Posted by Hervé BOUTEMY <he...@free.fr>.
sorry for the delay, time is missing lately
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
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
But looking at your actual pipeline, perhaps we can imagine something with
actual Maven features
Le dimanche 6 janvier 2013 10:18:18 Gábor Guta a écrit :
> Hi Hervé,
>
> > can you explain the ant/ivy build pipeline implementing promotion you did
> > with the help of my team mates?
>
> 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
> - 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)
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"?
with Maven and previous repo, you can write an unbounded range: [minimal,)
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?
Regards,
Hervé
> We use standard
> Ivy statuses, but custom statuses can be defined too.
>
> Regards, Gabor
>
> > (notice I won't be here for 1 week, so won't be able to continue the
> > discussion for the moment, but the topic is worth more discussion)
> >
> > Regards,
> >
> > Hervé
> >
> > Le jeudi 20 décembre 2012 12:12:22 Gábor Guta a écrit :
> >> Yes, I want to start the build of other projects if new version of the
> >> promoted artifact is available.
> >>
> >> Imagine a larger project in which 15-50 modules exists. Top level
> >> module build is triggered by the available new modules with a specific
> >> status i.e. performance tests run when new version of the dependencies
> >> with integration status available, but installer generation needs new
> >> artifact with milestone quality. Developers also prefer to work with
> >> milestone artifacts as they need something which is more stable than
> >> snapshot, but newer than the latest release. I hope this helped to
> >> clarify the role of module statuses.
> >>
> >> Regards, Gabor
> >>
> >> On Thu, Dec 20, 2012 at 8:35 AM, Hervé BOUTEMY <he...@free.fr>
> >
> > wrote:
> >> > ok, I see the workflow for single artifact promotion
> >> >
> >> > Once this artifact is promoted, you want to update another project's
> >> > dependency to rebuild using this (now promoted) artifact?
> >> > Or your wish is about not rebuilding the other project but promoting
> >> > its
> >> > built result and modifying dependency to let think it was built with
> >> > the
> >> > promoted artifact?
> >> >
> >> >
> >> > (notice I'm going to my day work: I won't be able to continue this
> >> > discussion before the end of the day...)
> >> >
> >> > Regards,
> >> >
> >> > Hervé
> >> >
> >> > Le jeudi 20 décembre 2012 07:51:08 Gábor Guta a écrit :
> >> >> We make the promotion of the already built artifact and we update the
> >> >> metadata. e.g.: if the corresponding integration tests are fine, the
> >> >> status of the artifact change to milestone.
> >> >>
> >> >> Regards, Gabor.
> >> >>
> >> >> On Thu, Dec 20, 2012 at 7:17 AM, Hervé BOUTEMY <he...@free.fr>
> >> >
> >> > wrote:
> >> >> > in your ideas, do you intend to rebuild the artifact at each
> >> >> > promotion,
> >> >> > or
> >> >> > make promotion of the already built artifact (then without
> >> >> > rebuilding
> >> >> > it),
> >> >> > only changing its status metatada?
> >> >> >
> >> >> > Regards,
> >> >> >
> >> >> > Hervé
> >> >> >
> >> >> > Le mercredi 19 décembre 2012 15:37:18 Gábor Guta a écrit :
> >> >> >> Can you give me feedback feedback / recommendation about how can I
> >> >> >> write extensions for Maven to support a build pipeline and artifact
> >> >> >> promotion in a "standard" way. As far as understand these issues
> >> >> >> are
> >> >> >> common problems, because I have found many blogs describing hacks
> >> >> >> and
> >> >> >> workarounds. I also have to mention that nexus and artifactory
> >> >> >> provide
> >> >> >> custom fixes for these problems, but I would prefer not to be
> >> >> >> locked
> >> >> >> to a specific vendor. I built an ant/ivy build pipeline
> >> >> >> implementing
> >> >> >> promotion with the help of my team mates. My primary motivation is
> >> >> >> to
> >> >> >> enable the mixing of artifacts from ant and maven builds through
> >> >> >> a
> >> >> >> central maven repository.
> >> >> >>
> >> >> >> I have two main issues with the current Maven model:
> >> >> >> - no standard way to handle traceable snapshot i.e. snapshots are
> >> >> >> temporary and I can't push them through on the testing pipeline by
> >> >> >> referencing to them by a unique id (build number);
> >> >> >> - no standard way to reference to staged/promoted artifact in the
> >> >> >> dynamic version number i.e. I can't specify in a standard way that
> >> >> >> I
> >> >> >> want the latest artifact which passed the integration test and has
> >> >> >> version from a specific branch.
> >> >> >>
> >> >> >> Proposal for promotion model:
> >> >> >> - store status information in a POM property (introducing standard
> >> >> >> meta data in the POM would be much nicer) e.g. integration,
> >> >> >> milestone
> >> >> >> - write an extension which can interpret and resolve "3.3.?
> >> >> >> latest.milestone" like notation in the version number
> >> >> >>
> >> >> >> Proposal for staging model:
> >> >> >> - status information is identified by the repository location, so I
> >> >> >> have to be able to add multiple repositories with meta data about
> >> >> >> the
> >> >> >> status of the stored artifacts
> >> >> >> - write an extension which can interpret and resolve "3.3.?,
> >> >> >> latest.milestone" like notation in the version number
> >> >> >>
> >> >> >>
> >> >> >> Gabor
> >> >> >>
> >> >> >> -------------------------------------------------------------------
> >> >> >> --
> >> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> >> >
> >> >> > --------------------------------------------------------------------
> >> >> > -
> >> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Is there any on-going work to implement standard build
promotion/staging mechanism?
Posted by Martin Gainty <mg...@hotmail.com>.
Hello Gabor
the logical next step for us maven folk would be to develop a plugin which synchronizes local (or remote) maven repositories
with the delta(s) from the originating ivy repository
I once worked at an ivy shoppe where i experienced macrodef regexp problem which ivy support was unable to solve
we ended up using maven maven-replacer-plugin to do the regexp parsing http://code.google.com/p/maven-replacer-plugin/ One reason why i prefer maven is there is an extensive talented support staff available that will answer any question 24-7 both here (and on users@maven.apache.org)
Many thanks for the insight,
Martin
______________________________________________
Jogi és Bizalmassági kinyilatkoztatás Ez az
üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy
jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának
készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és
semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek
könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet
ezen üzenet tartalma miatt.
> Date: Sun, 6 Jan 2013 17:05:00 +0100
> Subject: Re: Is there any on-going work to implement standard build promotion/staging mechanism?
> From: the.gaboo@gmail.com
> To: dev@maven.apache.org
>
> Hi Martin,
>
> As far as I understand our approach is fundamentally different than
> what "mvn release:prepare" does. We treat all build as a potential
> release build. After the binary artifacts are built from the source
> and the build number is stored in the SCM as a tag, we do not rebuild
> the binary artifacts anymore. Ivy stores the status of an artifact in
> the artifact repository and not in the SCM. The advantage of this for
> us:
> - we can trace the "snapshot like" artifacts (if a secondary test
> fails, we know the build numbers of the unstable dependencies),
> - it allows us a finer control over the "stability" of the used
> dependencies (we don't want to test fully all builds, but we want to
> integrate as frequently as possible),
> - we also don't have to rebuild the artifacts if we decided to release
> a specific build (for us it takes 3-5 hours to build everything).
>
> I don't know whether it is better or not, but it suites better for
> us (it is huge code base in which several modules released together as
> a single product).
>
> Regards, Gabor
>
> On Sun, Jan 6, 2013 at 2:59 PM, Martin Gainty <mg...@hotmail.com> wrote:
> >
> > Gabor How is Ivy better suited to specifying promotion/staging tags than implementing <tag> with mvn release:prepare?http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html
> > Martin
> > ______________________________________________
> > Jogi és Bizalmassági kinyilatkoztatás Ez az
> > üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy
> > jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának
> > készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és
> > semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek
> > könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet
> > ezen üzenet tartalma miatt.
> > > Date: Sun, 6 Jan 2013 10:18:18 +0100
> >> Subject: Re: Is there any on-going work to implement standard build promotion/staging mechanism?
> >> From: the.gaboo@gmail.com
> >> To: dev@maven.apache.org
> >>
> >> Hi Hervé,
> >>
> >> > can you explain the ant/ivy build pipeline implementing promotion you did with
> >> > the help of my team mates?
> >> Context: we have several modules which are built on top of each other.
> >> The build pipeline:
> >> - developer commits his/her changes to the SVN
> >> - the Jenkins server checks out from SVN, compiles and runs the unit
> >> tests; finally, the jar artifacts are created and published with
> >> "integration" status
> >> - 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
> >> - other jobs grab only the artifact if it has least "milestone" status
> >> - on the end of the pipeline "milestone" artifacts can be promoted
> >> manually to "release" if the manual tests are successful
> >> - other loosely coupled projects reference only to artifacts with
> >> "release" status
> >>
> >> 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. We use standard
> >> Ivy statuses, but custom statuses can be defined too.
> >>
> >> Regards, Gabor
> >>
> >> > (notice I won't be here for 1 week, so won't be able to continue the
> >> > discussion for the moment, but the topic is worth more discussion)
> >> >
> >> > Regards,
> >> >
> >> > Hervé
> >> >
> >> > Le jeudi 20 décembre 2012 12:12:22 Gábor Guta a écrit :
> >> >> Yes, I want to start the build of other projects if new version of the
> >> >> promoted artifact is available.
> >> >>
> >> >> Imagine a larger project in which 15-50 modules exists. Top level
> >> >> module build is triggered by the available new modules with a specific
> >> >> status i.e. performance tests run when new version of the dependencies
> >> >> with integration status available, but installer generation needs new
> >> >> artifact with milestone quality. Developers also prefer to work with
> >> >> milestone artifacts as they need something which is more stable than
> >> >> snapshot, but newer than the latest release. I hope this helped to
> >> >> clarify the role of module statuses.
> >> >>
> >> >> Regards, Gabor
> >> >>
> >> >> On Thu, Dec 20, 2012 at 8:35 AM, Hervé BOUTEMY <he...@free.fr>
> >> > wrote:
> >> >> > ok, I see the workflow for single artifact promotion
> >> >> >
> >> >> > Once this artifact is promoted, you want to update another project's
> >> >> > dependency to rebuild using this (now promoted) artifact?
> >> >> > Or your wish is about not rebuilding the other project but promoting its
> >> >> > built result and modifying dependency to let think it was built with the
> >> >> > promoted artifact?
> >> >> >
> >> >> >
> >> >> > (notice I'm going to my day work: I won't be able to continue this
> >> >> > discussion before the end of the day...)
> >> >> >
> >> >> > Regards,
> >> >> >
> >> >> > Hervé
> >> >> >
> >> >> > Le jeudi 20 décembre 2012 07:51:08 Gábor Guta a écrit :
> >> >> >> We make the promotion of the already built artifact and we update the
> >> >> >> metadata. e.g.: if the corresponding integration tests are fine, the
> >> >> >> status of the artifact change to milestone.
> >> >> >>
> >> >> >> Regards, Gabor.
> >> >> >>
> >> >> >> On Thu, Dec 20, 2012 at 7:17 AM, Hervé BOUTEMY <he...@free.fr>
> >> >> >
> >> >> > wrote:
> >> >> >> > in your ideas, do you intend to rebuild the artifact at each promotion,
> >> >> >> > or
> >> >> >> > make promotion of the already built artifact (then without rebuilding
> >> >> >> > it),
> >> >> >> > only changing its status metatada?
> >> >> >> >
> >> >> >> > Regards,
> >> >> >> >
> >> >> >> > Hervé
> >> >> >> >
> >> >> >> > Le mercredi 19 décembre 2012 15:37:18 Gábor Guta a écrit :
> >> >> >> >> Can you give me feedback feedback / recommendation about how can I
> >> >> >> >> write extensions for Maven to support a build pipeline and artifact
> >> >> >> >> promotion in a "standard" way. As far as understand these issues are
> >> >> >> >> common problems, because I have found many blogs describing hacks and
> >> >> >> >> workarounds. I also have to mention that nexus and artifactory provide
> >> >> >> >> custom fixes for these problems, but I would prefer not to be locked
> >> >> >> >> to a specific vendor. I built an ant/ivy build pipeline implementing
> >> >> >> >> promotion with the help of my team mates. My primary motivation is to
> >> >> >> >> enable the mixing of artifacts from ant and maven builds through a
> >> >> >> >> central maven repository.
> >> >> >> >>
> >> >> >> >> I have two main issues with the current Maven model:
> >> >> >> >> - no standard way to handle traceable snapshot i.e. snapshots are
> >> >> >> >> temporary and I can't push them through on the testing pipeline by
> >> >> >> >> referencing to them by a unique id (build number);
> >> >> >> >> - no standard way to reference to staged/promoted artifact in the
> >> >> >> >> dynamic version number i.e. I can't specify in a standard way that I
> >> >> >> >> want the latest artifact which passed the integration test and has
> >> >> >> >> version from a specific branch.
> >> >> >> >>
> >> >> >> >> Proposal for promotion model:
> >> >> >> >> - store status information in a POM property (introducing standard
> >> >> >> >> meta data in the POM would be much nicer) e.g. integration, milestone
> >> >> >> >> - write an extension which can interpret and resolve "3.3.?
> >> >> >> >> latest.milestone" like notation in the version number
> >> >> >> >>
> >> >> >> >> Proposal for staging model:
> >> >> >> >> - status information is identified by the repository location, so I
> >> >> >> >> have to be able to add multiple repositories with meta data about the
> >> >> >> >> status of the stored artifacts
> >> >> >> >> - write an extension which can interpret and resolve "3.3.?,
> >> >> >> >> latest.milestone" like notation in the version number
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> Gabor
> >> >> >> >>
> >> >> >> >> ---------------------------------------------------------------------
> >> >> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> >> >> >
> >> >> >> > ---------------------------------------------------------------------
> >> >> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >> >>
> >> >> >> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> >> >
> >> >> > ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Re: Is there any on-going work to implement standard build
promotion/staging mechanism?
Posted by Gábor Guta <th...@gmail.com>.
Hi Martin,
As far as I understand our approach is fundamentally different than
what "mvn release:prepare" does. We treat all build as a potential
release build. After the binary artifacts are built from the source
and the build number is stored in the SCM as a tag, we do not rebuild
the binary artifacts anymore. Ivy stores the status of an artifact in
the artifact repository and not in the SCM. The advantage of this for
us:
- we can trace the "snapshot like" artifacts (if a secondary test
fails, we know the build numbers of the unstable dependencies),
- it allows us a finer control over the "stability" of the used
dependencies (we don't want to test fully all builds, but we want to
integrate as frequently as possible),
- we also don't have to rebuild the artifacts if we decided to release
a specific build (for us it takes 3-5 hours to build everything).
I don't know whether it is better or not, but it suites better for
us (it is huge code base in which several modules released together as
a single product).
Regards, Gabor
On Sun, Jan 6, 2013 at 2:59 PM, Martin Gainty <mg...@hotmail.com> wrote:
>
> Gabor How is Ivy better suited to specifying promotion/staging tags than implementing <tag> with mvn release:prepare?http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html
> Martin
> ______________________________________________
> Jogi és Bizalmassági kinyilatkoztatás Ez az
> üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy
> jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának
> készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és
> semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek
> könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet
> ezen üzenet tartalma miatt.
> > Date: Sun, 6 Jan 2013 10:18:18 +0100
>> Subject: Re: Is there any on-going work to implement standard build promotion/staging mechanism?
>> From: the.gaboo@gmail.com
>> To: dev@maven.apache.org
>>
>> Hi Hervé,
>>
>> > can you explain the ant/ivy build pipeline implementing promotion you did with
>> > the help of my team mates?
>> Context: we have several modules which are built on top of each other.
>> The build pipeline:
>> - developer commits his/her changes to the SVN
>> - the Jenkins server checks out from SVN, compiles and runs the unit
>> tests; finally, the jar artifacts are created and published with
>> "integration" status
>> - 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
>> - other jobs grab only the artifact if it has least "milestone" status
>> - on the end of the pipeline "milestone" artifacts can be promoted
>> manually to "release" if the manual tests are successful
>> - other loosely coupled projects reference only to artifacts with
>> "release" status
>>
>> 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. We use standard
>> Ivy statuses, but custom statuses can be defined too.
>>
>> Regards, Gabor
>>
>> > (notice I won't be here for 1 week, so won't be able to continue the
>> > discussion for the moment, but the topic is worth more discussion)
>> >
>> > Regards,
>> >
>> > Hervé
>> >
>> > Le jeudi 20 décembre 2012 12:12:22 Gábor Guta a écrit :
>> >> Yes, I want to start the build of other projects if new version of the
>> >> promoted artifact is available.
>> >>
>> >> Imagine a larger project in which 15-50 modules exists. Top level
>> >> module build is triggered by the available new modules with a specific
>> >> status i.e. performance tests run when new version of the dependencies
>> >> with integration status available, but installer generation needs new
>> >> artifact with milestone quality. Developers also prefer to work with
>> >> milestone artifacts as they need something which is more stable than
>> >> snapshot, but newer than the latest release. I hope this helped to
>> >> clarify the role of module statuses.
>> >>
>> >> Regards, Gabor
>> >>
>> >> On Thu, Dec 20, 2012 at 8:35 AM, Hervé BOUTEMY <he...@free.fr>
>> > wrote:
>> >> > ok, I see the workflow for single artifact promotion
>> >> >
>> >> > Once this artifact is promoted, you want to update another project's
>> >> > dependency to rebuild using this (now promoted) artifact?
>> >> > Or your wish is about not rebuilding the other project but promoting its
>> >> > built result and modifying dependency to let think it was built with the
>> >> > promoted artifact?
>> >> >
>> >> >
>> >> > (notice I'm going to my day work: I won't be able to continue this
>> >> > discussion before the end of the day...)
>> >> >
>> >> > Regards,
>> >> >
>> >> > Hervé
>> >> >
>> >> > Le jeudi 20 décembre 2012 07:51:08 Gábor Guta a écrit :
>> >> >> We make the promotion of the already built artifact and we update the
>> >> >> metadata. e.g.: if the corresponding integration tests are fine, the
>> >> >> status of the artifact change to milestone.
>> >> >>
>> >> >> Regards, Gabor.
>> >> >>
>> >> >> On Thu, Dec 20, 2012 at 7:17 AM, Hervé BOUTEMY <he...@free.fr>
>> >> >
>> >> > wrote:
>> >> >> > in your ideas, do you intend to rebuild the artifact at each promotion,
>> >> >> > or
>> >> >> > make promotion of the already built artifact (then without rebuilding
>> >> >> > it),
>> >> >> > only changing its status metatada?
>> >> >> >
>> >> >> > Regards,
>> >> >> >
>> >> >> > Hervé
>> >> >> >
>> >> >> > Le mercredi 19 décembre 2012 15:37:18 Gábor Guta a écrit :
>> >> >> >> Can you give me feedback feedback / recommendation about how can I
>> >> >> >> write extensions for Maven to support a build pipeline and artifact
>> >> >> >> promotion in a "standard" way. As far as understand these issues are
>> >> >> >> common problems, because I have found many blogs describing hacks and
>> >> >> >> workarounds. I also have to mention that nexus and artifactory provide
>> >> >> >> custom fixes for these problems, but I would prefer not to be locked
>> >> >> >> to a specific vendor. I built an ant/ivy build pipeline implementing
>> >> >> >> promotion with the help of my team mates. My primary motivation is to
>> >> >> >> enable the mixing of artifacts from ant and maven builds through a
>> >> >> >> central maven repository.
>> >> >> >>
>> >> >> >> I have two main issues with the current Maven model:
>> >> >> >> - no standard way to handle traceable snapshot i.e. snapshots are
>> >> >> >> temporary and I can't push them through on the testing pipeline by
>> >> >> >> referencing to them by a unique id (build number);
>> >> >> >> - no standard way to reference to staged/promoted artifact in the
>> >> >> >> dynamic version number i.e. I can't specify in a standard way that I
>> >> >> >> want the latest artifact which passed the integration test and has
>> >> >> >> version from a specific branch.
>> >> >> >>
>> >> >> >> Proposal for promotion model:
>> >> >> >> - store status information in a POM property (introducing standard
>> >> >> >> meta data in the POM would be much nicer) e.g. integration, milestone
>> >> >> >> - write an extension which can interpret and resolve "3.3.?
>> >> >> >> latest.milestone" like notation in the version number
>> >> >> >>
>> >> >> >> Proposal for staging model:
>> >> >> >> - status information is identified by the repository location, so I
>> >> >> >> have to be able to add multiple repositories with meta data about the
>> >> >> >> status of the stored artifacts
>> >> >> >> - write an extension which can interpret and resolve "3.3.?,
>> >> >> >> latest.milestone" like notation in the version number
>> >> >> >>
>> >> >> >>
>> >> >> >> Gabor
>> >> >> >>
>> >> >> >> ---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> >> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >> >> >
>> >> >> > ---------------------------------------------------------------------
>> >> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> >> > For additional commands, e-mail: dev-help@maven.apache.org
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> > For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Is there any on-going work to implement standard build
promotion/staging mechanism?
Posted by Martin Gainty <mg...@hotmail.com>.
Gabor How is Ivy better suited to specifying promotion/staging tags than implementing <tag> with mvn release:prepare?http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html
Martin
______________________________________________
Jogi és Bizalmassági kinyilatkoztatás Ez az
üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy
jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának
készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és
semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek
könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet
ezen üzenet tartalma miatt.
> Date: Sun, 6 Jan 2013 10:18:18 +0100
> Subject: Re: Is there any on-going work to implement standard build promotion/staging mechanism?
> From: the.gaboo@gmail.com
> To: dev@maven.apache.org
>
> Hi Hervé,
>
> > can you explain the ant/ivy build pipeline implementing promotion you did with
> > the help of my team mates?
> Context: we have several modules which are built on top of each other.
> The build pipeline:
> - developer commits his/her changes to the SVN
> - the Jenkins server checks out from SVN, compiles and runs the unit
> tests; finally, the jar artifacts are created and published with
> "integration" status
> - 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
> - other jobs grab only the artifact if it has least "milestone" status
> - on the end of the pipeline "milestone" artifacts can be promoted
> manually to "release" if the manual tests are successful
> - other loosely coupled projects reference only to artifacts with
> "release" status
>
> 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. We use standard
> Ivy statuses, but custom statuses can be defined too.
>
> Regards, Gabor
>
> > (notice I won't be here for 1 week, so won't be able to continue the
> > discussion for the moment, but the topic is worth more discussion)
> >
> > Regards,
> >
> > Hervé
> >
> > Le jeudi 20 décembre 2012 12:12:22 Gábor Guta a écrit :
> >> Yes, I want to start the build of other projects if new version of the
> >> promoted artifact is available.
> >>
> >> Imagine a larger project in which 15-50 modules exists. Top level
> >> module build is triggered by the available new modules with a specific
> >> status i.e. performance tests run when new version of the dependencies
> >> with integration status available, but installer generation needs new
> >> artifact with milestone quality. Developers also prefer to work with
> >> milestone artifacts as they need something which is more stable than
> >> snapshot, but newer than the latest release. I hope this helped to
> >> clarify the role of module statuses.
> >>
> >> Regards, Gabor
> >>
> >> On Thu, Dec 20, 2012 at 8:35 AM, Hervé BOUTEMY <he...@free.fr>
> > wrote:
> >> > ok, I see the workflow for single artifact promotion
> >> >
> >> > Once this artifact is promoted, you want to update another project's
> >> > dependency to rebuild using this (now promoted) artifact?
> >> > Or your wish is about not rebuilding the other project but promoting its
> >> > built result and modifying dependency to let think it was built with the
> >> > promoted artifact?
> >> >
> >> >
> >> > (notice I'm going to my day work: I won't be able to continue this
> >> > discussion before the end of the day...)
> >> >
> >> > Regards,
> >> >
> >> > Hervé
> >> >
> >> > Le jeudi 20 décembre 2012 07:51:08 Gábor Guta a écrit :
> >> >> We make the promotion of the already built artifact and we update the
> >> >> metadata. e.g.: if the corresponding integration tests are fine, the
> >> >> status of the artifact change to milestone.
> >> >>
> >> >> Regards, Gabor.
> >> >>
> >> >> On Thu, Dec 20, 2012 at 7:17 AM, Hervé BOUTEMY <he...@free.fr>
> >> >
> >> > wrote:
> >> >> > in your ideas, do you intend to rebuild the artifact at each promotion,
> >> >> > or
> >> >> > make promotion of the already built artifact (then without rebuilding
> >> >> > it),
> >> >> > only changing its status metatada?
> >> >> >
> >> >> > Regards,
> >> >> >
> >> >> > Hervé
> >> >> >
> >> >> > Le mercredi 19 décembre 2012 15:37:18 Gábor Guta a écrit :
> >> >> >> Can you give me feedback feedback / recommendation about how can I
> >> >> >> write extensions for Maven to support a build pipeline and artifact
> >> >> >> promotion in a "standard" way. As far as understand these issues are
> >> >> >> common problems, because I have found many blogs describing hacks and
> >> >> >> workarounds. I also have to mention that nexus and artifactory provide
> >> >> >> custom fixes for these problems, but I would prefer not to be locked
> >> >> >> to a specific vendor. I built an ant/ivy build pipeline implementing
> >> >> >> promotion with the help of my team mates. My primary motivation is to
> >> >> >> enable the mixing of artifacts from ant and maven builds through a
> >> >> >> central maven repository.
> >> >> >>
> >> >> >> I have two main issues with the current Maven model:
> >> >> >> - no standard way to handle traceable snapshot i.e. snapshots are
> >> >> >> temporary and I can't push them through on the testing pipeline by
> >> >> >> referencing to them by a unique id (build number);
> >> >> >> - no standard way to reference to staged/promoted artifact in the
> >> >> >> dynamic version number i.e. I can't specify in a standard way that I
> >> >> >> want the latest artifact which passed the integration test and has
> >> >> >> version from a specific branch.
> >> >> >>
> >> >> >> Proposal for promotion model:
> >> >> >> - store status information in a POM property (introducing standard
> >> >> >> meta data in the POM would be much nicer) e.g. integration, milestone
> >> >> >> - write an extension which can interpret and resolve "3.3.?
> >> >> >> latest.milestone" like notation in the version number
> >> >> >>
> >> >> >> Proposal for staging model:
> >> >> >> - status information is identified by the repository location, so I
> >> >> >> have to be able to add multiple repositories with meta data about the
> >> >> >> status of the stored artifacts
> >> >> >> - write an extension which can interpret and resolve "3.3.?,
> >> >> >> latest.milestone" like notation in the version number
> >> >> >>
> >> >> >>
> >> >> >> Gabor
> >> >> >>
> >> >> >> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> >> >
> >> >> > ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Re: Is there any on-going work to implement standard build
promotion/staging mechanism?
Posted by Gábor Guta <th...@gmail.com>.
Hi Hervé,
> can you explain the ant/ivy build pipeline implementing promotion you did with
> the help of my team mates?
Context: we have several modules which are built on top of each other.
The build pipeline:
- developer commits his/her changes to the SVN
- the Jenkins server checks out from SVN, compiles and runs the unit
tests; finally, the jar artifacts are created and published with
"integration" status
- 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
- other jobs grab only the artifact if it has least "milestone" status
- on the end of the pipeline "milestone" artifacts can be promoted
manually to "release" if the manual tests are successful
- other loosely coupled projects reference only to artifacts with
"release" status
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. We use standard
Ivy statuses, but custom statuses can be defined too.
Regards, Gabor
> (notice I won't be here for 1 week, so won't be able to continue the
> discussion for the moment, but the topic is worth more discussion)
>
> Regards,
>
> Hervé
>
> Le jeudi 20 décembre 2012 12:12:22 Gábor Guta a écrit :
>> Yes, I want to start the build of other projects if new version of the
>> promoted artifact is available.
>>
>> Imagine a larger project in which 15-50 modules exists. Top level
>> module build is triggered by the available new modules with a specific
>> status i.e. performance tests run when new version of the dependencies
>> with integration status available, but installer generation needs new
>> artifact with milestone quality. Developers also prefer to work with
>> milestone artifacts as they need something which is more stable than
>> snapshot, but newer than the latest release. I hope this helped to
>> clarify the role of module statuses.
>>
>> Regards, Gabor
>>
>> On Thu, Dec 20, 2012 at 8:35 AM, Hervé BOUTEMY <he...@free.fr>
> wrote:
>> > ok, I see the workflow for single artifact promotion
>> >
>> > Once this artifact is promoted, you want to update another project's
>> > dependency to rebuild using this (now promoted) artifact?
>> > Or your wish is about not rebuilding the other project but promoting its
>> > built result and modifying dependency to let think it was built with the
>> > promoted artifact?
>> >
>> >
>> > (notice I'm going to my day work: I won't be able to continue this
>> > discussion before the end of the day...)
>> >
>> > Regards,
>> >
>> > Hervé
>> >
>> > Le jeudi 20 décembre 2012 07:51:08 Gábor Guta a écrit :
>> >> We make the promotion of the already built artifact and we update the
>> >> metadata. e.g.: if the corresponding integration tests are fine, the
>> >> status of the artifact change to milestone.
>> >>
>> >> Regards, Gabor.
>> >>
>> >> On Thu, Dec 20, 2012 at 7:17 AM, Hervé BOUTEMY <he...@free.fr>
>> >
>> > wrote:
>> >> > in your ideas, do you intend to rebuild the artifact at each promotion,
>> >> > or
>> >> > make promotion of the already built artifact (then without rebuilding
>> >> > it),
>> >> > only changing its status metatada?
>> >> >
>> >> > Regards,
>> >> >
>> >> > Hervé
>> >> >
>> >> > Le mercredi 19 décembre 2012 15:37:18 Gábor Guta a écrit :
>> >> >> Can you give me feedback feedback / recommendation about how can I
>> >> >> write extensions for Maven to support a build pipeline and artifact
>> >> >> promotion in a "standard" way. As far as understand these issues are
>> >> >> common problems, because I have found many blogs describing hacks and
>> >> >> workarounds. I also have to mention that nexus and artifactory provide
>> >> >> custom fixes for these problems, but I would prefer not to be locked
>> >> >> to a specific vendor. I built an ant/ivy build pipeline implementing
>> >> >> promotion with the help of my team mates. My primary motivation is to
>> >> >> enable the mixing of artifacts from ant and maven builds through a
>> >> >> central maven repository.
>> >> >>
>> >> >> I have two main issues with the current Maven model:
>> >> >> - no standard way to handle traceable snapshot i.e. snapshots are
>> >> >> temporary and I can't push them through on the testing pipeline by
>> >> >> referencing to them by a unique id (build number);
>> >> >> - no standard way to reference to staged/promoted artifact in the
>> >> >> dynamic version number i.e. I can't specify in a standard way that I
>> >> >> want the latest artifact which passed the integration test and has
>> >> >> version from a specific branch.
>> >> >>
>> >> >> Proposal for promotion model:
>> >> >> - store status information in a POM property (introducing standard
>> >> >> meta data in the POM would be much nicer) e.g. integration, milestone
>> >> >> - write an extension which can interpret and resolve "3.3.?
>> >> >> latest.milestone" like notation in the version number
>> >> >>
>> >> >> Proposal for staging model:
>> >> >> - status information is identified by the repository location, so I
>> >> >> have to be able to add multiple repositories with meta data about the
>> >> >> status of the stored artifacts
>> >> >> - write an extension which can interpret and resolve "3.3.?,
>> >> >> latest.milestone" like notation in the version number
>> >> >>
>> >> >>
>> >> >> Gabor
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> > For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Is there any on-going work to implement standard build promotion/staging mechanism?
Posted by Hervé BOUTEMY <he...@free.fr>.
ok
can you explain the ant/ivy build pipeline implementing promotion you did with
the help of my team mates?
(notice I won't be here for 1 week, so won't be able to continue the
discussion for the moment, but the topic is worth more discussion)
Regards,
Hervé
Le jeudi 20 décembre 2012 12:12:22 Gábor Guta a écrit :
> Yes, I want to start the build of other projects if new version of the
> promoted artifact is available.
>
> Imagine a larger project in which 15-50 modules exists. Top level
> module build is triggered by the available new modules with a specific
> status i.e. performance tests run when new version of the dependencies
> with integration status available, but installer generation needs new
> artifact with milestone quality. Developers also prefer to work with
> milestone artifacts as they need something which is more stable than
> snapshot, but newer than the latest release. I hope this helped to
> clarify the role of module statuses.
>
> Regards, Gabor
>
> On Thu, Dec 20, 2012 at 8:35 AM, Hervé BOUTEMY <he...@free.fr>
wrote:
> > ok, I see the workflow for single artifact promotion
> >
> > Once this artifact is promoted, you want to update another project's
> > dependency to rebuild using this (now promoted) artifact?
> > Or your wish is about not rebuilding the other project but promoting its
> > built result and modifying dependency to let think it was built with the
> > promoted artifact?
> >
> >
> > (notice I'm going to my day work: I won't be able to continue this
> > discussion before the end of the day...)
> >
> > Regards,
> >
> > Hervé
> >
> > Le jeudi 20 décembre 2012 07:51:08 Gábor Guta a écrit :
> >> We make the promotion of the already built artifact and we update the
> >> metadata. e.g.: if the corresponding integration tests are fine, the
> >> status of the artifact change to milestone.
> >>
> >> Regards, Gabor.
> >>
> >> On Thu, Dec 20, 2012 at 7:17 AM, Hervé BOUTEMY <he...@free.fr>
> >
> > wrote:
> >> > in your ideas, do you intend to rebuild the artifact at each promotion,
> >> > or
> >> > make promotion of the already built artifact (then without rebuilding
> >> > it),
> >> > only changing its status metatada?
> >> >
> >> > Regards,
> >> >
> >> > Hervé
> >> >
> >> > Le mercredi 19 décembre 2012 15:37:18 Gábor Guta a écrit :
> >> >> Can you give me feedback feedback / recommendation about how can I
> >> >> write extensions for Maven to support a build pipeline and artifact
> >> >> promotion in a "standard" way. As far as understand these issues are
> >> >> common problems, because I have found many blogs describing hacks and
> >> >> workarounds. I also have to mention that nexus and artifactory provide
> >> >> custom fixes for these problems, but I would prefer not to be locked
> >> >> to a specific vendor. I built an ant/ivy build pipeline implementing
> >> >> promotion with the help of my team mates. My primary motivation is to
> >> >> enable the mixing of artifacts from ant and maven builds through a
> >> >> central maven repository.
> >> >>
> >> >> I have two main issues with the current Maven model:
> >> >> - no standard way to handle traceable snapshot i.e. snapshots are
> >> >> temporary and I can't push them through on the testing pipeline by
> >> >> referencing to them by a unique id (build number);
> >> >> - no standard way to reference to staged/promoted artifact in the
> >> >> dynamic version number i.e. I can't specify in a standard way that I
> >> >> want the latest artifact which passed the integration test and has
> >> >> version from a specific branch.
> >> >>
> >> >> Proposal for promotion model:
> >> >> - store status information in a POM property (introducing standard
> >> >> meta data in the POM would be much nicer) e.g. integration, milestone
> >> >> - write an extension which can interpret and resolve "3.3.?
> >> >> latest.milestone" like notation in the version number
> >> >>
> >> >> Proposal for staging model:
> >> >> - status information is identified by the repository location, so I
> >> >> have to be able to add multiple repositories with meta data about the
> >> >> status of the stored artifacts
> >> >> - write an extension which can interpret and resolve "3.3.?,
> >> >> latest.milestone" like notation in the version number
> >> >>
> >> >>
> >> >> Gabor
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
Re: Is there any on-going work to implement standard build
promotion/staging mechanism?
Posted by Gábor Guta <th...@gmail.com>.
Yes, I want to start the build of other projects if new version of the
promoted artifact is available.
Imagine a larger project in which 15-50 modules exists. Top level
module build is triggered by the available new modules with a specific
status i.e. performance tests run when new version of the dependencies
with integration status available, but installer generation needs new
artifact with milestone quality. Developers also prefer to work with
milestone artifacts as they need something which is more stable than
snapshot, but newer than the latest release. I hope this helped to
clarify the role of module statuses.
Regards, Gabor
On Thu, Dec 20, 2012 at 8:35 AM, Hervé BOUTEMY <he...@free.fr> wrote:
> ok, I see the workflow for single artifact promotion
>
> Once this artifact is promoted, you want to update another project's
> dependency to rebuild using this (now promoted) artifact?
> Or your wish is about not rebuilding the other project but promoting its built
> result and modifying dependency to let think it was built with the promoted
> artifact?
>
>
> (notice I'm going to my day work: I won't be able to continue this discussion
> before the end of the day...)
>
> Regards,
>
> Hervé
>
> Le jeudi 20 décembre 2012 07:51:08 Gábor Guta a écrit :
>> We make the promotion of the already built artifact and we update the
>> metadata. e.g.: if the corresponding integration tests are fine, the
>> status of the artifact change to milestone.
>>
>> Regards, Gabor.
>>
>> On Thu, Dec 20, 2012 at 7:17 AM, Hervé BOUTEMY <he...@free.fr>
> wrote:
>> > in your ideas, do you intend to rebuild the artifact at each promotion, or
>> > make promotion of the already built artifact (then without rebuilding it),
>> > only changing its status metatada?
>> >
>> > Regards,
>> >
>> > Hervé
>> >
>> > Le mercredi 19 décembre 2012 15:37:18 Gábor Guta a écrit :
>> >> Can you give me feedback feedback / recommendation about how can I
>> >> write extensions for Maven to support a build pipeline and artifact
>> >> promotion in a "standard" way. As far as understand these issues are
>> >> common problems, because I have found many blogs describing hacks and
>> >> workarounds. I also have to mention that nexus and artifactory provide
>> >> custom fixes for these problems, but I would prefer not to be locked
>> >> to a specific vendor. I built an ant/ivy build pipeline implementing
>> >> promotion with the help of my team mates. My primary motivation is to
>> >> enable the mixing of artifacts from ant and maven builds through a
>> >> central maven repository.
>> >>
>> >> I have two main issues with the current Maven model:
>> >> - no standard way to handle traceable snapshot i.e. snapshots are
>> >> temporary and I can't push them through on the testing pipeline by
>> >> referencing to them by a unique id (build number);
>> >> - no standard way to reference to staged/promoted artifact in the
>> >> dynamic version number i.e. I can't specify in a standard way that I
>> >> want the latest artifact which passed the integration test and has
>> >> version from a specific branch.
>> >>
>> >> Proposal for promotion model:
>> >> - store status information in a POM property (introducing standard
>> >> meta data in the POM would be much nicer) e.g. integration, milestone
>> >> - write an extension which can interpret and resolve "3.3.?
>> >> latest.milestone" like notation in the version number
>> >>
>> >> Proposal for staging model:
>> >> - status information is identified by the repository location, so I
>> >> have to be able to add multiple repositories with meta data about the
>> >> status of the stored artifacts
>> >> - write an extension which can interpret and resolve "3.3.?,
>> >> latest.milestone" like notation in the version number
>> >>
>> >>
>> >> Gabor
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Is there any on-going work to implement standard build promotion/staging mechanism?
Posted by Hervé BOUTEMY <he...@free.fr>.
ok, I see the workflow for single artifact promotion
Once this artifact is promoted, you want to update another project's
dependency to rebuild using this (now promoted) artifact?
Or your wish is about not rebuilding the other project but promoting its built
result and modifying dependency to let think it was built with the promoted
artifact?
(notice I'm going to my day work: I won't be able to continue this discussion
before the end of the day...)
Regards,
Hervé
Le jeudi 20 décembre 2012 07:51:08 Gábor Guta a écrit :
> We make the promotion of the already built artifact and we update the
> metadata. e.g.: if the corresponding integration tests are fine, the
> status of the artifact change to milestone.
>
> Regards, Gabor.
>
> On Thu, Dec 20, 2012 at 7:17 AM, Hervé BOUTEMY <he...@free.fr>
wrote:
> > in your ideas, do you intend to rebuild the artifact at each promotion, or
> > make promotion of the already built artifact (then without rebuilding it),
> > only changing its status metatada?
> >
> > Regards,
> >
> > Hervé
> >
> > Le mercredi 19 décembre 2012 15:37:18 Gábor Guta a écrit :
> >> Can you give me feedback feedback / recommendation about how can I
> >> write extensions for Maven to support a build pipeline and artifact
> >> promotion in a "standard" way. As far as understand these issues are
> >> common problems, because I have found many blogs describing hacks and
> >> workarounds. I also have to mention that nexus and artifactory provide
> >> custom fixes for these problems, but I would prefer not to be locked
> >> to a specific vendor. I built an ant/ivy build pipeline implementing
> >> promotion with the help of my team mates. My primary motivation is to
> >> enable the mixing of artifacts from ant and maven builds through a
> >> central maven repository.
> >>
> >> I have two main issues with the current Maven model:
> >> - no standard way to handle traceable snapshot i.e. snapshots are
> >> temporary and I can't push them through on the testing pipeline by
> >> referencing to them by a unique id (build number);
> >> - no standard way to reference to staged/promoted artifact in the
> >> dynamic version number i.e. I can't specify in a standard way that I
> >> want the latest artifact which passed the integration test and has
> >> version from a specific branch.
> >>
> >> Proposal for promotion model:
> >> - store status information in a POM property (introducing standard
> >> meta data in the POM would be much nicer) e.g. integration, milestone
> >> - write an extension which can interpret and resolve "3.3.?
> >> latest.milestone" like notation in the version number
> >>
> >> Proposal for staging model:
> >> - status information is identified by the repository location, so I
> >> have to be able to add multiple repositories with meta data about the
> >> status of the stored artifacts
> >> - write an extension which can interpret and resolve "3.3.?,
> >> latest.milestone" like notation in the version number
> >>
> >>
> >> Gabor
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Is there any on-going work to implement standard build
promotion/staging mechanism?
Posted by Gábor Guta <th...@gmail.com>.
We make the promotion of the already built artifact and we update the
metadata. e.g.: if the corresponding integration tests are fine, the
status of the artifact change to milestone.
Regards, Gabor.
On Thu, Dec 20, 2012 at 7:17 AM, Hervé BOUTEMY <he...@free.fr> wrote:
> in your ideas, do you intend to rebuild the artifact at each promotion, or
> make promotion of the already built artifact (then without rebuilding it),
> only changing its status metatada?
>
> Regards,
>
> Hervé
>
> Le mercredi 19 décembre 2012 15:37:18 Gábor Guta a écrit :
>> Can you give me feedback feedback / recommendation about how can I
>> write extensions for Maven to support a build pipeline and artifact
>> promotion in a "standard" way. As far as understand these issues are
>> common problems, because I have found many blogs describing hacks and
>> workarounds. I also have to mention that nexus and artifactory provide
>> custom fixes for these problems, but I would prefer not to be locked
>> to a specific vendor. I built an ant/ivy build pipeline implementing
>> promotion with the help of my team mates. My primary motivation is to
>> enable the mixing of artifacts from ant and maven builds through a
>> central maven repository.
>>
>> I have two main issues with the current Maven model:
>> - no standard way to handle traceable snapshot i.e. snapshots are
>> temporary and I can't push them through on the testing pipeline by
>> referencing to them by a unique id (build number);
>> - no standard way to reference to staged/promoted artifact in the
>> dynamic version number i.e. I can't specify in a standard way that I
>> want the latest artifact which passed the integration test and has
>> version from a specific branch.
>>
>> Proposal for promotion model:
>> - store status information in a POM property (introducing standard
>> meta data in the POM would be much nicer) e.g. integration, milestone
>> - write an extension which can interpret and resolve "3.3.?
>> latest.milestone" like notation in the version number
>>
>> Proposal for staging model:
>> - status information is identified by the repository location, so I
>> have to be able to add multiple repositories with meta data about the
>> status of the stored artifacts
>> - write an extension which can interpret and resolve "3.3.?,
>> latest.milestone" like notation in the version number
>>
>>
>> Gabor
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Is there any on-going work to implement standard build promotion/staging mechanism?
Posted by Hervé BOUTEMY <he...@free.fr>.
in your ideas, do you intend to rebuild the artifact at each promotion, or
make promotion of the already built artifact (then without rebuilding it),
only changing its status metatada?
Regards,
Hervé
Le mercredi 19 décembre 2012 15:37:18 Gábor Guta a écrit :
> Can you give me feedback feedback / recommendation about how can I
> write extensions for Maven to support a build pipeline and artifact
> promotion in a "standard" way. As far as understand these issues are
> common problems, because I have found many blogs describing hacks and
> workarounds. I also have to mention that nexus and artifactory provide
> custom fixes for these problems, but I would prefer not to be locked
> to a specific vendor. I built an ant/ivy build pipeline implementing
> promotion with the help of my team mates. My primary motivation is to
> enable the mixing of artifacts from ant and maven builds through a
> central maven repository.
>
> I have two main issues with the current Maven model:
> - no standard way to handle traceable snapshot i.e. snapshots are
> temporary and I can't push them through on the testing pipeline by
> referencing to them by a unique id (build number);
> - no standard way to reference to staged/promoted artifact in the
> dynamic version number i.e. I can't specify in a standard way that I
> want the latest artifact which passed the integration test and has
> version from a specific branch.
>
> Proposal for promotion model:
> - store status information in a POM property (introducing standard
> meta data in the POM would be much nicer) e.g. integration, milestone
> - write an extension which can interpret and resolve "3.3.?
> latest.milestone" like notation in the version number
>
> Proposal for staging model:
> - status information is identified by the repository location, so I
> have to be able to add multiple repositories with meta data about the
> status of the stored artifacts
> - write an extension which can interpret and resolve "3.3.?,
> latest.milestone" like notation in the version number
>
>
> Gabor
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org