Continuous Delivery and Maven

[stug23 <pa...@gmail.com>]

I've been reading about Continuous Delivery <http://continuousdelivery.com/>
and trying to understand how to best combine Maven and Continuous Delivery.
There is a thread in the Continuous Delivery google group where this
discussion has started:

<http://groups.google.com/group/continuousdelivery/browse_thread/thread/c8440681058f2db8>

I would be curious as to whether there are other Maven developers following
the Maven Users forum that have been looking Continuous Delivery and trying
to grapple with the best way to use Maven in this approach.
-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3245370.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Yanko, Curtis" <cu...@uhc.com>]

Jez,

Again, you have carefully crafted a loosing scenario, which are easy to
do, just lay out a bunch of bad practices a your in . You seem to be
interested in A but ignore B and C. If you can rebuild A, why not B and
C? In this scenario you have crippled Maven and would need to rely on a
Build Management system to have mapped the relationships and have
captured the meta-data. If the relationships are mapped between A,B & C
then you would have some record of which ones were used. But, lets play
devils advocate and say we weren't following our process and people were
skipping steps. Your scenario is the *we didn't know* one and *can we go
back*?

In your case you are treating B and C as *external* dependencies and you
seem to assume they aren't hitting any milestones and *releasing*. As
external deps (separate SVN roots) we would never rely on a SNAPSHOT
version of them. In a CD world we would live with the most recent
*release* they have until they delivered new value. So, if we really
wanted their latest SNAPSHOT we would get it released so we can consume
it.

If it were in our repo root, we can go back and recreate the whole repo
and rebuild everything. Only *our* stuff can be SNAPSHOT (again, we're
doing the work).

If we take your logic to it's extreme are we saying the CD can not
tolerate a broken build? It can't possible be delivered! You've
abandoned Tags and Branches so I assume you have a fall forward
mentality (or roll back). In the case of a broken build in a CI system
using a Build Management System we should be able to very quickly get
back to a good build which could then be delivered.

What's more is I feel you are taking a narrow look at things. A world of
only SCC and Maven with no Build Management System. In this world you
would need to enable uniquely ID's snapshots in your Binary Repository
and at the very least retain your build logs, then you could go back to
that build of A and look at the log to see exactly which SNAPSHOTs were
used. Now you can have big continuous *jello* view of the world and
still have a detailed bill-of-materials. Not that you'd need it mind you
since your artifact would have been uniquely ID'd and stored (presumably
as a complete package somewhere) and now you don't even have to rebuild,
just go back and grab it and go from there.

While this is not how I'd use Maven, if you are willing to throw disk
space at the problem, so you can just keep everything and you're all
set.

________________________________

Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
Making IT Happen, one build at a time, 600 times a day

-----Original Message-----
From: jhumble [mailto:jez@jezhumble.net] 
Sent: Sunday, November 07, 2010 11:41 PM
To: users@maven.apache.org
Subject: Re: Continuous Delivery and Maven


Hi Curtis

I'm the first to admit I'm no Maven expert.

So please let me just confirm. Let's assume I am working on project A
which depends on projects B and C. For the sake of argument, let's say
that the source code for A, B and C have separate roots in SVN, and are
usually checked out independently. The CI system builds A at version 50
using snapshot dependencies on B and C, which are fetched from a central
snapshot repository.

Later, there are multiple updates to projects B and C which result in
new versions of them becoming available.

Say I now check out the source code to project A to version 50, because
I want to try and debug some issue that cropped up in a performance
testing environment, and I run a maven build. Will that use the latest
versions of the snapshots from the repo, or the versions that were
originally fetched when it was run on the CI system?

Can I even find out exactly which versions from svn the snapshots of B
and C came from that were used by the CI system to generate the original
build of A?

Thanks,

Jez.

On 7 November 2010 20:10, Yanko, Curtis [via Maven] <
ml-node+3254520-1036569885-143561@n5.nabble.com<ml-node%2B3254520-103656
ml-node+9885-143561@n5.nabble.com>
> wrote:

> Very interesting discussion. With all due respect to Mr. Humble, and I

> am a big fan of CD, I am going to venture to say that you don't 
> understand Maven very well. As a thought experiment, you are correct 
> in saying that a build based on snapshots is not reproducible. As a 
> more practical matter however, I feel it is.
>
> Dependencies come in two flavors, our and theirs (internal and 3rd 
> party). If, all of *our* dependencies are SNAPSHOT (we're doing the
> developing) and all of *theirs* are 'versioned' then the build is in 
> fact reproducible assuming you build everything from a particular repo

> version even with the default auto-update setting (in fact, it's 
> required).
> ________________________________
>
> Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
> Making IT Happen, one build at a time, 600 times a day
>
> -----Original Message-----
> From: jhumble [mailto:[hidden 
> email]<http://user/SendEmail.jtp?type=node&node=3254520&i=0>]
>
> Sent: Sunday, November 07, 2010 11:15 AM
> To: [hidden email] 
> <http://user/SendEmail.jtp?type=node&node=3254520&i=1>
> Subject: RE: Continuous Delivery and Maven
>
>
> Hey Todd
>
> The whole point of continuous delivery is that every check-in creates 
> a potential release candidate.
>
> When you're doing continuous deployment, you could be releasing 
> multiple times a day, so you don't bother cutting branches or tagging 
> or any of that stuff because of the overhead. I'd rather not get into 
> the justification for this process on this thread - but I wrote a book

> on it if you're interested:
> http://www.amazon.com/gp/product/0321601912 and many other people have

> blogged about it.
>
> You're right that creating a concrete release for each commit could 
> potentially use up a lot of space - but that's fine, you can just 
> delete the older ones. What this *does* mean in turn though is that it

> is essential to be able to recreate any given build given the version 
> in source control it came from, and this is where Maven falls down.
> Snapshots just aren't suitable because they aren't reproducible: what 
> the snapshot looks like depends not only on what versions of the 
> dependencies are available at the time the snapshot is created, but 
> also what Maven's configuration and plug-ins happen to be at the time 
> you run it (assuming Maven is configured to auto-update - the 
> default). I can't revert back to a particular revision in version 
> control, run maven, and be sure that the artifact it generates is 
> identical to the one it created when the commit was initially
triggered.
>
> Ideally what I'd like is for Maven to explicitly support the 
> continuous delivery model and provide snapshots that are reproducible.

> Failing that, a guide to configuring Maven so that its binaries are 
> reproducible (for example by switching off auto-update, and having 
> sufficient metadata stored in pom files and Maven's artifacts 
> repository to know what the state of each of the dependencies was at
any given time.
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32453
> 70<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32
> 45370?by-user=t>
> p3254090.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden 
> email]<http://user/SendEmail.jtp?type=node&node=3254520&i=2>
> For additional commands, e-mail: [hidden 
> email]<http://user/SendEmail.jtp?type=node&node=3254520&i=3>
>
>
> This e-mail, including attachments, may include confidential and/or 
> proprietary information, and may be used only by the person or entity 
> to which it is addressed. If the reader of this e-mail is not the 
> intended recipient or his or her authorized agent, the reader is 
> hereby notified that any dissemination, distribution or copying of 
> this e-mail is prohibited. If you have received this e-mail in error, 
> please notify the sender by replying to this message and delete this
e-mail immediately.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden 
> email]<http://user/SendEmail.jtp?type=node&node=3254520&i=4>
> For additional commands, e-mail: [hidden 
> email]<http://user/SendEmail.jtp?type=node&node=3254520&i=5>
>
>
>
> ------------------------------
>  View message @
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32453
> 70p3254520.html To unsubscribe from Continuous Delivery and Maven, 
> click
here<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubs
cribe_by_code&node=3245370&code=amV6QGplemh1bWJsZS5uZXR8MzI0NTM3MHwtMTg4
MjM1NzMyNA==>.
>
>
>


--
Jez Humble
Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
http://continuousdelivery.com/ http://jezhumble.net/

--
View this message in context:
http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370
p3254534.html
Sent from the Maven - Users mailing list archive at Nabble.com.

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Yanko, Curtis" <cu...@uhc.com>]

ad hoc dev *process* as an input...


________________________________

Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
Making IT Happen, one build at a time, 600 times a day

-----Original Message-----
From: Yanko, Curtis 
Sent: Monday, November 08, 2010 9:49 AM
To: Maven Users List
Subject: RE: Continuous Delivery and Maven

 
I would agree. CD is the logicval extension of CI, Continuous
Inspection, Continuous Testing and then and only then, Continuous
Delivery.

So I whole heartedly agree, Jez seems to have an ad hoc dev proves as an
input to his CD process and despite that, Maven can still make it work.

I also whole heartedly agree that while I am careful to protect the
foundational notion of Reproducibility, in practice it just doesn't
happen, we are always going forward and once you start treating builds
as build lives and start managing binaries in addition to code, you
never need to go back and reproduce a build.

________________________________

Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time, 600 times a day

-----Original Message-----
From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
Sent: Monday, November 08, 2010 9:17 AM
To: Maven Users List
Subject: Re: Continuous Delivery and Maven

On 8 November 2010 13:30, Thiessen, Todd (Todd) <tt...@avaya.com>
wrote:
> Interestingly enough, I kind of feel that we have a different
definition of continuous integration.
>

Interestingly enought, the original poster is talking about Continuous
_D_E_L_I_V_E_R_Y_ as distinct fron Continuous Integrration ;-)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity to
which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Yanko, Curtis" <cu...@uhc.com>]

 
I would agree. CD is the logicval extension of CI, Continuous
Inspection, Continuous Testing and then and only then, Continuous
Delivery.

So I whole heartedly agree, Jez seems to have an ad hoc dev proves as an
input to his CD process and despite that, Maven can still make it work.

I also whole heartedly agree that while I am careful to protect the
foundational notion of Reproducibility, in practice it just doesn't
happen, we are always going forward and once you start treating builds
as build lives and start managing binaries in addition to code, you
never need to go back and reproduce a build.

________________________________

Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
Making IT Happen, one build at a time, 600 times a day

-----Original Message-----
From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com] 
Sent: Monday, November 08, 2010 9:17 AM
To: Maven Users List
Subject: Re: Continuous Delivery and Maven

On 8 November 2010 13:30, Thiessen, Todd (Todd) <tt...@avaya.com>
wrote:
> Interestingly enough, I kind of feel that we have a different
definition of continuous integration.
>

Interestingly enought, the original poster is talking about Continuous
_D_E_L_I_V_E_R_Y_ as distinct fron Continuous Integrration ;-)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[Graham Leggett <mi...@sharp.fm>]

On 08 Nov 2010, at 7:03 PM, jhumble wrote:

> Two reasons: one, the faster you get feedback on the part of the  
> story you
> have done so far, the faster you know if any further work is going  
> to be
> valuable, and what in fact the next most valuable thing to deliver is.

How do you handle branches?

> Second, most of the pain of the software delivery process comes  
> *after* the
> software is dev-complete, during testing and deployment (often  
> called the
> "last mile"). One of the important points of cd is that by creating
> deployable software with every commit, you avoid the pain at the end  
> of the
> delivery process.

We have an alternative approach to this that we've found works just as  
well if not better - we require our developers to integrate their own  
code into a package. Until the code has been packaged, the developer  
is not done. We've chosen RPM as our packaging format, but any format  
that is deployable atomically will do.

We have further automated the deployments so that the packages are  
built in dedicated CI instances, in the process making it impossible  
for anyone to deploy anything that hasn't come out of source control  
first - no dodgy working copy builds or manual tweaking.

We've banned deployment documentation - if you want it installed, you  
have to roll it into your package. If you want anything more  
sophisticated than "deploy this RPM, graceful restart this service",  
you have to justify it.

We've found that doing this reduced costs on our platform by about an  
order of magnitude.

Regards,
Graham
--


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[jhumble <je...@jezhumble.net>]

>
>  You may use any number of commits to complete a particular user story.


But you can still keep your software releasable by implementing features in
an incremental way, as described here:
http://martinfowler.com/bliki/FeatureToggle.html

I don't see how delivering an in progress story has any value.


Two reasons: one, the faster you get feedback on the part of the story you
have done so far, the faster you know if any further work is going to be
valuable, and what in fact the next most valuable thing to deliver is.

Second, most of the pain of the software delivery process comes *after* the
software is dev-complete, during testing and deployment (often called the
"last mile"). One of the important points of cd is that by creating
deployable software with every commit, you avoid the pain at the end of the
delivery process.

Jez.

On 8 November 2010 08:52, Thiessen, Todd (Todd) [via Maven] <
ml-node+3255344-939946112-143561@n5.nabble.com<ml...@n5.nabble.com>
> wrote:

>
> > In my view of CD, you wouldn't come back, ever. You'd just commit code
> > that triggers a build and if it passes each and every quality gate along
> > the way it would get deployed.
>
> I am even struggling with that. A commit of some code, does not imply a
> deliverable feature.  You may use any number of commits to complete a
> particular user story. I don't see how delivering an in progress story has
> any value.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3255344&i=0>
> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3255344&i=1>
>
>
>
> ------------------------------
>  View message @
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3255344.html
> To unsubscribe from Continuous Delivery and Maven, click here<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_code&node=3245370&code=amV6QGplemh1bWJsZS5uZXR8MzI0NTM3MHwtMTg4MjM1NzMyNA==>.
>
>
>


-- 
Jez Humble
Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
http://continuousdelivery.com/
http://jezhumble.net/

-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3255375.html
Sent from the Maven - Users mailing list archive at Nabble.com.

RE: Continuous Delivery and Maven

["Yanko, Curtis" <cu...@uhc.com>]

There are techniques to do that, stuff like feature toggle for instance.
The Agile Executive just ran a story on this recently.


________________________________

Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
Making IT Happen, one build at a time, 600 times a day

-----Original Message-----
From: Thiessen, Todd (Todd) [mailto:tthiessen@avaya.com] 
Sent: Monday, November 08, 2010 11:52 AM
To: Maven Users List
Subject: RE: Continuous Delivery and Maven

 
> In my view of CD, you wouldn't come back, ever. You'd just commit code

> that triggers a build and if it passes each and every quality gate 
> along the way it would get deployed.

I am even struggling with that. A commit of some code, does not imply a
deliverable feature.  You may use any number of commits to complete a
particular user story. I don't see how delivering an in progress story
has any value.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Thiessen, Todd (Todd)" <tt...@avaya.com>]

 
> In my view of CD, you wouldn't come back, ever. You'd just commit code
> that triggers a build and if it passes each and every quality gate along
> the way it would get deployed.

I am even struggling with that. A commit of some code, does not imply a deliverable feature.  You may use any number of commits to complete a particular user story. I don't see how delivering an in progress story has any value.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Yanko, Curtis" <cu...@uhc.com>]

 I like where you are going with this but I don't understand the need to re-build or to have two different build processes. I'm in the Maciej Zawadzki camp of Build lives, that a build is just the beginning and you need to manage it in a way that let you come back and continue to advance it if you want.

In my view of CD, you wouldn't come back, ever. You'd just commit code that triggers a build and if it passes each and every quality gate along the way it would get deployed. If it fails at any point, it dies and a new build is created to address the reason it failed.
________________________________

Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
Making IT Happen, one build at a time, 600 times a day

-----Original Message-----
From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com] 
Sent: Monday, November 08, 2010 9:54 AM
To: Maven Users List
Subject: Re: Continuous Delivery and Maven

On 8 November 2010 14:50, Stephen Connolly <st...@gmail.com> wrote:
> CI does not end up on production systems, so CI does not require as 
> rigourously reproducible a build as CD.
>
> With CI, what you want to have happen is the latest code ends up on an 
> integration system and integration tests are run against the 
> integration system in order to identify integration issues before the 
> code goes to QA.
>
> With CD you have as much of the QA process automated as you are 
> comfrtable with, and when you kick off a build, it will automatically 
> run though an entirely automated process that ends up with the build 
> either failing or being deployed onto the live system... (note that 
> you might have one or two manual verifications before deploying to 
> production systems, but sooner or later you will have developed enough 
> confidence in your CD process that you can feel confident removing the 
> manual blocks)
>
> With CI, I can quite happily work with -SNAPSHOTs because all I need 
> to know is that something is broken.
>
> With CD, I need releases (but perhaps more lightweight than Maven's 
> current release process... perhaps I do not need to create tags).
>
> The question is what triggers the deploy in CD.
>
> There are a number of possible triggers:
>
> 1. Manual trigger... where I click a button and the whole process 
> starts 2. CI trigger... where a CI build passing triggers the whole 
> process 3. Commit trigger... where any commit triggers the whole process.
>
> The problem with #1 is that you have to remember to trigger
>
> If you are doing CD correctly, then #2 and #3 are actually the same 
> thing with just a re-ordered pipeline.
>
> #2 goes a little something like this
> 2.1 A commit triggers a build
> 2.2 The build passes and triggers a CI build
> 2.3 The CI build deploys to the integration system and runs the 
> integration tests
> 2.4 The CI build passes and triggers the CD build
> 2.5 The CD build runs a release of the software
> 2.6 The CD build deploys the release to the integration system and 
> runs the integration tests
> 2.7 The CD build runs the last ditch "no egg on face" tests that could 
> take a bit longer than integration tests (e.g. full regression)
> 2.8 All tests have passed and the CD build meets the release to 
> customer criteria
> 2.9 The CD build deploys the release to production systems 2.10 we are 
> live
>
> while #3 goes a little something like this
> 3.1 The CD build runs a release of the software
> 3.2 The CD build deploys the release to the integration system and 
> runs the integration tests
> 3.3 The CD build runs the last ditch "no egg on face" tests that could 
> take a bit longer than integration tests (e.g. full regression)
> 3.4 All tests have passed and the CD build meets the release to 
> customer criteria
> 3.5 The CD build deploys the release to production systems
> 3.6 we are live
>
> #2 saves on the churn of making releases but reduces the response time 
> for deployment.
>
> In any case you also want an automated process that allows you to roll 
> the production system back to a previous state just in case the "no 
> egg on face" tests let some egg slip through to your face!

Just to clarify, the only reason you want roll-back is when there is egg on your face you need to remove it fast... while you could just revert back SCM to "known good" state, it's faster to just re-deploy "known good" binaries which had previously met the delivery criteria, rather than have to run through the fuill regression suite again!

-Stephen

>
> -Stephen
> On 8 November 2010 14:27, Thiessen, Todd (Todd) <tt...@avaya.com> wrote:
>> True. But how does that change my statement? It still appears we may have a different definition of CI.  Because in order to do CD, you would no longer be doing CI.
>>
>> Unless of course the original poster is suggesting to abandon CI.
>>
>>> -----Original Message-----
>>> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
>>> Sent: Monday, November 08, 2010 9:17 AM
>>> To: Maven Users List
>>> Subject: Re: Continuous Delivery and Maven
>>>
>>> On 8 November 2010 13:30, Thiessen, Todd (Todd) 
>>> <tt...@avaya.com>
>>> wrote:
>>> > Interestingly enough, I kind of feel that we have a different
>>> definition of continuous integration.
>>> >
>>>
>>> Interestingly enought, the original poster is talking about 
>>> Continuous _D_E_L_I_V_E_R_Y_ as distinct fron Continuous 
>>> Integrration ;-)
>>>
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[Stephen Connolly <st...@gmail.com>]

On 8 November 2010 14:50, Stephen Connolly
<st...@gmail.com> wrote:
> CI does not end up on production systems, so CI does not require as
> rigourously reproducible a build as CD.
>
> With CI, what you want to have happen is the latest code ends up on an
> integration system and integration tests are run against the
> integration system in order to identify integration issues before the
> code goes to QA.
>
> With CD you have as much of the QA process automated as you are
> comfrtable with, and when you kick off a build, it will automatically
> run though an entirely automated process that ends up with the build
> either failing or being deployed onto the live system... (note that
> you might have one or two manual verifications before deploying to
> production systems, but sooner or later you will have developed enough
> confidence in your CD process that you can feel confident removing the
> manual blocks)
>
> With CI, I can quite happily work with -SNAPSHOTs because all I need
> to know is that something is broken.
>
> With CD, I need releases (but perhaps more lightweight than Maven's
> current release process... perhaps I do not need to create tags).
>
> The question is what triggers the deploy in CD.
>
> There are a number of possible triggers:
>
> 1. Manual trigger... where I click a button and the whole process starts
> 2. CI trigger... where a CI build passing triggers the whole process
> 3. Commit trigger... where any commit triggers the whole process.
>
> The problem with #1 is that you have to remember to trigger
>
> If you are doing CD correctly, then #2 and #3 are actually the same
> thing with just a re-ordered pipeline.
>
> #2 goes a little something like this
> 2.1 A commit triggers a build
> 2.2 The build passes and triggers a CI build
> 2.3 The CI build deploys to the integration system and runs the
> integration tests
> 2.4 The CI build passes and triggers the CD build
> 2.5 The CD build runs a release of the software
> 2.6 The CD build deploys the release to the integration system and
> runs the integration tests
> 2.7 The CD build runs the last ditch "no egg on face" tests that could
> take a bit longer than integration tests (e.g. full regression)
> 2.8 All tests have passed and the CD build meets the release to
> customer criteria
> 2.9 The CD build deploys the release to production systems
> 2.10 we are live
>
> while #3 goes a little something like this
> 3.1 The CD build runs a release of the software
> 3.2 The CD build deploys the release to the integration system and
> runs the integration tests
> 3.3 The CD build runs the last ditch "no egg on face" tests that could
> take a bit longer than integration tests (e.g. full regression)
> 3.4 All tests have passed and the CD build meets the release to
> customer criteria
> 3.5 The CD build deploys the release to production systems
> 3.6 we are live
>
> #2 saves on the churn of making releases but reduces the response time
> for deployment.
>
> In any case you also want an automated process that allows you to roll
> the production system back to a previous state just in case the "no
> egg on face" tests let some egg slip through to your face!

Just to clarify, the only reason you want roll-back is when there is
egg on your face you need to remove it fast... while you could just
revert back SCM to "known good" state, it's faster to just re-deploy
"known good" binaries which had previously met the delivery criteria,
rather than have to run through the fuill regression suite again!

-Stephen

>
> -Stephen
> On 8 November 2010 14:27, Thiessen, Todd (Todd) <tt...@avaya.com> wrote:
>> True. But how does that change my statement? It still appears we may have a different definition of CI.  Because in order to do CD, you would no longer be doing CI.
>>
>> Unless of course the original poster is suggesting to abandon CI.
>>
>>> -----Original Message-----
>>> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
>>> Sent: Monday, November 08, 2010 9:17 AM
>>> To: Maven Users List
>>> Subject: Re: Continuous Delivery and Maven
>>>
>>> On 8 November 2010 13:30, Thiessen, Todd (Todd) <tt...@avaya.com>
>>> wrote:
>>> > Interestingly enough, I kind of feel that we have a different
>>> definition of continuous integration.
>>> >
>>>
>>> Interestingly enought, the original poster is talking about Continuous
>>> _D_E_L_I_V_E_R_Y_ as distinct fron Continuous Integrration ;-)
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[jhumble <je...@jezhumble.net>]

>
>
> And in a community driven environment, if something isn't perceived as
> valuable, it generally doesn't get done. You are welcome to create a plugin
> to do this or perhaps enhance an existing one. If the community feels it is
> valuable, you will get a lot of help to make it happen. If the community
> doesn't, then you won't ;-).


Sure, I get that, that's why I'm polling the maven users list before I break
out IntelliJ :-)

Jez.

-- 
Jez Humble
Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
http://continuousdelivery.com/
http://jezhumble.net/

-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3255947.html
Sent from the Maven - Users mailing list archive at Nabble.com.

RE: Continuous Delivery and Maven

["Yanko, Curtis" <cu...@uhc.com>]

> I'm just saying, that as a practical matter, we can today solve your 
> problem without the need for a new plugin. Reproducible, and
Auditable.
> I can look at anything directly, even in Prod, and make the leap all 
> the way to SVN without a single cross reference or lookup because we 
> put all that meta-data in the manifest, just not in the POM (in your 
> scenario, in ours the POM has everything listed as a version though so

> we don't face the SNAPSHOT issue).
>

Fair enough, but you have to do a bunch of extra work to include that
information in the manifest, and the manifest doesn't include
information on transitive dependencies. I want the tool to support it
out of the box by including the information in the pom that goes along
with the artifacts it creates.

Cmy - We're not doing any extra work to get that info into the manifest.
The plugin that does that is defined in a corporate POM that everyone
uses. If all of my deps in my POMs are at release then they have all of
the dependency info they need, including transient, why wouldn't it?


Of course, the pom is in XML which is eXtensible, so existing tools can
ignore this extra information if they like! So I don't see why it should
be a problem.

You want to be able to Audit but eschew documentation like a Site
> reports? Again seems sort of cake-and-eat-it-too to me.
>

Perhaps I expressed myself poorly. I am fine creating documentation like
site reports, but I want to be able to derive the information in the
site report from the metadata associated with my binaries.

Cmy - Again, I think we can, it's all in the POM and running a
dependency:resolve will go beyond the POM.


-Curt

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Thiessen, Todd (Todd)" <tt...@avaya.com>]

> You may not care about them, and that's fine, but I want any tool I use
> to
> be able to work according to these principles.

You are free to use whichever tool fits your needs. And Maven can fit that need by putting build information in the artifact. But clearly that isn't sufficient. You want something more. I don't think Maven supports what you are looking for out of box. And that's fine too.
 
> I want the tool to support it out of the box by
> including the information in the pom that goes along with the artifacts
> it
> creates.

And that is your preference. But others may disagree. And in a community driven environment, if something isn't perceived as valuable, it generally doesn't get done. You are welcome to create a plugin to do this or perhaps enhance an existing one. If the community feels it is valuable, you will get a lot of help to make it happen. If the community doesn't, then you won't ;-).

> Of course, the pom is in XML which is eXtensible, so existing tools can
> ignore this extra information if they like! So I don't see why it should
> be
> a problem.

What do you do with the information once you have it? Are you thinking of extending the concept of version? And how do you ensure that the data is always accurate? Do you update this information during a build and then recommit? You say that putting build information in the jar is extra work. But that sounds a lot simplier than querying this metadata at build time and then storing it in source control.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[jhumble <je...@jezhumble.net>]

Hi Curtis


> What you're proposing is indeed interesting. But you do seem to pick and
> choose what you want (reproducibility) and what you can dispense with
> (tags and branches).
>

Correct. In my defence, I have extremely good reasons why I want
reproducibility and don't care about tagging, derived from high level
principles about how to do software delivery in a reliable, efficient way.
You may not care about them, and that's fine, but I want any tool I use to
be able to work according to these principles.


> I'm just saying, that as a practical matter, we can today solve your
> problem without the need for a new plugin. Reproducible, and Auditable.
> I can look at anything directly, even in Prod, and make the leap all the
> way to SVN without a single cross reference or lookup because we put all
> that meta-data in the manifest, just not in the POM (in your scenario,
> in ours the POM has everything listed as a version though so we don't
> face the SNAPSHOT issue).
>

Fair enough, but you have to do a bunch of extra work to include that
information in the manifest, and the manifest doesn't include information on
transitive dependencies. I want the tool to support it out of the box by
including the information in the pom that goes along with the artifacts it
creates.

Of course, the pom is in XML which is eXtensible, so existing tools can
ignore this extra information if they like! So I don't see why it should be
a problem.

You want to be able to Audit but eschew documentation like a Site
> reports? Again seems sort of cake-and-eat-it-too to me.
>

Perhaps I expressed myself poorly. I am fine creating documentation like
site reports, but I want to be able to derive the information in the site
report from the metadata associated with my binaries.

-- 
Jez Humble
Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
http://continuousdelivery.com/
http://jezhumble.net/

-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3255698.html
Sent from the Maven - Users mailing list archive at Nabble.com.

Re: Continuous Delivery and Maven

[jhumble <je...@jezhumble.net>]

Fair enough. I would love to believe that Maven will work just fine with CD
in its present state, and perhaps you have cracked it. It's just that I have
heard enough people I trust tell me otherwise so I wanted to see what people
are doing and throw some ideas around.

Anyway I'm signing off for the day, but thanks to you and the rest of the
group for an interesting discussion :-)

Jez.

On 8 November 2010 18:27, Yanko, Curtis [via Maven] <
ml-node+3256136-495546356-143561@n5.nabble.com<ml...@n5.nabble.com>
> wrote:

>
> --And I think this is the nub of the problem - you don't have a
> sufficiently frequent release cycle to experience the problems I am
> describing.
>
> I too came to this same conclusion. I get that now, even every two weeks
> isn't enough but I still don't see my process being a pain even if we
> released a few times daily, I really don't.
>
> Also understand that I am committed to understanding how I'm going to
> get my projects to CD some day but my assumption was that I'd be
> building on my existing work and figure it must be my ignorance that
> makes me feel like the rug is being pulled out. I confess I haven't read
> your book yet but it is on my short list so only a matter of time I'm
> sure.
>
> ________________________________
>
> Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
> Making IT Happen, one build at a time, 600 times a day
>
> -----Original Message-----
> From: jhumble [mailto:[hidden email]<http://user/SendEmail.jtp?type=node&node=3256136&i=0>]
>
> Sent: Monday, November 08, 2010 6:54 PM
> To: [hidden email] <http://user/SendEmail.jtp?type=node&node=3256136&i=1>
> Subject: Re: Continuous Delivery and Maven
>
>
> >
> > My mantra is this, if you are feeling pain in your process, do it more
>
> > often which should force you to either solve the problem or realize
> > it's upstream.
>
>
> That is one of my 8 principles of CD ("If It Hurts, Do It More
> Frequently, and Bring the Pain Forward" - p26). And I think it applies
> to integrating modules too.
>
>
> > You're trying to solve a two-sided jello view of a system at build
> > time, perhaps what you need is to refactor you architecture (and why
> > SaaS, Cloud and federated systems lend themselves to CD). Maven is
> > your pain point but I say you're just not doing it right.
> >
>
> We can both play that game, but it's not very productive. I respect the
> fact that you have a bunch of experience and that you've created a
> process that works great for you, and I am not suggesting you change it.
> Hard as it may be to believe, I have had many experiences that point me
> in exactly the opposite direction, also working for organizations that
> make "our little
> A->B->C game" seem trivial.
>
> So, after we *find something valuable* we can release it trivially.
> >
>
> And I think this is the nub of the problem - you don't have a
> sufficiently frequent release cycle to experience the problems I am
> describing.
>
> --
> Jez Humble
> Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
> http://continuousdelivery.com/ http://jezhumble.net/
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370?by-user=t>
> p3256015.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> This e-mail, including attachments, may include confidential and/or
> proprietary information, and may be used only by the person or entity
> to which it is addressed. If the reader of this e-mail is not the intended
> recipient or his or her authorized agent, the reader is hereby notified
> that any dissemination, distribution or copying of this e-mail is
> prohibited. If you have received this e-mail in error, please notify the
> sender by replying to this message and delete this e-mail immediately.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3256136&i=2>
> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3256136&i=3>
>
>
>
> ------------------------------
>  View message @
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3256136.html
> To unsubscribe from Continuous Delivery and Maven, click here<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_code&node=3245370&code=amV6QGplemh1bWJsZS5uZXR8MzI0NTM3MHwtMTg4MjM1NzMyNA==>.
>
>
>


-- 
Jez Humble
Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
http://continuousdelivery.com/
http://jezhumble.net/

-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3256153.html
Sent from the Maven - Users mailing list archive at Nabble.com.

RE: Continuous Delivery and Maven

["Yanko, Curtis" <cu...@uhc.com>]

 
--And I think this is the nub of the problem - you don't have a
sufficiently frequent release cycle to experience the problems I am
describing.

I too came to this same conclusion. I get that now, even every two weeks
isn't enough but I still don't see my process being a pain even if we
released a few times daily, I really don't.

Also understand that I am committed to understanding how I'm going to
get my projects to CD some day but my assumption was that I'd be
building on my existing work and figure it must be my ignorance that
makes me feel like the rug is being pulled out. I confess I haven't read
your book yet but it is on my short list so only a matter of time I'm
sure.

________________________________

Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
Making IT Happen, one build at a time, 600 times a day

-----Original Message-----
From: jhumble [mailto:jez@jezhumble.net] 
Sent: Monday, November 08, 2010 6:54 PM
To: users@maven.apache.org
Subject: Re: Continuous Delivery and Maven


>
> My mantra is this, if you are feeling pain in your process, do it more

> often which should force you to either solve the problem or realize 
> it's upstream.


That is one of my 8 principles of CD ("If It Hurts, Do It More
Frequently, and Bring the Pain Forward" - p26). And I think it applies
to integrating modules too.


> You're trying to solve a two-sided jello view of a system at build 
> time, perhaps what you need is to refactor you architecture (and why 
> SaaS, Cloud and federated systems lend themselves to CD). Maven is 
> your pain point but I say you're just not doing it right.
>

We can both play that game, but it's not very productive. I respect the
fact that you have a bunch of experience and that you've created a
process that works great for you, and I am not suggesting you change it.
Hard as it may be to believe, I have had many experiences that point me
in exactly the opposite direction, also working for organizations that
make "our little
A->B->C game" seem trivial.

So, after we *find something valuable* we can release it trivially.
>

And I think this is the nub of the problem - you don't have a
sufficiently frequent release cycle to experience the problems I am
describing.

--
Jez Humble
Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
http://continuousdelivery.com/ http://jezhumble.net/

--
View this message in context:
http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370
p3256015.html
Sent from the Maven - Users mailing list archive at Nabble.com.

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[jhumble <je...@jezhumble.net>]

>
> My mantra is this, if you are feeling pain in your process, do it more
> often which should force you to either solve the problem or realize it's
> upstream.


That is one of my 8 principles of CD ("If It Hurts, Do It More Frequently,
and Bring the Pain Forward" - p26). And I think it applies to integrating
modules too.


> You're trying to solve a two-sided jello view of a system at
> build time, perhaps what you need is to refactor you architecture (and
> why SaaS, Cloud and federated systems lend themselves to CD). Maven is
> your pain point but I say you're just not doing it right.
>

We can both play that game, but it's not very productive. I respect the fact
that you have a bunch of experience and that you've created a process that
works great for you, and I am not suggesting you change it. Hard as it may
be to believe, I have had many experiences that point me in exactly the
opposite direction, also working for organizations that make "our little
A->B->C game" seem trivial.

So, after we *find something valuable* we can release it trivially.
>

And I think this is the nub of the problem - you don't have a sufficiently
frequent release cycle to experience the problems I am describing.

--
Jez Humble
Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
http://continuousdelivery.com/
http://jezhumble.net/

-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3256015.html
Sent from the Maven - Users mailing list archive at Nabble.com.

RE: Continuous Delivery and Maven

["Yanko, Curtis" <cu...@uhc.com>]

I think our fundamental schism is that you see managing POM's as too
hard where as I see them as so easy and a no brainer when it comes to
ROI especially considering the alternatives.

We have plenty of initiatives that span system boundaries but those need
to be addressed in architecture and not CI systems.

My mantra is this, if you are feeling pain in your process, do it more
often which should force you to either solve the problem or realize it's
upstream. You're trying to solve a two-sided jello view of a system at
build time, perhaps what you need is to refactor you architecture (and
why SaaS, Cloud and federated systems lend themselves to CD). Maven is
your pain point but I say you're just not doing it right.

I have projects with enough internal modules to exhaust the alphabet in
our little A->B->C game. Then there is twice as many more 3rd party
libraries often times with conflicting transient dependencies of their
own. The level of complexity is really quite astounding imo. But, thanks
to maven we can think in terms of technology stacks reducing 50
dependencies into just a handful of high level components. *Managing*
our POMs has been streamlined in such a way that they are very easy to
manage. And yes, there are times when I have to touch that whole
alphabets of POM but you know what, that's why someone solved the
general problem with find-n-replace, followed by one atomic commit.

So, after we *find something valuable* we can release it trivially.

________________________________

Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
Making IT Happen, one build at a time, 600 times a day

-----Original Message-----
From: jhumble [mailto:jez@jezhumble.net] 
Sent: Monday, November 08, 2010 3:40 PM
To: users@maven.apache.org
Subject: Re: Continuous Delivery and Maven


>
> Only my stuff can be a SNAPSHOT and it is either all a snapshot or it 
> is not. So, if B & C are mine it's not an issue, if they belong to 
> some one else's, they can't be SNAPSHOTs, it's that simple. I can even

> use the enforcer to ensure there isn't a SNAPSHOT set anywhere as part

> of the inspection process.
>

This goes back to my original example. In large development teams it is
very common for different groups to work on different modules which must
all be integrated together for the application to work. In those
situations it is common for all of the modules to change quite
regularly. As a result, you want each of those teams to use snapshots
because it's too painful to be always creating new release versions and
update the pom files by hand.

But you also don't want to throw away the testing you do with those
snapshots.

This is what motivates the idea of including enough metadata with the
snapshots so that the binaries can ultimately be released *if required.*


>  We release by changing one entry in one POM and all of our stuff gets

> versioned, built and released. Repeat the process and everything is 
> back to the next SNAPSHOT so we can resume changing things. It seems 
> it is this one discreet activity that CD abhors. You want to defer it 
> to after the fact which doesn't seem any different than what Stephen 
> suggested by waiting for CI feedback and then trigger a CD build. I 
> don't get what event prompts you to wan to go back and reproduce a 
> build to be a release?
>

But if you are continuously integrating the modules, which you should be
(CI applies at the module level, not just at the code level), then you'd
be changing the POMs *all the time*.


> The ours vs. theirs problem exist for your plugin scenario too. Sure 
> you've created a synthetic POM but have they? If B & C's  development 
> is in fact decoupled from yours, why would they? How would they know? 
> If they didn't make one and in turn are using SNAPSHOT deps themselves

> then you're hosed and your problem is spiraling in complexity.
>

If creating the extra metadata is built in to the tool, then we ensure
that everybody has the pom with the extra metadata and there isn't a
problem.
Anyone who doesn't need it can ignore it.


> If your goal is to change anything anywhere at anytime and still 
> deliver any of it, good luck.


No, that's absolutely not my goal. I want to make what I think is a very
simple change to the way Maven works so that people can carry on with
their existing methodology, but incrementally create a full deployment
pipeline too if they find it to be valuable.

--
Jez Humble
Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
http://continuousdelivery.com/ http://jezhumble.net/

--
View this message in context:
http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370
p3255726.html
Sent from the Maven - Users mailing list archive at Nabble.com.

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[jhumble <je...@jezhumble.net>]

>
> Only my stuff can be a SNAPSHOT and it is either all a snapshot or it is
> not. So, if B & C are mine it's not an issue, if they belong to some one
> else's, they can't be SNAPSHOTs, it's that simple. I can even use the
> enforcer to ensure there isn't a SNAPSHOT set anywhere as part of the
> inspection process.
>

This goes back to my original example. In large development teams it is very
common for different groups to work on different modules which must all be
integrated together for the application to work. In those situations it is
common for all of the modules to change quite regularly. As a result, you
want each of those teams to use snapshots because it's too painful to be
always creating new release versions and update the pom files by hand.

But you also don't want to throw away the testing you do with those
snapshots.

This is what motivates the idea of including enough metadata with the
snapshots so that the binaries can ultimately be released *if required.*


>  We release by changing one entry in one POM and all of our stuff gets
> versioned, built and released. Repeat the process and everything is back
> to the next SNAPSHOT so we can resume changing things. It seems it is
> this one discreet activity that CD abhors. You want to defer it to after
> the fact which doesn't seem any different than what Stephen suggested by
> waiting for CI feedback and then trigger a CD build. I don't get what
> event prompts you to wan to go back and reproduce a build to be a
> release?
>

But if you are continuously integrating the modules, which you should be (CI
applies at the module level, not just at the code level), then you'd be
changing the POMs *all the time*.


> The ours vs. theirs problem exist for your plugin scenario too. Sure
> you've created a synthetic POM but have they? If B & C's  development is
> in fact decoupled from yours, why would they? How would they know? If
> they didn't make one and in turn are using SNAPSHOT deps themselves then
> you're hosed and your problem is spiraling in complexity.
>

If creating the extra metadata is built in to the tool, then we ensure that
everybody has the pom with the extra metadata and there isn't a problem.
Anyone who doesn't need it can ignore it.


> If your goal is to change anything anywhere at anytime and still deliver
> any of it, good luck.


No, that's absolutely not my goal. I want to make what I think is a very
simple change to the way Maven works so that people can carry on with their
existing methodology, but incrementally create a full deployment pipeline
too if they find it to be valuable.

-- 
Jez Humble
Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
http://continuousdelivery.com/
http://jezhumble.net/

-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3255726.html
Sent from the Maven - Users mailing list archive at Nabble.com.

Re: Continuous Delivery and Maven

[Justin Edelson <ju...@justinedelson.com>]

I've been following this thread with some confusion... if you want to
use CD with Maven, why can't you just use the release plugin and cut a
release on every commit? In other words, if your CI configuration
currently runs 'mvn clean install', instead have it run 'mvn -B clean
release:prepare release:perform'

I'm obviously missing something significant, because this seems too
simple a solution.

Justin

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Thiessen, Todd (Todd)" <tt...@avaya.com>]

.
> >
> > I think it is crucial that the release artifact DOES get rebuilt.
> 
> 
> I think that exactly the opposite is true

I know you "think" that. You're beating a dead horse. But that isn't the point here. It is crucial for Maven that it gets rebuilt. It is simply the way Maven is architected. Little to do with what I or you want or think.  That just a simple fact I think you will need to accept.

I think is time to move on. I think you have enough feedback to try and get what you want working with a plugin or whatever. Best way to learn is to do.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[jhumble <je...@jezhumble.net>]

OK this is great - I think we're on the same page now.


> And I am pretty sure that the community in general is not really in favor
> of this kind of massaging of the artifacts from snapshot -> release. It
> invalidates your testing of said snapshot.
>
> I think it is crucial that the release artifact DOES get rebuilt.


I think that exactly the opposite is true - if you recreate the release
artifact, it invalidates your testing of the snapshot, because by definition
you're releasing something different from what you've tested. Worse, because
Maven doesn't currently include that metadata, it might well actually be a
different binary!


> > That would be great, and the obvious place would be in MANIFEST.MF, but
> > the
> > format isn't rich enough to store all the information we'd need.
>
> What would be missing? Your pom says your using artifact 1.0-SNAPSHOT.jar.
> You go and find that jar, open it and find what revision. Do that for all
> snapshot jars you depend on.
>

But I want to know what versions of the upstream jars were that I built my
snapshot against too.


> The second is that maven would have to query this information during a
> build, and then update it own "extra information.xml file" to update its
> transtitive dependency information list and then deploy that list to the
> repository as well. And this would need to be a complete list of all
> transtive dependencies, not just direct ones. So now you can download that
> file, figure out what revision of all your transitive deps are and recreate
> the entire build.
>

Exactly.

Now how would this work if a project has release and snapshot dependencies?
> I think you would only need to do this for snapshot deps.
>

Well for release dependencies you already specify the exact version number
you depend on, so it doesn't matter, right?

Thanks,

Jez.

-- 
Jez Humble
Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
http://continuousdelivery.com/
http://jezhumble.net/

-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3256025.html
Sent from the Maven - Users mailing list archive at Nabble.com.

Re: Continuous Delivery and Maven

[jmorrow <jo...@morrowmail.com>]

stephenconnolly wrote:
> 
> Well I regard that the project being delivered can only have internal
> -SNAPSHOT dependencies, all external (to the reactor) dependencies
> should be release dependencies.
> 
> One of the things I have wanted to do with v-m-p is to hack around
> version ranges... for example...
> 

Couldn't you use v-m-p to update the versions prior to running the release?
(Going down this road we would never have snapshot dependencies)
mvn versions:use-latest-versions release:prepare release:perform

or set it as a preparation goal.

This would update all versions to latest and checkin when done.

Developers could execute this prior to clean install to always be using the
latest stuff.

In fact you could also attach this to the validate phase so the goal does
not have to be specified.

-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3259395.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[rpomeroy <rp...@me.com>]

jhumble wrote:
> 
>>
> [snip snip]
> That would be great, and the obvious place would be in MANIFEST.MF, but
> the
> format isn't rich enough to store all the information we'd need. Another
> possibility would be to create a custom maven XML extension file inside
> META-INF.
> [snip snip]
> 

I thought it worth mentioning that OSGi extends (in a compliant way) the
MANIFEST.MF to store very fine-grained transitive dependency information
(versioned java package level import/export expressions).  Tycho (the Maven
that builds OSGi bundles) is currently using this metadata for dependency
resolution - so I wouldn't assume the manifest wouldn't work.  A minor point
in the grand scheme of this discussion - I'll grant that :-).

Ron

-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3256034.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Yanko, Curtis" <cu...@uhc.com>]

 
What you're proposing is indeed interesting. But you do seem to pick and
choose what you want (reproducibility) and what you can dispense with
(tags and branches).

I'm just saying, that as a practical matter, we can today solve your
problem without the need for a new plugin. Reproducible, and Auditable.
I can look at anything directly, even in Prod, and make the leap all the
way to SVN without a single cross reference or lookup because we put all
that meta-data in the manifest, just not in the POM (in your scenario,
in ours the POM has everything listed as a version though so we don't
face the SNAPSHOT issue).

You want to be able to Audit but eschew documentation like a Site
reports? Again seems sort of cake-and-eat-it-too to me. Are you managing
Technical Debt at all? Are you tracking who consumes what so you can do
an impact analysis later?

________________________________

Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
Making IT Happen, one build at a time, 600 times a day

-----Original Message-----
From: jhumble [mailto:jez@jezhumble.net] 
Sent: Monday, November 08, 2010 12:46 PM
To: users@maven.apache.org
Subject: Re: Continuous Delivery and Maven


Right - but I don't want to rely on the build logs or the site report, I
want the bill of materials in an easily accessible and simple format
that Maven itself can understand - for example in the pom file
associated with the snapshot.

In particular, I want to be able to point the Maven release plug-in at
the snapshot's pom and run a command which does all the kind of tagging
stuff that the release plug-in does, but that doesn't need to reproduce
the binary (except to verify that it's identical to the snapshot). I'd
also want to be able to create the site report automatically from the
snapshot's pom.

I don't ever need to re-produce it because I have it and am managing the
> binary


Except that I do want to keep the ability to blow away the binaries and
know I can re-create them, especially when I'm running multiple builds
per day.

More importantly, it's essential for auditing purposes that we can trace
back from any given binary to the exact versions in version control that
it and all its build-time dependencies came from.

On 8 November 2010 09:34, Yanko, Curtis [via Maven] <
ml-node+3255434-1467695194-143561@n5.nabble.com<ml-node%2B3255434-146769
ml-node+5194-143561@n5.nabble.com>
> wrote:

> Thanks,
>
> I did manage to find it too. Not sure I follow his logic though.
>
>    "One of the things I like about snapshots is it just simply means 
> "latest".  Though the thing about timestamped snapshots is that they 
> aren't guaranteed to exist (the repository is not typically assumed to

> be reliable), and they aren't 100% reproducible (the timestamp offset 
> includes the time it took to build the artifact and all the artifacts 
> before it, meaning there's no way to know exactly what point in time 
> the build came from).  Even if one could find the correct timestamp to

> check out from to get the same binary, whatever subsystem creates the 
> timestamp on upload (wagon?) probably doesn't like being told what to 
> call the snapshot."
>
> If I build a SNAPSHOT and deploy it to an internal Maven Repo it will 
> be given a unique identifier based on a time stamp (repo configured to

> do this). Why is that not guaranteed to exist or be reliable? And at 
> the moment I build A the build log will tell me exactly which SNAPSHOT

> we received. I don't ever need to re-produce it because I have it and 
> am managing the binary but... I can crack it open and see exactly 
> which SCC revision was used and which path within the SCC it came from

> (because we bake that info into everything we build). So I can 
> reproduce it in a pinch. What's also missing from the conversation is 
> the final assembly where A,B and C get put together for deployment 
> which is also managed as a binary and represents the 
> bill-of-materials. And of course my Maven Site report for A would have
documented which B & C I had too.
>
> ________________________________
>
> Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
> Making IT Happen, one build at a time, 600 times a day
>
> -----Original Message-----
> From: jhumble [mailto:[hidden 
> email]<http://user/SendEmail.jtp?type=node&node=3255434&i=0>]
>
> Sent: Monday, November 08, 2010 12:11 PM
> To: [hidden email] 
> <http://user/SendEmail.jtp?type=node&node=3255434&i=1>
> Subject: Re: Continuous Delivery and Maven
>
>
> Hi Curt - it was this one:
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32453
> 70<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32
> 45370?by-user=t>
> p3254439.html
>
> On 8 November 2010 09:07, Yanko, Curtis [via Maven] < [hidden email] 
> <http://user/SendEmail.jtp?type=node&node=3255434&i=2><ml-node%2B32553
> 82-1751046
>
> [hidden email] <http://user/SendEmail.jtp?type=node&node=3255434&i=3>>
> > wrote:
>
> >
> > I didn't see a reply from a Brian. What answer did he provided that 
> > answered your question?
> >
> > ________________________________
> >
> > Curt Yanko | Continuous Integration Services | UnitedHealth Group IT

> > Making IT Happen, one build at a time, 600 times a day
> >
> > -----Original Message-----
> > From: jhumble [mailto:[hidden
> > email]<http://user/SendEmail.jtp?type=node&node=3255382&i=0>]
> >
> > Sent: Monday, November 08, 2010 11:58 AM
> > To: [hidden email]
> > <http://user/SendEmail.jtp?type=node&node=3255382&i=1>
> > Subject: Re: Continuous Delivery and Maven
> >
> >
> > Todd, I have read all of your posts and I have come to the 
> > conclusion that you're missing the point of CD. I was really hoping 
> > to avoid an argument about process, because I just want to work out 
> > what needs to be done to Maven to make it support CD, and that's 
> > already a big enough discussion for one thread. However since the 
> > thread has (perhaps
> > inevitably) been taken over by a discussion about what continuous 
> > delivery is, I will add my 1c. In any case I think I have what I 
> > need from the discussion with Brian.
> >
> > With CD, the software is *always* production ready, right from the 
> > start of the project. Any work of any kind that doesn't result in a 
> > deployable build is waste.
> >
> > If you are at the start of a release, your product owner will have a

> > good
> > > idea of how much content needs to get to the customer to fullfill 
> > > that
> >
> > > release. Doing CD through the entire lifecycle is largely a waste
> > IMHO.
> >
> >
> > Wrong. In fact, it's the opposite - any work that doesn't keep the 
> > software in a deployable, releasable state is waste, because you 
> > can't
>
> > know whether or not the work you have done is actually useful, or 
> > even
>
> > whether it keeps the software working. And you can't know whether or

> > not the software is working - i.e. whether or not the build can be 
> > deployed
> > - until it has passed end-to-end acceptance tests under realistic 
> > loads in a production-like environment.
> >
> > I am fine with you using the process you describe. If it works for 
> > you, that's great. But please don't call it continuous delivery - it
> isn't.
>
> >
> > Now, assuming we are working in a cd process, the crucial thing is 
> > that we don't waste any cycles creating a build that couldn't be 
> > released. We then take this binary and put it through the rest of 
> > the deployment pipeline (or build life or whatever you want to call
it).
> > But crucially, we don't want to recreate the binary later on. If you

> > want more detail on the mechanics of how it works, you can read the 
> > free chapter from my book here:
> > http://www.informit.com/articles/article.aspx?p=1621865
> >
> > *What I want from Maven*
> > *===================*
> >
> > We want the simplicity of snapshots with the traceability of proper 
> > releases. So I think from what Brian said, I'd like the the Maven 
> > snapshot build process to create enough metadata in the pom file 
> > such that when you ran the release plugin, it wouldn't be necessary 
> > for it to rebuild the artifact - it could just do the various bits 
> > of tagging
>
> > and metadata creation using the information in the pom associated 
> > with
>
> > the snapshot. We might also want the release plugin to try and 
> > recreate the binary using its process and verify the md5 is the same

> > as the md5 of the snapshot.
> >
> > If anybody has any feedback on this hypothesis, I'd be very
grateful.
> >
> > Thanks,
> >
> > Jez.
> >
> > On 8 November 2010 08:49, Thiessen, Todd (Todd) [via Maven] < 
> > [hidden email]
> > <http://user/SendEmail.jtp?type=node&node=3255382&i=2><ml-node%2B325
> > 53
> > 36-196234
> >
> > [hidden email] 
> > <http://user/SendEmail.jtp?type=node&node=3255382&i=3>>
> > > wrote:
> >
> > > > I'm thinking tha Ci wouldn't be affected at all, CD still 
> > > > requires
>
> > > > Ci as a quality metric preventing deployment to the customer.
> > >
> > > I am curious to see that. Or how it would work. How do you put in 
> > > fixed release numbers into a CD build and then switch back to CI 
> > > building? And I can only imagine it being quite complex.
> > >
> > > The only thing I can think of is something like:
> > >
> > > 1. CI build produces 1.0-SNAPSHOT
> > > 2. CD build produces 1.0-01
> > > 3. CD build reverts source back to 1.0-SNAPSHOT 4. Repeat
> > >
> > >
> > > ------------------------------------------------------------------
> > > --
> > > -
> > > To unsubscribe, e-mail: [hidden
> > email]<http://user/SendEmail.jtp?type=node&node=3255336&i=0>
> > > For additional commands, e-mail: [hidden
> > email]<http://user/SendEmail.jtp?type=node&node=3255336&i=1>
> > >
> > >
> > >
> > > ------------------------------
> > >  View message @
> > >
> > http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp324
> > 53<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp
> > 32453?by-user=t> 
> > 70<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp
> > 32<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp
> > 32?by-user=t>
> > 45370?by-user=t>
> > p3255336.html
> > > To unsubscribe from Continuous Delivery and Maven, click
> > here<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=un
> > su<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsu
> > &by-user=t> 
> > bs<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsu
> > bs<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsu
> > bs&by-user=t>
> > &by-user=t>
> > cribe_by_code&node=3245370&code=amV6QGplemh1bWJsZS5uZXR8MzI0NTM3MHwt
> > MT
> > g4
> > MjM1NzMyNA==>.
> > >
> > >
> > >
> >
> >
> > --
> > Jez Humble
> > Co-author, *Continuous Delivery <http://continuousdelivery.com/>* 
> > http://continuousdelivery.com/ http://jezhumble.net/
> >
> > --
> > View this message in context:
> > http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp324
> > 53<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp
> > 32453?by-user=t> 
> > 70<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp
> > 32<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp
> > 32?by-user=t>
> > 45370?by-user=t>
> > p3255361.html
> > Sent from the Maven - Users mailing list archive at Nabble.com.
> >
> > This e-mail, including attachments, may include confidential and/or 
> > proprietary information, and may be used only by the person or 
> > entity to which it is addressed. If the reader of this e-mail is not

> > the intended recipient or his or her authorized agent, the reader is

> > hereby notified that any dissemination, distribution or copying of 
> > this e-mail is prohibited. If you have received this e-mail in 
> > error, please notify the sender by replying to this message and 
> > delete this
> e-mail immediately.
>
> >
> >
> > --------------------------------------------------------------------
> > -
> > To unsubscribe, e-mail: [hidden
> > email]<http://user/SendEmail.jtp?type=node&node=3255382&i=4>
> > For additional commands, e-mail: [hidden 
> > email]<http://user/SendEmail.jtp?type=node&node=3255382&i=5>
> >
> >
> >
> > ------------------------------
> >  View message @
> > http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp324
> > 53<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp
> > 32453?by-user=t> 70p3255382.html To unsubscribe from Continuous 
> > Delivery and Maven, click
> here<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsu
> bs<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubs
> &by-user=t>
> cribe_by_code&node=3245370&code=amV6QGplemh1bWJsZS5uZXR8MzI0NTM3MHwtMT
> g4
> MjM1NzMyNA==>.
> >
> >
> >
>
>
> --
> Jez Humble
> Co-author, *Continuous Delivery <http://continuousdelivery.com/>* 
> http://continuousdelivery.com/ http://jezhumble.net/
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32453
> 70<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32
> 45370?by-user=t>
> p3255387.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> This e-mail, including attachments, may include confidential and/or 
> proprietary information, and may be used only by the person or entity 
> to which it is addressed. If the reader of this e-mail is not the 
> intended recipient or his or her authorized agent, the reader is 
> hereby notified that any dissemination, distribution or copying of 
> this e-mail is prohibited. If you have received this e-mail in error, 
> please notify the sender by replying to this message and delete this
e-mail immediately.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden 
> email]<http://user/SendEmail.jtp?type=node&node=3255434&i=4>
> For additional commands, e-mail: [hidden 
> email]<http://user/SendEmail.jtp?type=node&node=3255434&i=5>
>
>
>
> ------------------------------
>  View message @
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32453
> 70p3255434.html To unsubscribe from Continuous Delivery and Maven, 
> click
here<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubs
cribe_by_code&node=3245370&code=amV6QGplemh1bWJsZS5uZXR8MzI0NTM3MHwtMTg4
MjM1NzMyNA==>.
>
>
>


--
Jez Humble
Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
http://continuousdelivery.com/ http://jezhumble.net/

--
View this message in context:
http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370
p3255456.html
Sent from the Maven - Users mailing list archive at Nabble.com.

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[jhumble <je...@jezhumble.net>]

Right - but I don't want to rely on the build logs or the site report, I
want the bill of materials in an easily accessible and simple format that
Maven itself can understand - for example in the pom file associated with
the snapshot.

In particular, I want to be able to point the Maven release plug-in at the
snapshot's pom and run a command which does all the kind of tagging stuff
that the release plug-in does, but that doesn't need to reproduce the binary
(except to verify that it's identical to the snapshot). I'd also want to be
able to create the site report automatically from the snapshot's pom.

I don't ever need to re-produce it because I have it and am managing the
> binary


Except that I do want to keep the ability to blow away the binaries and know
I can re-create them, especially when I'm running multiple builds per day.

More importantly, it's essential for auditing purposes that we can trace
back from any given binary to the exact versions in version control that it
and all its build-time dependencies came from.

On 8 November 2010 09:34, Yanko, Curtis [via Maven] <
ml-node+3255434-1467695194-143561@n5.nabble.com<ml...@n5.nabble.com>
> wrote:

> Thanks,
>
> I did manage to find it too. Not sure I follow his logic though.
>
>    "One of the things I like about snapshots is it just simply means
> "latest".  Though the thing about timestamped snapshots is that they
> aren't guaranteed to exist (the repository is not typically assumed to
> be reliable), and they aren't 100% reproducible (the timestamp offset
> includes the time it took to build the artifact and all the artifacts
> before it, meaning there's no way to know exactly what point in time the
> build came from).  Even if one could find the correct timestamp to check
> out from to get the same binary, whatever subsystem creates the
> timestamp on upload (wagon?) probably doesn't like being told what to
> call the snapshot."
>
> If I build a SNAPSHOT and deploy it to an internal Maven Repo it will be
> given a unique identifier based on a time stamp (repo configured to do
> this). Why is that not guaranteed to exist or be reliable? And at the
> moment I build A the build log will tell me exactly which SNAPSHOT we
> received. I don't ever need to re-produce it because I have it and am
> managing the binary but... I can crack it open and see exactly which SCC
> revision was used and which path within the SCC it came from (because we
> bake that info into everything we build). So I can reproduce it in a
> pinch. What's also missing from the conversation is the final assembly
> where A,B and C get put together for deployment which is also managed as
> a binary and represents the bill-of-materials. And of course my Maven
> Site report for A would have documented which B & C I had too.
>
> ________________________________
>
> Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
> Making IT Happen, one build at a time, 600 times a day
>
> -----Original Message-----
> From: jhumble [mailto:[hidden email]<http://user/SendEmail.jtp?type=node&node=3255434&i=0>]
>
> Sent: Monday, November 08, 2010 12:11 PM
> To: [hidden email] <http://user/SendEmail.jtp?type=node&node=3255434&i=1>
> Subject: Re: Continuous Delivery and Maven
>
>
> Hi Curt - it was this one:
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370?by-user=t>
> p3254439.html
>
> On 8 November 2010 09:07, Yanko, Curtis [via Maven] <
> [hidden email] <http://user/SendEmail.jtp?type=node&node=3255434&i=2><ml-node%2B3255382-1751046
>
> [hidden email] <http://user/SendEmail.jtp?type=node&node=3255434&i=3>>
> > wrote:
>
> >
> > I didn't see a reply from a Brian. What answer did he provided that
> > answered your question?
> >
> > ________________________________
> >
> > Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
> > Making IT Happen, one build at a time, 600 times a day
> >
> > -----Original Message-----
> > From: jhumble [mailto:[hidden
> > email]<http://user/SendEmail.jtp?type=node&node=3255382&i=0>]
> >
> > Sent: Monday, November 08, 2010 11:58 AM
> > To: [hidden email]
> > <http://user/SendEmail.jtp?type=node&node=3255382&i=1>
> > Subject: Re: Continuous Delivery and Maven
> >
> >
> > Todd, I have read all of your posts and I have come to the conclusion
> > that you're missing the point of CD. I was really hoping to avoid an
> > argument about process, because I just want to work out what needs to
> > be done to Maven to make it support CD, and that's already a big
> > enough discussion for one thread. However since the thread has
> > (perhaps
> > inevitably) been taken over by a discussion about what continuous
> > delivery is, I will add my 1c. In any case I think I have what I need
> > from the discussion with Brian.
> >
> > With CD, the software is *always* production ready, right from the
> > start of the project. Any work of any kind that doesn't result in a
> > deployable build is waste.
> >
> > If you are at the start of a release, your product owner will have a
> > good
> > > idea of how much content needs to get to the customer to fullfill
> > > that
> >
> > > release. Doing CD through the entire lifecycle is largely a waste
> > IMHO.
> >
> >
> > Wrong. In fact, it's the opposite - any work that doesn't keep the
> > software in a deployable, releasable state is waste, because you can't
>
> > know whether or not the work you have done is actually useful, or even
>
> > whether it keeps the software working. And you can't know whether or
> > not the software is working - i.e. whether or not the build can be
> > deployed
> > - until it has passed end-to-end acceptance tests under realistic
> > loads in a production-like environment.
> >
> > I am fine with you using the process you describe. If it works for
> > you, that's great. But please don't call it continuous delivery - it
> isn't.
>
> >
> > Now, assuming we are working in a cd process, the crucial thing is
> > that we don't waste any cycles creating a build that couldn't be
> > released. We then take this binary and put it through the rest of the
> > deployment pipeline (or build life or whatever you want to call it).
> > But crucially, we don't want to recreate the binary later on. If you
> > want more detail on the mechanics of how it works, you can read the
> > free chapter from my book here:
> > http://www.informit.com/articles/article.aspx?p=1621865
> >
> > *What I want from Maven*
> > *===================*
> >
> > We want the simplicity of snapshots with the traceability of proper
> > releases. So I think from what Brian said, I'd like the the Maven
> > snapshot build process to create enough metadata in the pom file such
> > that when you ran the release plugin, it wouldn't be necessary for it
> > to rebuild the artifact - it could just do the various bits of tagging
>
> > and metadata creation using the information in the pom associated with
>
> > the snapshot. We might also want the release plugin to try and
> > recreate the binary using its process and verify the md5 is the same
> > as the md5 of the snapshot.
> >
> > If anybody has any feedback on this hypothesis, I'd be very grateful.
> >
> > Thanks,
> >
> > Jez.
> >
> > On 8 November 2010 08:49, Thiessen, Todd (Todd) [via Maven] < [hidden
> > email]
> > <http://user/SendEmail.jtp?type=node&node=3255382&i=2><ml-node%2B32553
> > 36-196234
> >
> > [hidden email] <http://user/SendEmail.jtp?type=node&node=3255382&i=3>>
> > > wrote:
> >
> > > > I'm thinking tha Ci wouldn't be affected at all, CD still requires
>
> > > > Ci as a quality metric preventing deployment to the customer.
> > >
> > > I am curious to see that. Or how it would work. How do you put in
> > > fixed release numbers into a CD build and then switch back to CI
> > > building? And I can only imagine it being quite complex.
> > >
> > > The only thing I can think of is something like:
> > >
> > > 1. CI build produces 1.0-SNAPSHOT
> > > 2. CD build produces 1.0-01
> > > 3. CD build reverts source back to 1.0-SNAPSHOT 4. Repeat
> > >
> > >
> > > --------------------------------------------------------------------
> > > -
> > > To unsubscribe, e-mail: [hidden
> > email]<http://user/SendEmail.jtp?type=node&node=3255336&i=0>
> > > For additional commands, e-mail: [hidden
> > email]<http://user/SendEmail.jtp?type=node&node=3255336&i=1>
> > >
> > >
> > >
> > > ------------------------------
> > >  View message @
> > >
> > http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32453<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32453?by-user=t>
> > 70<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32?by-user=t>
> > 45370?by-user=t>
> > p3255336.html
> > > To unsubscribe from Continuous Delivery and Maven, click
> > here<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsu<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsu&by-user=t>
> > bs<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubs<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubs&by-user=t>
> > &by-user=t>
> > cribe_by_code&node=3245370&code=amV6QGplemh1bWJsZS5uZXR8MzI0NTM3MHwtMT
> > g4
> > MjM1NzMyNA==>.
> > >
> > >
> > >
> >
> >
> > --
> > Jez Humble
> > Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
> > http://continuousdelivery.com/ http://jezhumble.net/
> >
> > --
> > View this message in context:
> > http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32453<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32453?by-user=t>
> > 70<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32?by-user=t>
> > 45370?by-user=t>
> > p3255361.html
> > Sent from the Maven - Users mailing list archive at Nabble.com.
> >
> > This e-mail, including attachments, may include confidential and/or
> > proprietary information, and may be used only by the person or entity
> > to which it is addressed. If the reader of this e-mail is not the
> > intended recipient or his or her authorized agent, the reader is
> > hereby notified that any dissemination, distribution or copying of
> > this e-mail is prohibited. If you have received this e-mail in error,
> > please notify the sender by replying to this message and delete this
> e-mail immediately.
>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden
> > email]<http://user/SendEmail.jtp?type=node&node=3255382&i=4>
> > For additional commands, e-mail: [hidden
> > email]<http://user/SendEmail.jtp?type=node&node=3255382&i=5>
> >
> >
> >
> > ------------------------------
> >  View message @
> > http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32453<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32453?by-user=t>
> > 70p3255382.html To unsubscribe from Continuous Delivery and Maven,
> > click
> here<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubs<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubs&by-user=t>
> cribe_by_code&node=3245370&code=amV6QGplemh1bWJsZS5uZXR8MzI0NTM3MHwtMTg4
> MjM1NzMyNA==>.
> >
> >
> >
>
>
> --
> Jez Humble
> Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
> http://continuousdelivery.com/ http://jezhumble.net/
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370?by-user=t>
> p3255387.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> This e-mail, including attachments, may include confidential and/or
> proprietary information, and may be used only by the person or entity
> to which it is addressed. If the reader of this e-mail is not the intended
> recipient or his or her authorized agent, the reader is hereby notified
> that any dissemination, distribution or copying of this e-mail is
> prohibited. If you have received this e-mail in error, please notify the
> sender by replying to this message and delete this e-mail immediately.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3255434&i=4>
> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3255434&i=5>
>
>
>
> ------------------------------
>  View message @
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3255434.html
> To unsubscribe from Continuous Delivery and Maven, click here<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_code&node=3245370&code=amV6QGplemh1bWJsZS5uZXR8MzI0NTM3MHwtMTg4MjM1NzMyNA==>.
>
>
>


-- 
Jez Humble
Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
http://continuousdelivery.com/
http://jezhumble.net/

-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3255456.html
Sent from the Maven - Users mailing list archive at Nabble.com.

RE: Continuous Delivery and Maven

[jmorrow <jo...@morrowmail.com>]

Certainly and I would promote that the solution using this mechanism should
allow a rang eto be specified. In a true CD shop though I think it would be
important the you could leave the upper bound off. It seems both are
supported so it is all good.
-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3259400.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Dual javadoc

[jmorrow <jo...@morrowmail.com>]

You might get a better/faster answer if you posted your own thread for this
issue.
-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3260352.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Yanko, Curtis" <cu...@uhc.com>]

 Obviously there are times when that is the case but and others when the
boundary would be welcome.

-----Original Message-----
From: Thiessen, Todd (Todd) [mailto:tthiessen@avaya.com] 
Sent: Wednesday, November 10, 2010 2:54 PM
To: Maven Users List
Subject: RE: Continuous Delivery and Maven

I don't think you need to specify a top end. For example, you could use
[1.0,).

http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-se
ct-version-ranges.html


________________________________

Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
Making IT Happen, one build at a time, 600 times a day

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Thiessen, Todd (Todd)" <tt...@avaya.com>]

I don't think you need to specify a top end. For example, you could use [1.0,).

http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-version-ranges.html


> -----Original Message-----
> From: jmorrow [mailto:jon@morrowmail.com]
> Sent: Wednesday, November 10, 2010 2:51 PM
> To: users@maven.apache.org
> Subject: RE: Continuous Delivery and Maven
> 
> 
> 
> Thiessen, Todd (Todd) wrote:
> >
> > Is LATEST deprecate now?
> >
> > But if I recall correctly, I don't think it would be quite right either
> as
> > LATEST implies the latest release or snapshot. So you'll want to be
> > careful here.
> >
> 
> https://cwiki.apache.org/MAVEN/maven-3x-compatibility-
> notes.html#Maven3.xCompatibilityNotes-PluginMetaversionResolution
> 
> You are correct it is depricated as of 3.x. It has generally been thought
> of
> as bad practice to use latest as you never really knew what version you
> were
> dependent on and for non-CD approaches this makes complete sense. In CD I
> think it embodies exactly what you do want, the latest code that has
> passed
> a certain phase of the pipeline.
> 
> RELEASE would probably be better, but alas it is depricated as well.
> 
> I think it is unfortunate that this was removed from Maven 3 as it was
> valuable in certain circumstances and now that CD is hitting the big time
> it
> would be useful.
> 
> I don't like the idea of specifying the top end of the version range
> becasue
> I am not in control of when the team I am dependent on updates their
> major
> version number. I might not catch the change and continue development
> against old versions, this would effectively render my CI environment
> useless.
> 
> 
> 
> 
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-
> tp3245370p3259341.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Dual javadoc

[Gerard Weatherby <ge...@alum.mit.edu>]

Is there a way to configure the javadoc plugin to generate two sets of 
Javadoc output? We find it convenient to have both  the default public 
and <show>private</show> versions.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Yanko, Curtis" <cu...@uhc.com>]

 The dep ranges make more sense to me because they can equate to
feature/functionality sets and still enable parallel development for all
those non-CD shops ;-)  I'm sure there is no notion of parallel
development in CD since they eschew branches in favor of Bliki feature
toggles (which are pretty cool I must say). Non-CD shops can still
benefit from this since it would further minimize POM management which
everyone seems to abhor.


________________________________

Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
Making IT Happen, one build at a time, 600 times a day

-----Original Message-----
From: jmorrow [mailto:jon@morrowmail.com] 
Sent: Wednesday, November 10, 2010 2:51 PM
To: users@maven.apache.org
Subject: RE: Continuous Delivery and Maven



Thiessen, Todd (Todd) wrote:
> 
> Is LATEST deprecate now?
> 
> But if I recall correctly, I don't think it would be quite right 
> either as LATEST implies the latest release or snapshot. So you'll 
> want to be careful here.
> 

https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.
xCompatibilityNotes-PluginMetaversionResolution

You are correct it is depricated as of 3.x. It has generally been
thought of as bad practice to use latest as you never really knew what
version you were dependent on and for non-CD approaches this makes
complete sense. In CD I think it embodies exactly what you do want, the
latest code that has passed a certain phase of the pipeline.

RELEASE would probably be better, but alas it is depricated as well.

I think it is unfortunate that this was removed from Maven 3 as it was
valuable in certain circumstances and now that CD is hitting the big
time it would be useful.

I don't like the idea of specifying the top end of the version range
becasue I am not in control of when the team I am dependent on updates
their major version number. I might not catch the change and continue
development against old versions, this would effectively render my CI
environment useless.




--
View this message in context:
http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370
p3259341.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

[jmorrow <jo...@morrowmail.com>]

Thiessen, Todd (Todd) wrote:
> 
> Is LATEST deprecate now?
> 
> But if I recall correctly, I don't think it would be quite right either as
> LATEST implies the latest release or snapshot. So you'll want to be
> careful here.
> 

https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-PluginMetaversionResolution

You are correct it is depricated as of 3.x. It has generally been thought of
as bad practice to use latest as you never really knew what version you were
dependent on and for non-CD approaches this makes complete sense. In CD I
think it embodies exactly what you do want, the latest code that has passed
a certain phase of the pipeline.

RELEASE would probably be better, but alas it is depricated as well.

I think it is unfortunate that this was removed from Maven 3 as it was
valuable in certain circumstances and now that CD is hitting the big time it
would be useful.

I don't like the idea of specifying the top end of the version range becasue
I am not in control of when the team I am dependent on updates their major
version number. I might not catch the change and continue development
against old versions, this would effectively render my CI environment
useless.




-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3259341.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Thiessen, Todd (Todd)" <tt...@avaya.com>]

And you're right. You could probably use version ranges for this as Stephen was saying. Then you wouldn't use snapshot deps at all. All projects would simply use the mvn ship command instead of mvn deploy and never work with snapshots.

Make it so ;-). I'd love to see what you have 2 weeks ;-).

> -----Original Message-----
> From: Thiessen, Todd (Todd) [mailto:tthiessen@avaya.com]
> Sent: Wednesday, November 10, 2010 2:24 PM
> To: Maven Users List
> Subject: RE: Continuous Delivery and Maven
> 
> Is LATEST deprecate now?
> 
> But if I recall correctly, I don't think it would be quite right either
> as LATEST implies the latest release or snapshot. So you'll want to be
> careful here.
> 
> > -----Original Message-----
> > From: jmorrow [mailto:jon@morrowmail.com]
> > Sent: Wednesday, November 10, 2010 1:33 PM
> > To: users@maven.apache.org
> > Subject: Re: Continuous Delivery and Maven
> >
> >
> >
> > stephenconnolly wrote:
> > >
> > >
> > > <dependency>
> > >   <groupId>foo</groupId>
> > >   <artifactId>bar</artifactId>
> > >   <version>[1.0,2.0)</version>
> > > </dependency>
> > >
> > >
> >
> > This seems to me to a place where the Maven concept of
> > <version>LATEST</version> actually makes sense to use. If we add around
> > this
> > your concept of writting the concreate version and checking-in, it ott
> > work
> > nicely. With this approach you do not need to keep the meta data of
> what
> > was
> > there previously (although I can see the benefit of supporting the
> > ranges).
> >
> > In a CD environment I'd imagine most of the time you would wnat to be
> > working against the latest released version of all your dependencies.
> >
> > If one wanted to control versions of 3rd party stuff you coul duse your
> > repository manager to lock things down.
> >
> >
> > --
> > View this message in context:
> > http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-
> > tp3245370p3259183.html
> > Sent from the Maven - Users mailing list archive at Nabble.com.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Thiessen, Todd (Todd)" <tt...@avaya.com>]

Is LATEST deprecate now?

But if I recall correctly, I don't think it would be quite right either as LATEST implies the latest release or snapshot. So you'll want to be careful here.

> -----Original Message-----
> From: jmorrow [mailto:jon@morrowmail.com]
> Sent: Wednesday, November 10, 2010 1:33 PM
> To: users@maven.apache.org
> Subject: Re: Continuous Delivery and Maven
> 
> 
> 
> stephenconnolly wrote:
> >
> >
> > <dependency>
> >   <groupId>foo</groupId>
> >   <artifactId>bar</artifactId>
> >   <version>[1.0,2.0)</version>
> > </dependency>
> >
> >
> 
> This seems to me to a place where the Maven concept of
> <version>LATEST</version> actually makes sense to use. If we add around
> this
> your concept of writting the concreate version and checking-in, it ott
> work
> nicely. With this approach you do not need to keep the meta data of what
> was
> there previously (although I can see the benefit of supporting the
> ranges).
> 
> In a CD environment I'd imagine most of the time you would wnat to be
> working against the latest released version of all your dependencies.
> 
> If one wanted to control versions of 3rd party stuff you coul duse your
> repository manager to lock things down.
> 
> 
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-
> tp3245370p3259183.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[jmorrow <jo...@morrowmail.com>]

stephenconnolly wrote:
> 
> 
> <dependency>
>   <groupId>foo</groupId>
>   <artifactId>bar</artifactId>
>   <version>[1.0,2.0)</version>
> </dependency>
> 
> 

This seems to me to a place where the Maven concept of
<version>LATEST</version> actually makes sense to use. If we add around this
your concept of writting the concreate version and checking-in, it ott work
nicely. With this approach you do not need to keep the meta data of what was
there previously (although I can see the benefit of supporting the ranges).

In a CD environment I'd imagine most of the time you would wnat to be
working against the latest released version of all your dependencies.

If one wanted to control versions of 3rd party stuff you coul duse your
repository manager to lock things down.


-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3259183.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[Marcin Kuthan <ma...@gmail.com>]

Hi,

On 2 March 2011 16:25, epabst <ep...@gmail.com> wrote:Hi
> I've put a lot of thought into this because I'm working on designing
> continuous delivery with Maven, Hudson, and Nexus.  Our criteria is this:
>
> - We want to have continuous integration of stable versioned components.
> - We don't want to have noise in the SCM logs.
> - We want builds to be repeatable and traceable.
> - We want it to be easy for developers to work on features without having to
> deal with dependency versions.
> - We want the system to be simple.
> - We want to know what changed between different deployable versions of the
> system.
> - We want to avoid needing to build the same revision of a component twice.
> - We want it to be easy to debug locally against any specific integration
> pipeline build's versions.
>
> This is what I'm thinking:
> Maven:
> - The pom.xml has a SNAPSHOT version and version ranges for its
> dependencies.  In a multi-module project, only the parent pom should have
> the version ranges, and the sub-modules inherit them.

Avoid version ranges, your build won't be repeatable. If 3rd party
breaks backward compatibility between minor versions your build fails.

> - For complicated projects, a dependency-management pom.xml should be used
> which all projects import.  It only has specific versions (not version
> ranges) in its dependencyManagement section.  Each project pom.xml imports
> it using a version range.

You can also create pom type project called bom (bill of materials).
Or put all project dependencies in the dependency management section
in parent pom of project.
http://code.google.com/p/m4enterprise/source/browse/trunk/modular-war/modular-war-parent/pom.xml

> - Use the maven-buildmetadata-plugin to capture the SCM revision and URL in
> each built artifact.

Avoid scm revision for binary to source traceability. Use SCM tags for
tracebility, please refer to the Continous Delivery book for more
details.
Release management with Maven culd be one-click operation, don't worry
with hundreds of tags.

>
> Component Pipeline (e.g. Hudson):
> - The component pipeline replaces "-SNAPSHOT" with
> ".${BUILD_NUMBER}{PADDED_SCM_REVISION}".  The BUILD_NUMBER makes each build
> unique, and the SCM_REVISION is optional but can add traceability.  This
> even works for Git where the revision numbers are not incremental.  This is
> NOT committed to SCM.

Why you don't want follow Maven versioning scheme? I use shapshot
versions only on DEV environment, and due to deployment pipeline after
every commit, the latest version is deployed on DEV. I don't need to
know which revision, it is always the latest. On QA and PROD only
released and tagged versions are deployed.

> - The component pipeline resolves all of the version ranges.  This is NOT
> committed to SCM.
> - The component pipeline runs "mvn clean install"
> - The component pipeline deploys the artifacts to a special "integration"
> Nexus repo only used by the integration pipeline (not component pipelines).
> - The component pipeline triggers the integration pipeline.
>
> Integration Pipeline (e.g. Hudson)
> - The CI server picks component versions (from mvn
> versions:display-property-updates) to try to integrate and triggers an
> integration run for each combination of versions.
> - If using a dependency-management pom, the integration pipeline publishes a
> version of it to the special "integration" Nexus repo.
> - The integration pipeline replaces "-SNAPSHOT" with
> ".${BUILD_NUMBER}{PADDED_SCM_REVISION}".
> - The integration pipeline resolves all of the version ranges.
> - The integration pipeline assembles and packages the deployable artifacts
> using a dedicated maven project using the specified versions as command-line
> version property overrides (e.g. -Dcomponent1.version=1.5.1032212).
> - The integration pipeline deploys to a testing server.
> - The integration pipeline runs acceptance tests.
> - Upon success, the integration pipeline promotes all of the artifacts:
>   - It marks the integration build as promoted.
>   - It promotes original component pipeline CI build (e.g. using Hudson's
> Build Promotion Plugin)
>   - It publishes the artifacts to the main nexus repository.
>   - It creates a tag with the integration build number in the component's
> SCM.
>   - It updates the dependency-management pom with the component versions
> used and commits it to SCM along with a tag with the integration pipeline
> build number.
>   - Promotes any deployable artifacts.

Sorry, but I lost a little bit after this section ;-)

>
> This setup prevents version leakages since all published artifacts have
> specific versions for every dependency.
> This setup allows for developers to develop on trunk and automatically be
> using the latest stable versions of all dependencies.
> It enforces that changes are backward compatible at least relative to the
> promoted downstream usage of the last promoted version of that component.
>
> I think enhancing the versions-maven-plugin to support replacing "-SNAPSHOT"
> with a given string would be helpful.  I am currently using a Scala script
> for this.  Maybe the new goal should also resolve the version ranges, but
> it's not necessary since that is already available as a goal.
>
> I welcome any and all feedback.
>
> Eric Pabst
>
>

Good luck :-)

-- 
Marcin
m4enterprise.googlecode.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Yanko, Curtis" <cu...@uhc.com>]

This sounds promising

________________________________

Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
Making IT Happen, one build at a time, 600 times a day
 

> -----Original Message-----
> From: epabst [mailto:epabst@gmail.com] 
> Sent: Wednesday, March 02, 2011 10:25 AM
> To: users@maven.apache.org
> Subject: RE: Continuous Delivery and Maven
> 
> I've put a lot of thought into this because I'm working on 
> designing continuous delivery with Maven, Hudson, and Nexus.  
> Our criteria is this:
> 
> - We want to have continuous integration of stable versioned 
> components.
> - We don't want to have noise in the SCM logs.
> - We want builds to be repeatable and traceable.
> - We want it to be easy for developers to work on features 
> without having to deal with dependency versions.
> - We want the system to be simple.
> - We want to know what changed between different deployable 
> versions of the system.
> - We want to avoid needing to build the same revision of a 
> component twice.
> - We want it to be easy to debug locally against any specific 
> integration pipeline build's versions.
> 
> This is what I'm thinking:
> Maven:
> - The pom.xml has a SNAPSHOT version and version ranges for 
> its dependencies.  In a multi-module project, only the parent 
> pom should have the version ranges, and the sub-modules inherit them.
> - For complicated projects, a dependency-management pom.xml 
> should be used which all projects import.  It only has 
> specific versions (not version
> ranges) in its dependencyManagement section.  Each project 
> pom.xml imports it using a version range.
> - Use the maven-buildmetadata-plugin to capture the SCM 
> revision and URL in each built artifact.
> 
> Component Pipeline (e.g. Hudson):
> - The component pipeline replaces "-SNAPSHOT" with 
> ".${BUILD_NUMBER}{PADDED_SCM_REVISION}".  The BUILD_NUMBER 
> makes each build unique, and the SCM_REVISION is optional but 
> can add traceability.  This even works for Git where the 
> revision numbers are not incremental.  This is NOT committed to SCM.
> - The component pipeline resolves all of the version ranges.  
> This is NOT committed to SCM.
> - The component pipeline runs "mvn clean install"
> - The component pipeline deploys the artifacts to a special 
> "integration"
> Nexus repo only used by the integration pipeline (not 
> component pipelines).
> - The component pipeline triggers the integration pipeline.
> 
> Integration Pipeline (e.g. Hudson)
> - The CI server picks component versions (from mvn
> versions:display-property-updates) to try to integrate and 
> triggers an integration run for each combination of versions.
> - If using a dependency-management pom, the integration 
> pipeline publishes a version of it to the special 
> "integration" Nexus repo.
> - The integration pipeline replaces "-SNAPSHOT" with 
> ".${BUILD_NUMBER}{PADDED_SCM_REVISION}".
> - The integration pipeline resolves all of the version ranges.
> - The integration pipeline assembles and packages the 
> deployable artifacts using a dedicated maven project using 
> the specified versions as command-line version property 
> overrides (e.g. -Dcomponent1.version=1.5.1032212).
> - The integration pipeline deploys to a testing server.
> - The integration pipeline runs acceptance tests.
> - Upon success, the integration pipeline promotes all of the 
> artifacts:
>    - It marks the integration build as promoted.
>    - It promotes original component pipeline CI build (e.g. 
> using Hudson's Build Promotion Plugin)
>    - It publishes the artifacts to the main nexus repository.
>    - It creates a tag with the integration build number in 
> the component's SCM.
>    - It updates the dependency-management pom with the 
> component versions used and commits it to SCM along with a 
> tag with the integration pipeline build number.
>    - Promotes any deployable artifacts.
> 
> This setup prevents version leakages since all published 
> artifacts have specific versions for every dependency. 
> This setup allows for developers to develop on trunk and 
> automatically be using the latest stable versions of all dependencies.
> It enforces that changes are backward compatible at least 
> relative to the promoted downstream usage of the last 
> promoted version of that component.
> 
> I think enhancing the versions-maven-plugin to support 
> replacing "-SNAPSHOT"
> with a given string would be helpful.  I am currently using a 
> Scala script for this.  Maybe the new goal should also 
> resolve the version ranges, but it's not necessary since that 
> is already available as a goal.
> 
> I welcome any and all feedback.
> 
> Eric Pabst
> 
> 
> Yanko, Curtis wrote:
> > 
> > I though the idea we talked about was to re-write the POM 
> that get's 
> > packaged with the actual version used from a version range?
> > 
> > ________________________________
> > 
> > Curt Yanko | Continuous Integration Services | UnitedHealth 
> Group IT 
> > Making IT Happen, one build at a time, 600 times a day
> > 
> 
> 
> --
> View this message in context: 
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven
> -tp3245370p3406688.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
> 

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

[Jason Chaffee <jc...@ebates.com>]

Sounds like something WealthFront would be doing.  :)


-----Original Message-----
From: epabst [mailto:epabst@gmail.com]
Sent: Wed 3/2/2011 7:25 AM
To: users@maven.apache.org
Subject: RE: Continuous Delivery and Maven
 
I've put a lot of thought into this because I'm working on designing
continuous delivery with Maven, Hudson, and Nexus.  Our criteria is this:

- We want to have continuous integration of stable versioned components.
- We don't want to have noise in the SCM logs.
- We want builds to be repeatable and traceable.
- We want it to be easy for developers to work on features without having to
deal with dependency versions.
- We want the system to be simple.
- We want to know what changed between different deployable versions of the
system.
- We want to avoid needing to build the same revision of a component twice.
- We want it to be easy to debug locally against any specific integration
pipeline build's versions.

This is what I'm thinking:
Maven:
- The pom.xml has a SNAPSHOT version and version ranges for its
dependencies.  In a multi-module project, only the parent pom should have
the version ranges, and the sub-modules inherit them.
- For complicated projects, a dependency-management pom.xml should be used
which all projects import.  It only has specific versions (not version
ranges) in its dependencyManagement section.  Each project pom.xml imports
it using a version range.
- Use the maven-buildmetadata-plugin to capture the SCM revision and URL in
each built artifact.

Component Pipeline (e.g. Hudson):
- The component pipeline replaces "-SNAPSHOT" with
".${BUILD_NUMBER}{PADDED_SCM_REVISION}".  The BUILD_NUMBER makes each build
unique, and the SCM_REVISION is optional but can add traceability.  This
even works for Git where the revision numbers are not incremental.  This is
NOT committed to SCM.
- The component pipeline resolves all of the version ranges.  This is NOT
committed to SCM.
- The component pipeline runs "mvn clean install"
- The component pipeline deploys the artifacts to a special "integration"
Nexus repo only used by the integration pipeline (not component pipelines).
- The component pipeline triggers the integration pipeline.

Integration Pipeline (e.g. Hudson)
- The CI server picks component versions (from mvn
versions:display-property-updates) to try to integrate and triggers an
integration run for each combination of versions.
- If using a dependency-management pom, the integration pipeline publishes a
version of it to the special "integration" Nexus repo.
- The integration pipeline replaces "-SNAPSHOT" with
".${BUILD_NUMBER}{PADDED_SCM_REVISION}".
- The integration pipeline resolves all of the version ranges.
- The integration pipeline assembles and packages the deployable artifacts
using a dedicated maven project using the specified versions as command-line
version property overrides (e.g. -Dcomponent1.version=1.5.1032212).
- The integration pipeline deploys to a testing server.
- The integration pipeline runs acceptance tests.
- Upon success, the integration pipeline promotes all of the artifacts:
   - It marks the integration build as promoted.
   - It promotes original component pipeline CI build (e.g. using Hudson's
Build Promotion Plugin)
   - It publishes the artifacts to the main nexus repository.
   - It creates a tag with the integration build number in the component's
SCM.
   - It updates the dependency-management pom with the component versions
used and commits it to SCM along with a tag with the integration pipeline
build number.
   - Promotes any deployable artifacts.

This setup prevents version leakages since all published artifacts have
specific versions for every dependency. 
This setup allows for developers to develop on trunk and automatically be
using the latest stable versions of all dependencies.
It enforces that changes are backward compatible at least relative to the
promoted downstream usage of the last promoted version of that component.

I think enhancing the versions-maven-plugin to support replacing "-SNAPSHOT"
with a given string would be helpful.  I am currently using a Scala script
for this.  Maybe the new goal should also resolve the version ranges, but
it's not necessary since that is already available as a goal.

I welcome any and all feedback.

Eric Pabst


Yanko, Curtis wrote:
> 
> I though the idea we talked about was to re-write the POM that get's
> packaged with the actual version used from a version range?
> 
> ________________________________
> 
> Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
> Making IT Happen, one build at a time, 600 times a day
> 


--
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3406688.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

[epabst <ep...@gmail.com>]

I've put a lot of thought into this because I'm working on designing
continuous delivery with Maven, Hudson, and Nexus.  Our criteria is this:

- We want to have continuous integration of stable versioned components.
- We don't want to have noise in the SCM logs.
- We want builds to be repeatable and traceable.
- We want it to be easy for developers to work on features without having to
deal with dependency versions.
- We want the system to be simple.
- We want to know what changed between different deployable versions of the
system.
- We want to avoid needing to build the same revision of a component twice.
- We want it to be easy to debug locally against any specific integration
pipeline build's versions.

This is what I'm thinking:
Maven:
- The pom.xml has a SNAPSHOT version and version ranges for its
dependencies.  In a multi-module project, only the parent pom should have
the version ranges, and the sub-modules inherit them.
- For complicated projects, a dependency-management pom.xml should be used
which all projects import.  It only has specific versions (not version
ranges) in its dependencyManagement section.  Each project pom.xml imports
it using a version range.
- Use the maven-buildmetadata-plugin to capture the SCM revision and URL in
each built artifact.

Component Pipeline (e.g. Hudson):
- The component pipeline replaces "-SNAPSHOT" with
".${BUILD_NUMBER}{PADDED_SCM_REVISION}".  The BUILD_NUMBER makes each build
unique, and the SCM_REVISION is optional but can add traceability.  This
even works for Git where the revision numbers are not incremental.  This is
NOT committed to SCM.
- The component pipeline resolves all of the version ranges.  This is NOT
committed to SCM.
- The component pipeline runs "mvn clean install"
- The component pipeline deploys the artifacts to a special "integration"
Nexus repo only used by the integration pipeline (not component pipelines).
- The component pipeline triggers the integration pipeline.

Integration Pipeline (e.g. Hudson)
- The CI server picks component versions (from mvn
versions:display-property-updates) to try to integrate and triggers an
integration run for each combination of versions.
- If using a dependency-management pom, the integration pipeline publishes a
version of it to the special "integration" Nexus repo.
- The integration pipeline replaces "-SNAPSHOT" with
".${BUILD_NUMBER}{PADDED_SCM_REVISION}".
- The integration pipeline resolves all of the version ranges.
- The integration pipeline assembles and packages the deployable artifacts
using a dedicated maven project using the specified versions as command-line
version property overrides (e.g. -Dcomponent1.version=1.5.1032212).
- The integration pipeline deploys to a testing server.
- The integration pipeline runs acceptance tests.
- Upon success, the integration pipeline promotes all of the artifacts:
   - It marks the integration build as promoted.
   - It promotes original component pipeline CI build (e.g. using Hudson's
Build Promotion Plugin)
   - It publishes the artifacts to the main nexus repository.
   - It creates a tag with the integration build number in the component's
SCM.
   - It updates the dependency-management pom with the component versions
used and commits it to SCM along with a tag with the integration pipeline
build number.
   - Promotes any deployable artifacts.

This setup prevents version leakages since all published artifacts have
specific versions for every dependency. 
This setup allows for developers to develop on trunk and automatically be
using the latest stable versions of all dependencies.
It enforces that changes are backward compatible at least relative to the
promoted downstream usage of the last promoted version of that component.

I think enhancing the versions-maven-plugin to support replacing "-SNAPSHOT"
with a given string would be helpful.  I am currently using a Scala script
for this.  Maybe the new goal should also resolve the version ranges, but
it's not necessary since that is already available as a goal.

I welcome any and all feedback.

Eric Pabst


Yanko, Curtis wrote:
> 
> I though the idea we talked about was to re-write the POM that get's
> packaged with the actual version used from a version range?
> 
> ________________________________
> 
> Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
> Making IT Happen, one build at a time, 600 times a day
> 


--
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3406688.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[Brian Topping <to...@codehaus.org>]

On Nov 8, 2010, at 2:27 PM, Yanko, Curtis wrote:

> 
> To be clear, I'm not advocating time stamped artifacts simply indulging
> them for now to try and solve a problem that imo doesn't exist except as
> a thought experiment.

Yup, feel the same way.

> I agree with your assessment of a Maven Repo and that's why we have a
> build manager to go with it. It keeps records of build meta-data.
> 
> Sure, A doesn't have the meta-data for B & C but they do and they all
> got put together at some point (we are integrating no?). The build
> management system also keeps all of the logs and manages them
> intelligently based on how for they got promoted in the life cycle. So
> pretty optimal in my opinion since I do want to pass an audit. The BMS
> also keeps all of the meta-data in it's db and while that is not
> *indefinitely*, it's very long when compared to release cycles (driven
> more by compliance and legal).

Also fair.  But if were talking about "generalized solutions" instead of "localized means of coping", it's a bit of a different problem space.  Agreed that the BMS as a whole should not be losing it's cache so often that one needs to look at the logs very often, if ever.   I'm just making the point that if a solution is going to adhere to standards set by it's dependent subsystems, it ought to solve the problem within those constraints or make it an explicit non-requirement.  Sometimes searching logs is the only way to solve a database corruption or loss issue, but it's a disaster recovery response, not business-as-usual.

> Keeping the SCC info in the manifest provides excellent traceability. I
> don't care that Maven can't use it, I can.

The adage from the world of disaster recovery can be summed up as "it doesn't matter if your data is backed up, it matters if someone else can restore it".  

DR situations usually arise when someone needed the archives ten minutes ago and found them corrupted.  I was never an advocate of foolproof DR tools until I had to wear the hat of a recovery guy with a half-dozen frustrated users crawling all over me because someone set up a system that wasn't built to be restored.

> The real crux here is whether or not B and C are mine or some one else's
> (even if that is internal).

Indeed, and all bets are off once the transitive facilities stop communicating sufficient information.

> Only my stuff can be a SNAPSHOT and it is either all a snapshot or it is
> not. So, if B & C are mine it's not an issue, if they belong to some one
> else's, they can't be SNAPSHOTs, it's that simple. I can even use the
> enforcer to ensure there isn't a SNAPSHOT set anywhere as part of the
> inspection process.
> 
> We release by changing one entry in one POM and all of our stuff gets
> versioned, built and released. Repeat the process and everything is back
> to the next SNAPSHOT so we can resume changing things. It seems it is
> this one discreet activity that CD abhors. You want to defer it to after
> the fact which doesn't seem any different than what Stephen suggested by
> waiting for CI feedback and then trigger a CD build. I don't get what
> event prompts you to wan to go back and reproduce a build to be a
> release?

There was a time I wouldn't have felt naked without a CI server.  I would "never" institute CD, but then who would ever need more than 640KB?  Things change.  Any tool can either provide generalized facilities to enable (if not support) these kind of requests or sometimes find itself delegitimized by cocky upstarts with more hype than heat.  I like Maven and want it to remain the favorite build tool, so it makes sense to help consider these kinds of arguments.  I look forward to being surprised someday.  In the mean time, if someone wants to put their head in this area, why discourage them?

> The ours vs. theirs problem exist for your plugin scenario too. Sure
> you've created a synthetic POM but have they? If B & C's  development is
> in fact decoupled from yours, why would they? How would they know? If
> they didn't make one and in turn are using SNAPSHOT deps themselves then
> you're hosed and your problem is spiraling in complexity.

The site-specific policy that groups make today are still valid.  I generally don't allow external SNAPSHOTs into Nexus, and this is probably a sufficient means to solve the problem if their RM can't transitively supply the facilities required to interoperate to provide a named snapshot (i.e. their RM doesn't run the plugin).  

I simply can't imagine a partnership where I have no clue about what an external partner is doing but still want their bleeding-edge work product deployed to my production server in a CD process.  On the other hand, if I am tight enough with them to know what they are doing and we agree I do want their bleeding-edge going live on my server, it's not farfetched at all that we would be sharing a lot more than just build artifacts.  We would probably be pretty well-integrated as teams and would collectively see the benefits of both doing CD or eschew it altogether.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Yanko, Curtis" <cu...@uhc.com>]

 To be clear, I'm not advocating time stamped artifacts simply indulging
them for now to try and solve a problem that imo doesn't exist except as
a thought experiment.

I agree with your assessment of a Maven Repo and that's why we have a
build manager to go with it. It keeps records of build meta-data.

Sure, A doesn't have the meta-data for B & C but they do and they all
got put together at some point (we are integrating no?). The build
management system also keeps all of the logs and manages them
intelligently based on how for they got promoted in the life cycle. So
pretty optimal in my opinion since I do want to pass an audit. The BMS
also keeps all of the meta-data in it's db and while that is not
*indefinitely*, it's very long when compared to release cycles (driven
more by compliance and legal).

Keeping the SCC info in the manifest provides excellent traceability. I
don't care that Maven can't use it, I can.

The real crux here is whether or not B and C are mine or some one else's
(even if that is internal).

Only my stuff can be a SNAPSHOT and it is either all a snapshot or it is
not. So, if B & C are mine it's not an issue, if they belong to some one
else's, they can't be SNAPSHOTs, it's that simple. I can even use the
enforcer to ensure there isn't a SNAPSHOT set anywhere as part of the
inspection process.

 We release by changing one entry in one POM and all of our stuff gets
versioned, built and released. Repeat the process and everything is back
to the next SNAPSHOT so we can resume changing things. It seems it is
this one discreet activity that CD abhors. You want to defer it to after
the fact which doesn't seem any different than what Stephen suggested by
waiting for CI feedback and then trigger a CD build. I don't get what
event prompts you to wan to go back and reproduce a build to be a
release?

The ours vs. theirs problem exist for your plugin scenario too. Sure
you've created a synthetic POM but have they? If B & C's  development is
in fact decoupled from yours, why would they? How would they know? If
they didn't make one and in turn are using SNAPSHOT deps themselves then
you're hosed and your problem is spiraling in complexity.

Only the things my team are changing and talking about are allowed to be
SNAPSHOTs, this way I have people and interactions making decisions
instead of trying to codify all of the possibilities.

If your goal is to change anything anywhere at anytime and still deliver
any of it, good luck. Even Timothy Fitz's work was just CI with
Inspection and Testing along the way. The difference was, Prod deploy
was just one more *test* and if anything bad happened it got pulled.
Just because in theory any build can be deployed to prod doesn't mean
that every build is of production release quality. Just because you can
doesn't mean you should. It just means we should be providing the
customer with value faster than they want it so there is always a
backlog at their disposal


________________________________

Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
Making IT Happen, one build at a time, 600 times a day

-----Original Message-----
From: Brian Topping [mailto:topping@codehaus.org] 
Sent: Monday, November 08, 2010 1:22 PM
To: Maven Users List
Subject: Re: Continuous Delivery and Maven


On Nov 8, 2010, at 12:33 PM, Yanko, Curtis wrote:

> Why is that not guaranteed to exist or be reliable?

A Maven repository is a cache, not a reliable persistent store.  *Yours*
may be reliable, but the artifacts that are built to it should not
contain metadata that, if lost, would make rebuilding that (or another
artifact) exceptionally difficult.  

> And at the
> moment I build A the build log will tell me exactly which SNAPSHOT we 
> received.

So you want to keep build logs around indefinitely to solve this
problem?  That sounds suboptimal.  There's no schema for log output, so
pulling the values out by machine is unreliable over time.  

> I can crack it open and see exactly which SCC revision was used and 
> which path within the SCC it came from (because we bake that info into

> everything we build).

But if A depends on B and C and the SCC revisions of B and C are not
recorded in A, then there isn't a way to reliably build A.  

The other side of this question is where to store the revision IDs for B
and C.  In the manifest?  Maven can't use that information.  Possibly in
the POM as an additional qualifier in the respective <dependency>
element of the POM that is stored in the artifact would make more sense,
but then Maven needs to be changed with questionable semantics (what
happens if there is an impossible combination of <version> and this
revision ID qualifier?)

This is why I was considering a repository manager plugin.  It's site
specific, and if it generated throwaway synthetic POMs for reproducing
old builds, nothing has to be changed in Maven itself (the repository
manager can call the artifacts anything it wants to properly identify
the exact versions of B and C, likely returning synthetic POMs for them
too).




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[Brian Topping <to...@codehaus.org>]

On Nov 8, 2010, at 12:33 PM, Yanko, Curtis wrote:

> Why is that not guaranteed to exist or be reliable?

A Maven repository is a cache, not a reliable persistent store.  *Yours* may be reliable, but the artifacts that are built to it should not contain metadata that, if lost, would make rebuilding that (or another artifact) exceptionally difficult.  

> And at the
> moment I build A the build log will tell me exactly which SNAPSHOT we
> received.

So you want to keep build logs around indefinitely to solve this problem?  That sounds suboptimal.  There's no schema for log output, so pulling the values out by machine is unreliable over time.  

> I can crack it open and see exactly which SCC
> revision was used and which path within the SCC it came from (because we
> bake that info into everything we build).

But if A depends on B and C and the SCC revisions of B and C are not recorded in A, then there isn't a way to reliably build A.  

The other side of this question is where to store the revision IDs for B and C.  In the manifest?  Maven can't use that information.  Possibly in the POM as an additional qualifier in the respective <dependency> element of the POM that is stored in the artifact would make more sense, but then Maven needs to be changed with questionable semantics (what happens if there is an impossible combination of <version> and this revision ID qualifier?)

This is why I was considering a repository manager plugin.  It's site specific, and if it generated throwaway synthetic POMs for reproducing old builds, nothing has to be changed in Maven itself (the repository manager can call the artifacts anything it wants to properly identify the exact versions of B and C, likely returning synthetic POMs for them too).




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Yanko, Curtis" <cu...@uhc.com>]

Thanks,

I did manage to find it too. Not sure I follow his logic though.

   "One of the things I like about snapshots is it just simply means
"latest".  Though the thing about timestamped snapshots is that they
aren't guaranteed to exist (the repository is not typically assumed to
be reliable), and they aren't 100% reproducible (the timestamp offset
includes the time it took to build the artifact and all the artifacts
before it, meaning there's no way to know exactly what point in time the
build came from).  Even if one could find the correct timestamp to check
out from to get the same binary, whatever subsystem creates the
timestamp on upload (wagon?) probably doesn't like being told what to
call the snapshot."

If I build a SNAPSHOT and deploy it to an internal Maven Repo it will be
given a unique identifier based on a time stamp (repo configured to do
this). Why is that not guaranteed to exist or be reliable? And at the
moment I build A the build log will tell me exactly which SNAPSHOT we
received. I don't ever need to re-produce it because I have it and am
managing the binary but... I can crack it open and see exactly which SCC
revision was used and which path within the SCC it came from (because we
bake that info into everything we build). So I can reproduce it in a
pinch. What's also missing from the conversation is the final assembly
where A,B and C get put together for deployment which is also managed as
a binary and represents the bill-of-materials. And of course my Maven
Site report for A would have documented which B & C I had too.

________________________________

Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
Making IT Happen, one build at a time, 600 times a day

-----Original Message-----
From: jhumble [mailto:jez@jezhumble.net] 
Sent: Monday, November 08, 2010 12:11 PM
To: users@maven.apache.org
Subject: Re: Continuous Delivery and Maven


Hi Curt - it was this one:
http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370
p3254439.html

On 8 November 2010 09:07, Yanko, Curtis [via Maven] <
ml-node+3255382-175104679-143561@n5.nabble.com<ml-node%2B3255382-1751046
ml-node+79-143561@n5.nabble.com>
> wrote:

>
> I didn't see a reply from a Brian. What answer did he provided that 
> answered your question?
>
> ________________________________
>
> Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
> Making IT Happen, one build at a time, 600 times a day
>
> -----Original Message-----
> From: jhumble [mailto:[hidden 
> email]<http://user/SendEmail.jtp?type=node&node=3255382&i=0>]
>
> Sent: Monday, November 08, 2010 11:58 AM
> To: [hidden email] 
> <http://user/SendEmail.jtp?type=node&node=3255382&i=1>
> Subject: Re: Continuous Delivery and Maven
>
>
> Todd, I have read all of your posts and I have come to the conclusion 
> that you're missing the point of CD. I was really hoping to avoid an 
> argument about process, because I just want to work out what needs to 
> be done to Maven to make it support CD, and that's already a big 
> enough discussion for one thread. However since the thread has 
> (perhaps
> inevitably) been taken over by a discussion about what continuous 
> delivery is, I will add my 1c. In any case I think I have what I need 
> from the discussion with Brian.
>
> With CD, the software is *always* production ready, right from the 
> start of the project. Any work of any kind that doesn't result in a 
> deployable build is waste.
>
> If you are at the start of a release, your product owner will have a 
> good
> > idea of how much content needs to get to the customer to fullfill 
> > that
>
> > release. Doing CD through the entire lifecycle is largely a waste
> IMHO.
>
>
> Wrong. In fact, it's the opposite - any work that doesn't keep the 
> software in a deployable, releasable state is waste, because you can't

> know whether or not the work you have done is actually useful, or even

> whether it keeps the software working. And you can't know whether or 
> not the software is working - i.e. whether or not the build can be 
> deployed
> - until it has passed end-to-end acceptance tests under realistic 
> loads in a production-like environment.
>
> I am fine with you using the process you describe. If it works for 
> you, that's great. But please don't call it continuous delivery - it
isn't.
>
> Now, assuming we are working in a cd process, the crucial thing is 
> that we don't waste any cycles creating a build that couldn't be 
> released. We then take this binary and put it through the rest of the 
> deployment pipeline (or build life or whatever you want to call it). 
> But crucially, we don't want to recreate the binary later on. If you 
> want more detail on the mechanics of how it works, you can read the 
> free chapter from my book here:
> http://www.informit.com/articles/article.aspx?p=1621865
>
> *What I want from Maven*
> *===================*
>
> We want the simplicity of snapshots with the traceability of proper 
> releases. So I think from what Brian said, I'd like the the Maven 
> snapshot build process to create enough metadata in the pom file such 
> that when you ran the release plugin, it wouldn't be necessary for it 
> to rebuild the artifact - it could just do the various bits of tagging

> and metadata creation using the information in the pom associated with

> the snapshot. We might also want the release plugin to try and 
> recreate the binary using its process and verify the md5 is the same 
> as the md5 of the snapshot.
>
> If anybody has any feedback on this hypothesis, I'd be very grateful.
>
> Thanks,
>
> Jez.
>
> On 8 November 2010 08:49, Thiessen, Todd (Todd) [via Maven] < [hidden 
> email] 
> <http://user/SendEmail.jtp?type=node&node=3255382&i=2><ml-node%2B32553
> 36-196234
>
> [hidden email] <http://user/SendEmail.jtp?type=node&node=3255382&i=3>>
> > wrote:
>
> > > I'm thinking tha Ci wouldn't be affected at all, CD still requires

> > > Ci as a quality metric preventing deployment to the customer.
> >
> > I am curious to see that. Or how it would work. How do you put in 
> > fixed release numbers into a CD build and then switch back to CI 
> > building? And I can only imagine it being quite complex.
> >
> > The only thing I can think of is something like:
> >
> > 1. CI build produces 1.0-SNAPSHOT
> > 2. CD build produces 1.0-01
> > 3. CD build reverts source back to 1.0-SNAPSHOT 4. Repeat
> >
> >
> > --------------------------------------------------------------------
> > -
> > To unsubscribe, e-mail: [hidden
> email]<http://user/SendEmail.jtp?type=node&node=3255336&i=0>
> > For additional commands, e-mail: [hidden
> email]<http://user/SendEmail.jtp?type=node&node=3255336&i=1>
> >
> >
> >
> > ------------------------------
> >  View message @
> >
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32453
> 70<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32
> 45370?by-user=t>
> p3255336.html
> > To unsubscribe from Continuous Delivery and Maven, click
> here<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsu
> bs<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubs
> &by-user=t>
> cribe_by_code&node=3245370&code=amV6QGplemh1bWJsZS5uZXR8MzI0NTM3MHwtMT
> g4
> MjM1NzMyNA==>.
> >
> >
> >
>
>
> --
> Jez Humble
> Co-author, *Continuous Delivery <http://continuousdelivery.com/>* 
> http://continuousdelivery.com/ http://jezhumble.net/
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32453
> 70<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32
> 45370?by-user=t>
> p3255361.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> This e-mail, including attachments, may include confidential and/or 
> proprietary information, and may be used only by the person or entity 
> to which it is addressed. If the reader of this e-mail is not the 
> intended recipient or his or her authorized agent, the reader is 
> hereby notified that any dissemination, distribution or copying of 
> this e-mail is prohibited. If you have received this e-mail in error, 
> please notify the sender by replying to this message and delete this
e-mail immediately.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden 
> email]<http://user/SendEmail.jtp?type=node&node=3255382&i=4>
> For additional commands, e-mail: [hidden 
> email]<http://user/SendEmail.jtp?type=node&node=3255382&i=5>
>
>
>
> ------------------------------
>  View message @
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32453
> 70p3255382.html To unsubscribe from Continuous Delivery and Maven, 
> click
here<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubs
cribe_by_code&node=3245370&code=amV6QGplemh1bWJsZS5uZXR8MzI0NTM3MHwtMTg4
MjM1NzMyNA==>.
>
>
>


--
Jez Humble
Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
http://continuousdelivery.com/ http://jezhumble.net/

--
View this message in context:
http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370
p3255387.html
Sent from the Maven - Users mailing list archive at Nabble.com.

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[jhumble <je...@jezhumble.net>]

Hi Curt - it was this one:
http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3254439.html

On 8 November 2010 09:07, Yanko, Curtis [via Maven] <
ml-node+3255382-175104679-143561@n5.nabble.com<ml...@n5.nabble.com>
> wrote:

>
> I didn't see a reply from a Brian. What answer did he provided that
> answered your question?
>
> ________________________________
>
> Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
> Making IT Happen, one build at a time, 600 times a day
>
> -----Original Message-----
> From: jhumble [mailto:[hidden email]<http://user/SendEmail.jtp?type=node&node=3255382&i=0>]
>
> Sent: Monday, November 08, 2010 11:58 AM
> To: [hidden email] <http://user/SendEmail.jtp?type=node&node=3255382&i=1>
> Subject: Re: Continuous Delivery and Maven
>
>
> Todd, I have read all of your posts and I have come to the conclusion
> that you're missing the point of CD. I was really hoping to avoid an
> argument about process, because I just want to work out what needs to be
> done to Maven to make it support CD, and that's already a big enough
> discussion for one thread. However since the thread has (perhaps
> inevitably) been taken over by a discussion about what continuous
> delivery is, I will add my 1c. In any case I think I have what I need
> from the discussion with Brian.
>
> With CD, the software is *always* production ready, right from the start
> of the project. Any work of any kind that doesn't result in a deployable
> build is waste.
>
> If you are at the start of a release, your product owner will have a
> good
> > idea of how much content needs to get to the customer to fullfill that
>
> > release. Doing CD through the entire lifecycle is largely a waste
> IMHO.
>
>
> Wrong. In fact, it's the opposite - any work that doesn't keep the
> software in a deployable, releasable state is waste, because you can't
> know whether or not the work you have done is actually useful, or even
> whether it keeps the software working. And you can't know whether or not
> the software is working - i.e. whether or not the build can be deployed
> - until it has passed end-to-end acceptance tests under realistic loads
> in a production-like environment.
>
> I am fine with you using the process you describe. If it works for you,
> that's great. But please don't call it continuous delivery - it isn't.
>
> Now, assuming we are working in a cd process, the crucial thing is that
> we don't waste any cycles creating a build that couldn't be released. We
> then take this binary and put it through the rest of the deployment
> pipeline (or build life or whatever you want to call it). But crucially,
> we don't want to recreate the binary later on. If you want more detail
> on the mechanics of how it works, you can read the free chapter from my
> book here:
> http://www.informit.com/articles/article.aspx?p=1621865
>
> *What I want from Maven*
> *===================*
>
> We want the simplicity of snapshots with the traceability of proper
> releases. So I think from what Brian said, I'd like the the Maven
> snapshot build process to create enough metadata in the pom file such
> that when you ran the release plugin, it wouldn't be necessary for it to
> rebuild the artifact - it could just do the various bits of tagging and
> metadata creation using the information in the pom associated with the
> snapshot. We might also want the release plugin to try and recreate the
> binary using its process and verify the md5 is the same as the md5 of
> the snapshot.
>
> If anybody has any feedback on this hypothesis, I'd be very grateful.
>
> Thanks,
>
> Jez.
>
> On 8 November 2010 08:49, Thiessen, Todd (Todd) [via Maven] <
> [hidden email] <http://user/SendEmail.jtp?type=node&node=3255382&i=2><ml-node%2B3255336-196234
>
> [hidden email] <http://user/SendEmail.jtp?type=node&node=3255382&i=3>>
> > wrote:
>
> > > I'm thinking tha Ci wouldn't be affected at all, CD still requires
> > > Ci as a quality metric preventing deployment to the customer.
> >
> > I am curious to see that. Or how it would work. How do you put in
> > fixed release numbers into a CD build and then switch back to CI
> > building? And I can only imagine it being quite complex.
> >
> > The only thing I can think of is something like:
> >
> > 1. CI build produces 1.0-SNAPSHOT
> > 2. CD build produces 1.0-01
> > 3. CD build reverts source back to 1.0-SNAPSHOT 4. Repeat
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden
> email]<http://user/SendEmail.jtp?type=node&node=3255336&i=0>
> > For additional commands, e-mail: [hidden
> email]<http://user/SendEmail.jtp?type=node&node=3255336&i=1>
> >
> >
> >
> > ------------------------------
> >  View message @
> >
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370?by-user=t>
> p3255336.html
> > To unsubscribe from Continuous Delivery and Maven, click
> here<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubs<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubs&by-user=t>
> cribe_by_code&node=3245370&code=amV6QGplemh1bWJsZS5uZXR8MzI0NTM3MHwtMTg4
> MjM1NzMyNA==>.
> >
> >
> >
>
>
> --
> Jez Humble
> Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
> http://continuousdelivery.com/
> http://jezhumble.net/
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370?by-user=t>
> p3255361.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> This e-mail, including attachments, may include confidential and/or
> proprietary information, and may be used only by the person or entity
> to which it is addressed. If the reader of this e-mail is not the intended
> recipient or his or her authorized agent, the reader is hereby notified
> that any dissemination, distribution or copying of this e-mail is
> prohibited. If you have received this e-mail in error, please notify the
> sender by replying to this message and delete this e-mail immediately.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3255382&i=4>
> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3255382&i=5>
>
>
>
> ------------------------------
>  View message @
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3255382.html
> To unsubscribe from Continuous Delivery and Maven, click here<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_code&node=3245370&code=amV6QGplemh1bWJsZS5uZXR8MzI0NTM3MHwtMTg4MjM1NzMyNA==>.
>
>
>


-- 
Jez Humble
Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
http://continuousdelivery.com/
http://jezhumble.net/

-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3255387.html
Sent from the Maven - Users mailing list archive at Nabble.com.

RE: Continuous Delivery and Maven

["Thiessen, Todd (Todd)" <tt...@avaya.com>]

> 
> That's fine. What I'm suggesting is simply that Maven creates enough
> metadata when building a snapshot that the release plug-in can more or
> less
> just copy it to the released repository when necessary. Crucially though
> it
> won't cause it to be rebuilt.

Thanks. That makes it a little more clear.

However, that's implies renaming. The artifacts get renamed when pubished to a release repo. So to extend the example we have been using, this artifact here:

https://repository.apache.org/content/repositories/maven-snapshots-sonatype/org/apache/maven/maven-core/3.0-SNAPSHOT/maven-core-3.0-20101004.110147-683.jar

Would have to get ranamed to something like:

maven-core-3.0-alpha1

Or whatever the release naming of that project follows.

To keep the same name between a snapshot/release repo, I am not entirely sure how that would work or what changes it would imply to snapshot/release repos. Others may be able to comment on that further.

And I am pretty sure that the community in general is not really in favor of this kind of massaging of the artifacts from snapshot -> release. It invalidates your testing of said snapshot.

I think it is crucial that the release artifact DOES get rebuilt.
 
> That would be great, and the obvious place would be in MANIFEST.MF, but
> the
> format isn't rich enough to store all the information we'd need.

What would be missing? Your pom says your using artifact 1.0-SNAPSHOT.jar. You go and find that jar, open it and find what revision. Do that for all snapshot jars you depend on.

> Right - so you see this file:
> https://repository.apache.org/content/repositories/maven-snapshots-
> sonatype/org/apache/maven/maven-core/3.0-SNAPSHOT/maven-core-3.0-
> 20101004.110147-683.pom
> 
> All I'm suggesting is that in addition to the <groupId> and <artifactId>
> tags that are attached to each <dependency> we *also* store something
> like
> <source><uri>http://svn.apache.org/blah/blah
> </uri><version>1423</version></uri>
> 
> That's it.

Ok. So your talking about two things here. First, that maven store this information on a repository.

The second is that maven would have to query this information during a build, and then update it own "extra information.xml file" to update its transtitive dependency information list and then deploy that list to the repository as well. And this would need to be a complete list of all transtive dependencies, not just direct ones. So now you can download that file, figure out what revision of all your transitive deps are and recreate the entire build.

Now how would this work if a project has release and snapshot dependencies? I think you would only need to do this for snapshot deps.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[jhumble <je...@jezhumble.net>]

>
> At the risk of derailing the conversion again though, there is likely a
> good reason for why it has been such an up hill battle for you.  I hope you
> are prepared to consider that CD is not as great of a solution to a lot of
> the industry as you wish it to be.


Well, if I and many others had not seen it make a huge difference to many
organizations of many different types over many years, I would not have
bothered investing 4 years of my personal life writing the book. What I'm
proposing is not something new and magical - it's something that many, many
others have successfully implemented. I am just the messenger here - please
don't shoot me ;-)

More seriously, sure, it is not a silver bullet. Where it really matters is
when you're delivering software that is strategic for business success. If
you're not doing that, it's probably not that important.

Let's assume that it is useful for some set of people. Why the resistance to
Maven supporting this methodology?


> If you don't change the binaries, they will still be a "snapshot" binary;
> which never goes to a customer. For example, when you search a maven
> repository, you will generally look for artifacts in a released reository.
> If your customer artifacts are now in the snapshot repo, everyone is going
> to have to start searching the released artifacts in the snapshot repos.
> This is just confusing.
>

That's fine. What I'm suggesting is simply that Maven creates enough
metadata when building a snapshot that the release plug-in can more or less
just copy it to the released repository when necessary. Crucially though it
won't cause it to be rebuilt.


> I think maybe the part you're missing is the underlying culture of Maven.
> If I need an artifact, you type it in a repository search, hit enter and
> bingo, the dependency appears in your pom. It takes care of downloading all
> of its transitive dependenies. I don't have to worry about getting latest
> version of the dependencies, fixed versions.... If it's a released artifact,
> I get fixed... if its snapshot, I get the latest. I don't have to look on
> the internet and waste a whole bunch of time. It makes a devs life much
> faster and much easier.
>

Yep, I absolutely undertand that. I am not trying to change anything about
what you just said. In fact, I want to leverage it.

> All I'm doing is adding some more metadata (in the form of
> > changing
> > the names, doing tagging, or whatever)
>
> How does your build know about this extra metadata?  Where are you going to
> store it?
>

I'm proposing to store it in the pom file that gets created along with the
binary (*not* the project's pom file!) - see the example below

A version of 1.0-SNAPSHOT simply means latest 1.0 version. Nice, clean and
> simple. If you want a fixed version you say 1.0-01. Again, nice clean and
> simple.
>

Right. Again, I'm not proposing to change this.

I think the best place to store this information is in the binary itself.
> That will allow you to recreate any build.


That would be great, and the obvious place would be in MANIFEST.MF, but the
format isn't rich enough to store all the information we'd need. Another
possibility would be to create a custom maven XML extension file inside
META-INF.


> Here is an example snapshot folder:
>
>
> https://repository.apache.org/content/repositories/maven-snapshots-sonatype/org/apache/maven/maven-core/3.0-SNAPSHOT/


Right - so you see this file:
https://repository.apache.org/content/repositories/maven-snapshots-sonatype/org/apache/maven/maven-core/3.0-SNAPSHOT/maven-core-3.0-20101004.110147-683.pom

All I'm suggesting is that in addition to the <groupId> and <artifactId>
tags that are attached to each <dependency> we *also* store something like
<source><uri>http://svn.apache.org/blah/blah
</uri><version>1423</version></uri>

That's it.

The whole idea is that you are working off the latest, not a specific
> version. If you are storing this information in source control (whether it's
> the pom or in its own file) then you have to somehow constantly change that
> information to always point to the latest. I don't think there is logically
> away around that ;-).
>

So just to reiterate - I'm not suggesting we change the behavior. All I'm
suggesting is that we *record* the information on what version in source
control each snapshot artifact came from and propagate this information down
the dependency chain so that doing a "release" in maven is just a question
of copying the artifact to the release repo and updating some of the
metadata in its associated pom file - say, giving it a "real" identifier.

Thanks,

Jez.

-- 
Jez Humble
Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
http://continuousdelivery.com/
http://jezhumble.net/

-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3255940.html
Sent from the Maven - Users mailing list archive at Nabble.com.

RE: Continuous Delivery and Maven

["Yanko, Curtis" <cu...@uhc.com>]

I would agree with you on this one. I think one of the discussions that
is missing here is the idea of when or how we determine we have
*something of value*.

My assumptions is it goes something like this:

Build -> Inspect and Test -> Value? YES|NO

Right now the approach presented in this group was to *go back* and take
our *squishy* build, harden it, and ship it.

What I like about our current thinking is that we are taking a gamble,
up front, that what we built will have value so we take our *squishy*
build and harden it at build time so that IF it does pass whatever
quality gates are down the line we don't have to fear going back, we can
in fact *pluck it from the stream* or simply allow it to continue on
it's way.

 

> stephenconnolly wrote:
> > 
> > so lets say for #1 we add a phase of "ship"... we'd have 
> the standard 
> > lifecycle something like
> > 
> > validate -> ... -> compile -> ... -> test -> ... -> package 
> -> ... -> 
> > verify -> install -> deploy -> ship
> > 
> > that would allow us to bind our CD steps to the "ship" phase...
> > 
> 
> I'd be concerned about binding the CD steps to any phase in 
> Maven. In my mind a server deployment should happen by 
> grabbing the deployable artifact from your repository and 
> sending it to the server. In CD we would need to send the 
> artifact to multiple servers through out the pipeline and 
> ultimately have a "push-button" deployment to production. CD 
> is all about making artifacts availible to be deployed not 
> neccessarily forcing the deployment. THis means we have to 
> have a place where the latest blessed version is staged and 
> ready to go.
> 
> I see the Maven repo as an ideal place for this.
> 
> In our environment I feel the "build" build responsibility of 
> maven ends with an artifact being deployed/promoted in the 
> repository. After that the server deployment is triggered and 
> picks up said artifact. I see many tools as possible in this 
> part of the process, most notably scripting or a separate 
> unique Maven invokation. I just think it is very important to 
> separate this phase/process from the build phase/process.
> 
> In many environments we'd also want to pull enviroment 
> specific configuration from a cmdb, add this to the 
> deployable and then deploy. I don't see how this could be 
> easily accomodated if this is simply taked on to the standard 
> Maven life-cycle.
> --
> View this message in context: 
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven
-tp3245370p3259411.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
> 

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[jmorrow <jo...@morrowmail.com>]

stephenconnolly wrote:
> 
> so lets say for #1 we add a phase of "ship"... we'd have the standard
> lifecycle something like
> 
> validate -> ... -> compile -> ... -> test -> ... -> package -> ... ->
> verify -> install -> deploy -> ship
> 
> that would allow us to bind our CD steps to the "ship" phase...
> 

I'd be concerned about binding the CD steps to any phase in Maven. In my
mind a server deployment should happen by grabbing the deployable artifact
from your repository and sending it to the server. In CD we would need to
send the artifact to multiple servers through out the pipeline and
ultimately have a "push-button" deployment to production. CD is all about
making artifacts availible to be deployed not neccessarily forcing the
deployment. THis means we have to have a place where the latest blessed
version is staged and ready to go.

I see the Maven repo as an ideal place for this.

In our environment I feel the "build" build responsibility of maven ends
with an artifact being deployed/promoted in the repository. After that the
server deployment is triggered and picks up said artifact. I see many tools
as possible in this part of the process, most notably scripting or a
separate unique Maven invokation. I just think it is very important to
separate this phase/process from the build phase/process.

In many environments we'd also want to pull enviroment specific
configuration from a cmdb, add this to the deployable and then deploy. I
don't see how this could be easily accomodated if this is simply taked on to
the standard Maven life-cycle.
-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3259411.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: RE: Continuous Delivery and Maven

[jhumble <je...@jezhumble.net>]

BTW - I also think Stephen's suggestion is a good one - it's more or less
what I suggest in the book.

On 10 November 2010 09:45, Jez Humble <je...@jezhumble.net> wrote:

> Hey Todd.
>
> My interpretation of what Jason is saying in his comment here -
> http://www.lucasward.net/2010/11/maven-and-continuous-delivery.html - "you
> should be able to tag the code, and pluck the snapshot out and promote it to
> a release repository... Someone just needs to do the two weeks of work to
> add the tooling." is that this is exactly what he's saying. I'm going to
> have a nose around the code and see if I think I can take a shot at it.
>
> Thanks,
>
> Jez.
>
> On 10 November 2010 05:51, Thiessen, Todd (Todd) [via Maven] <
> ml-node+3258691-1180604705-143561@n5.nabble.com<ml...@n5.nabble.com>
> > wrote:
>
>> Agreed Stephen. I think your proposal is the best so far. I just want to
>> make sure we don't go back into a discussion about promoting snapshots to
>> releases, as I believe that is where this discussion started.  To do that I
>> think would require a significant re-architecture of maven which I don't
>> think would be happening in the near future.
>>
>> > -----Original Message-----
>> > From: Stephen Connolly [mailto:[hidden email]<http://user/SendEmail.jtp?type=node&node=3258691&i=0>]
>>
>> > Sent: Wednesday, November 10, 2010 8:29 AM
>> > To: Maven Users List
>> > Subject: Re: RE: Continuous Delivery and Maven
>> >
>> > Imho taking a snapshot artefact and renaming as a release artefact and
>> > pushing to the remote repo will never be supported by maven, but my
>> > ship-maven-plugin (not ready for publishing yet) and some extra mojos
>> > added
>> > to versions-maven-plugin should enable CD in a way that is in keeping
>> > with
>> > the "maven way", as long as ranges are used in place of snapshots. (will
>>
>> > also need minor tweaks to the maven-release-plugin, but these would be
>> > backwards compatible tweaks that do not change its current behaviour,
>> > only
>> > provide a hook for extending it)
>> >
>> > - Stephen
>> >
>> > On 10 Nov 2010 13:03, "Thiessen, Todd (Todd)" <[hidden email]<http://user/SendEmail.jtp?type=node&node=3258691&i=1>>
>>
>> > wrote:
>> >
>> > I don't think thats the same thing. The proposal is to take a snapshot
>> > artifact which was built using mvn deploy and promote it to the release
>> > repo. I think what you are referring to here Jason is how the release
>> > plugin
>> > first builds the snapshot, tags it, and then rebuilds the tag.
>> >
>> >
>> > > -----Original Message-----
>> > > From: Jason van Zyl [mailto:[hidden email]<http://user/SendEmail.jtp?type=node&node=3258691&i=2>]
>>
>> > > Sent: Wednesday, Nove...
>> >
>> > > Subject: Re: Continuous Delivery and Maven
>> > >
>> > >
>> > > On Nov 9, 2010, at 2:25 PM, Thiessen, Todd (Tod...
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3258691&i=3>
>> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3258691&i=4>
>>
>>
>>
>> ------------------------------
>>  View message @
>> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3258691.html
>> To unsubscribe from Continuous Delivery and Maven, click here<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_code&node=3245370&code=amV6QGplemh1bWJsZS5uZXR8MzI0NTM3MHwtMTg4MjM1NzMyNA==>.
>>
>>
>>
>
>
> --
> Jez Humble
> Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
> http://continuousdelivery.com/
> http://jezhumble.net/
>
>
>


-- 
Jez Humble
Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
http://continuousdelivery.com/
http://jezhumble.net/

-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3259081.html
Sent from the Maven - Users mailing list archive at Nabble.com.

RE: Continuous Delivery and Maven

["Thiessen, Todd (Todd)" <tt...@avaya.com>]

> My apologies - I realize it's somewhat unfair of me to say I don't want
> to
> discuss the value proposition any more and then dissect a bunch of what
> you
> said. I guess I have been explaining the value proposition quite a lot
> recently and would like to get back to some more technical stuff

I can understand that.  I am sure you have been pushing this idea for quite a while and saying a lot to back it up.

At the risk of derailing the conversion again though, there is likely a good reason for why it has been such an up hill battle for you.  I hope you are prepared to consider that CD is not as great of a solution to a lot of the industry as you wish it to be. 
 
> So long as I don't change the actual binaries, how does this invalidate
> the
> testing?

If you don't change the binaries, they will still be a "snapshot" binary; which never goes to a customer. For example, when you search a maven repository, you will generally look for artifacts in a released reository. If your customer artifacts are now in the snapshot repo, everyone is going to have to start searching the released artifacts in the snapshot repos. This is just confusing.

I think maybe the part you're missing is the underlying culture of Maven. If I need an artifact, you type it in a repository search, hit enter and bingo, the dependency appears in your pom. It takes care of downloading all of its transitive dependenies. I don't have to worry about getting latest version of the dependencies, fixed versions.... If it's a released artifact, I get fixed... if its snapshot, I get the latest. I don't have to look on the internet and waste a whole bunch of time. It makes a devs life much faster and much easier.

Maven is able to do this I think in large part due to the fact that version information about the artifact is right in the pom. However, I feel the cost is that Maven doesn't really support CD very well.

> All I'm doing is adding some more metadata (in the form of
> changing
> the names, doing tagging, or whatever)

How does your build know about this extra metadata?  Where are you going to store it?

A version of 1.0-SNAPSHOT simply means latest 1.0 version. Nice, clean and simple. If you want a fixed version you say 1.0-01. Again, nice clean and simple.

You can't store both in the pom file. Not without having to constantly change the pom file to always point to the latest.

So you'd have to store latest information elsewhere and store that in source control. There is currently no mechanism for this. But one could write their own plugin to do it. It would be kind of "hacky" in my mind but I am sure possible.

I think the best place to store this information is in the binary itself. That will allow you to recreate any build.

> 
> 
> > When I say meta data here, I am referring to the meta data maven stores
> > about the artifact. This information doesn't appear in the pom.
> >
> 
> I must admit my ignorance here - I thought Maven stored metadata about
> the
> artifact in the form of pom files (e.g. this one:
> http://repo2.maven.org/maven2/HTTPClient/HTTPClient/0.3-3/HTTPClient-0.3-
> 3.pom
> )

That is an example released artifact. And you'll only find released artifacts up on maven central (intentionally as this what is published for wide consumption). Snapshot repos and release repos are quite different. They are not even stored in the same way or same place.

Here is an example snapshot folder:

https://repository.apache.org/content/repositories/maven-snapshots-sonatype/org/apache/maven/maven-core/3.0-SNAPSHOT/

You reference a snapshot dependency by using a version of 3.0-SNAPSHOT.

You will notice a file here called maven-metadata.xml. This is the metadata I was referring to earlier. This metadata is also structured differently than release metadata.

So to really do what you are asking I think it would be a core change to the maven architecture. You would have to merge the concept of snapshot and releases which I don't think would be trivial.
 
> However when the build artifact is created as part of the CI process, the
> pom that is created with it also includes the information about exactly
> which versions of these snapshots were used, including the version in
> version control they were created from.

Unfortunately (or fortunately, depending on your perspective) it doesn't. Not for snapshots. And intentionally so. The whole idea is that you are working off the latest, not a specific version. If you are storing this information in source control (whether it's the pom or in its own file) then you have to somehow constantly change that information to always point to the latest. I don't think there is logically away around that ;-).



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[jhumble <je...@jezhumble.net>]

Hi Todd.


> Ok. I will refocus here. Let me just say that this discussion is
> inevitable. It is important as the value of CD will help determine if Maven
> should consider working towards supporting this kind of process.  The basic
> architecture of Maven today does not lend well to it.  So we can table it
> for now. You comments I think took what I am trying to get across very much
> out of context but *snip* them for now and defer the discussion to a later
> date.
>

My apologies - I realize it's somewhat unfair of me to say I don't want to
discuss the value proposition any more and then dissect a bunch of what you
said. I guess I have been explaining the value proposition quite a lot
recently and would like to get back to some more technical stuff, but that
is my problem, not yours. Having said that, I wrote something which you may
find interesting here:
http://www.informit.com/articles/article.aspx?p=1641923 - it has a bunch of
links to other stuff too.


> The final artifacts and all the meta do not represent what is considered a
> released artifact.  The meta data is different and the artifact names are
> different. So the release process would have to "massage" the snapshot
> artifacts to "look" like releases. This will of course invalidate much of
> the testing done by your CI.
>

So long as I don't change the actual binaries, how does this invalidate the
testing? All I'm doing is adding some more metadata (in the form of changing
the names, doing tagging, or whatever)


> When I say meta data here, I am referring to the meta data maven stores
> about the artifact. This information doesn't appear in the pom.
>

I must admit my ignorance here - I thought Maven stored metadata about the
artifact in the form of pom files (e.g. this one:
http://repo2.maven.org/maven2/HTTPClient/HTTPClient/0.3-3/HTTPClient-0.3-3.pom
)


> Also if you do this you will be breaking the idea of CI. If your
> dependencies point to specific time stamp then that build won't be getting
> the latest version of those dependencies. You'd need some process to
> constantly update the pom to always point to the latest version of all your
> dependencies.  This I think would be fairly complex as your pom files would
> be constantly changing, even if you as a developer didn't need to change it.
>
>

So the idea is that the pom files for the build just point to the upstream
snapshot as happens right now.

However when the build artifact is created as part of the CI process, the
pom that is created with it also includes the information about exactly
which versions of these snapshots were used, including the version in
version control they were created from.

You can then re-use the same binaries you created from CI throughout the
rest of your delivery process.

-- 
Jez Humble
Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
http://continuousdelivery.com/
http://jezhumble.net/

-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3255684.html
Sent from the Maven - Users mailing list archive at Nabble.com.

Re: RE: Continuous Delivery and Maven

[stug23 <pa...@gmail.com>]

Stephen's solution makes sense to me. It doesn't try to conflate the meaning
of SNAPSHOTs and it retains the metadata in trunk that keeps everything in
the Maven build instead of relying on an outside tool.

Anyone see any issues with this approach? I think I like it from what I
understand so far.

Thanks!

-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3257778.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Yanko, Curtis" <cu...@uhc.com>]

 This was precisely where I was headed.

I was thinking about using version ranges in depMgmnt and *burning lots
of versions in the CI process but having a release plugin that ID's the
version retrieved and re-wrote the POM to be version specific at package
time.

I'm drawn to the idea of using an all Maven solution as opposed to
relying on extracting meta-data from an SCC tool or even a Maven Repo.
Between the help:effective-pom and the dependency-resolve plugins we
should be able to retrieve all of the info we need to packed a fully
baked POM into the artifact itself.


________________________________

Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
Making IT Happen, one build at a time, 600 times a day

-----Original Message-----
From: stug23 [mailto:pat.podenski@gmail.com] 
Sent: Monday, November 08, 2010 2:21 PM
To: users@maven.apache.org
Subject: Re: Continuous Delivery and Maven


We need to figure out how to best leverage Maven (keeping in mind its
process and practices) in a Continuous Delivery solution. I like the
conversation around this topic and also see that there is this other
discussion about the meaning of CD versus CI.

>From the comments so far, there has been a fair amount of discussion
about how to use SNAPSHOTs as if they were something that they aren't.
Namely retaining SNAPSHOTs all the way through release, possibly
mutating the metadata to make the builds products look like released
artifacts instead of SNAPSHOTs without having to rebuild the binaries.
Since a SNAPSHOT works well for a "work in progress" and not for a
"thing I want to keep", maybe a different approach would work better.

Maybe it would make more sense to just burn lots of version numbers
(e.g,
3.5.1099) and always release with a new yet-to-be-defined Maven release
plugin that reflects the processes involved with CD. If the concern is
disk usage or inefficiency, perhaps some automation can make this more
manageable?

I would be interested in inputs on this topic from the Maven founders if
they are following this thread.
--
View this message in context:
http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370
p3255592.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: RE: Continuous Delivery and Maven

["Thiessen, Todd (Todd)" <tt...@avaya.com>]

I am not entirely sure what Jason means when he says "pluck the snapshot out and promote it to a release repository". I think he still means rebuild it from source but I agree that that statement is a bit unclear.

The release plugin, by default, builds twice. First it checks out the code as a snapshot. Then it creates the tag, checks out the tag and then rebuilds and deploys that. This is the final released artifact.

As Jason mentioned, a lot of people don't want the release process to build twice. So they skip the initial build of the snapshot and skip directly to the building of the tag and the release. If you could somehow identify the revison of what snapshot you wanted, you could check out and rebuild that as a release. I "think" this is what Jason means by "plucking" but he would have confirm that.

This isn't a "promotion" of the snapshot per ce. It still completely rebuilds the artifact from source. It just doesn't rebuild it twice.

But this is also I think different from what Stephen is proposing. I think what you are looking for is to skip, or at least ignore, the building of snapshots entirely. So with Stephen's idea, by adding a "ship" phase to the lifecycle, you would always be doing some kind of command like:

mvn ship

You would bind a modified release plugin to this phase to always build a release. You may want to even consider overriding the deploy phase to do nothing, or even overriding the deploy phase to ship and not even worry about adding a ship phase to the lifecycle.

What is missing, that you were asking for, is being able to use snapshot dependencies that are not in the reactor. Stephen was thinking that this wasn't very important, but I was under the impression that you felt it was.

I also read through the blog. I tend to agree that the release process of Maven is a bit more complicated than it needs to be. There is a strict seperation between snapshots and releases which I think is the primary cause. There are likely reasons for it and I would love for a guy like Jason van Zyl (the Maven founder) to provide some insight or history here. Or even another comment on the blog you linked. For example elaborate on the comment:

"I believe the separation of snapshot and release repositories are required"

>From my understanding, to really embrace CD, there would have to be no difference between a snapshot and a release.

> -----Original Message-----
> From: jhumble [mailto:jez@jezhumble.net]
> Sent: Wednesday, November 10, 2010 12:47 PM
> To: users@maven.apache.org
> Subject: Re: RE: Continuous Delivery and Maven
> 
> 
> Hey Todd.
> 
> My interpretation of what Jason is saying in his comment here -
> http://www.lucasward.net/2010/11/maven-and-continuous-delivery.html -
> "you
> should be able to tag the code, and pluck the snapshot out and promote it
> to
> a release repository... Someone just needs to do the two weeks of work to
> add the tooling." is that this is exactly what he's saying. I'm going to
> have a nose around the code and see if I think I can take a shot at it.
> 
> Thanks,
> 
> Jez.
> 
> On 10 November 2010 05:51, Thiessen, Todd (Todd) [via Maven] <
> ml-node+3258691-1180604705-143561@n5.nabble.com<ml-node%2B3258691-
> 1180604705-143561@n5.nabble.com>
> > wrote:
> 
> > Agreed Stephen. I think your proposal is the best so far. I just want
> to
> > make sure we don't go back into a discussion about promoting snapshots
> to
> > releases, as I believe that is where this discussion started.  To do
> that I
> > think would require a significant re-architecture of maven which I
> don't
> > think would be happening in the near future.
> >
> > > -----Original Message-----
> > > From: Stephen Connolly [mailto:[hidden
> email]<http://user/SendEmail.jtp?type=node&node=3258691&i=0>]
> >
> > > Sent: Wednesday, November 10, 2010 8:29 AM
> > > To: Maven Users List
> > > Subject: Re: RE: Continuous Delivery and Maven
> > >
> > > Imho taking a snapshot artefact and renaming as a release artefact
> and
> > > pushing to the remote repo will never be supported by maven, but my
> > > ship-maven-plugin (not ready for publishing yet) and some extra mojos
> > > added
> > > to versions-maven-plugin should enable CD in a way that is in keeping
> > > with
> > > the "maven way", as long as ranges are used in place of snapshots.
> (will
> > > also need minor tweaks to the maven-release-plugin, but these would
> be
> > > backwards compatible tweaks that do not change its current behaviour,
> > > only
> > > provide a hook for extending it)
> > >
> > > - Stephen
> > >
> > > On 10 Nov 2010 13:03, "Thiessen, Todd (Todd)" <[hidden
> email]<http://user/SendEmail.jtp?type=node&node=3258691&i=1>>
> >
> > > wrote:
> > >
> > > I don't think thats the same thing. The proposal is to take a
> snapshot
> > > artifact which was built using mvn deploy and promote it to the
> release
> > > repo. I think what you are referring to here Jason is how the release
> > > plugin
> > > first builds the snapshot, tags it, and then rebuilds the tag.
> > >
> > >
> > > > -----Original Message-----
> > > > From: Jason van Zyl [mailto:[hidden
> email]<http://user/SendEmail.jtp?type=node&node=3258691&i=2>]
> >
> > > > Sent: Wednesday, Nove...
> > >
> > > > Subject: Re: Continuous Delivery and Maven
> > > >
> > > >
> > > > On Nov 9, 2010, at 2:25 PM, Thiessen, Todd (Tod...
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden
> email]<http://user/SendEmail.jtp?type=node&node=3258691&i=3>
> > For additional commands, e-mail: [hidden
> email]<http://user/SendEmail.jtp?type=node&node=3258691&i=4>
> >
> >
> >
> > ------------------------------
> >  View message @
> > http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-
> tp3245370p3258691.html
> > To unsubscribe from Continuous Delivery and Maven, click
> here<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubsc
> ribe_by_code&node=3245370&code=amV6QGplemh1bWJsZS5uZXR8MzI0NTM3MHwtMTg4Mj
> M1NzMyNA==>.
> >
> >
> >
> 
> 
> --
> Jez Humble
> Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
> http://continuousdelivery.com/
> http://jezhumble.net/
> 
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-
> tp3245370p3259078.html
> Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: RE: Continuous Delivery and Maven

[jhumble <je...@jezhumble.net>]

Hey Todd.

My interpretation of what Jason is saying in his comment here -
http://www.lucasward.net/2010/11/maven-and-continuous-delivery.html - "you
should be able to tag the code, and pluck the snapshot out and promote it to
a release repository... Someone just needs to do the two weeks of work to
add the tooling." is that this is exactly what he's saying. I'm going to
have a nose around the code and see if I think I can take a shot at it.

Thanks,

Jez.

On 10 November 2010 05:51, Thiessen, Todd (Todd) [via Maven] <
ml-node+3258691-1180604705-143561@n5.nabble.com<ml...@n5.nabble.com>
> wrote:

> Agreed Stephen. I think your proposal is the best so far. I just want to
> make sure we don't go back into a discussion about promoting snapshots to
> releases, as I believe that is where this discussion started.  To do that I
> think would require a significant re-architecture of maven which I don't
> think would be happening in the near future.
>
> > -----Original Message-----
> > From: Stephen Connolly [mailto:[hidden email]<http://user/SendEmail.jtp?type=node&node=3258691&i=0>]
>
> > Sent: Wednesday, November 10, 2010 8:29 AM
> > To: Maven Users List
> > Subject: Re: RE: Continuous Delivery and Maven
> >
> > Imho taking a snapshot artefact and renaming as a release artefact and
> > pushing to the remote repo will never be supported by maven, but my
> > ship-maven-plugin (not ready for publishing yet) and some extra mojos
> > added
> > to versions-maven-plugin should enable CD in a way that is in keeping
> > with
> > the "maven way", as long as ranges are used in place of snapshots. (will
> > also need minor tweaks to the maven-release-plugin, but these would be
> > backwards compatible tweaks that do not change its current behaviour,
> > only
> > provide a hook for extending it)
> >
> > - Stephen
> >
> > On 10 Nov 2010 13:03, "Thiessen, Todd (Todd)" <[hidden email]<http://user/SendEmail.jtp?type=node&node=3258691&i=1>>
>
> > wrote:
> >
> > I don't think thats the same thing. The proposal is to take a snapshot
> > artifact which was built using mvn deploy and promote it to the release
> > repo. I think what you are referring to here Jason is how the release
> > plugin
> > first builds the snapshot, tags it, and then rebuilds the tag.
> >
> >
> > > -----Original Message-----
> > > From: Jason van Zyl [mailto:[hidden email]<http://user/SendEmail.jtp?type=node&node=3258691&i=2>]
>
> > > Sent: Wednesday, Nove...
> >
> > > Subject: Re: Continuous Delivery and Maven
> > >
> > >
> > > On Nov 9, 2010, at 2:25 PM, Thiessen, Todd (Tod...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3258691&i=3>
> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3258691&i=4>
>
>
>
> ------------------------------
>  View message @
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3258691.html
> To unsubscribe from Continuous Delivery and Maven, click here<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_code&node=3245370&code=amV6QGplemh1bWJsZS5uZXR8MzI0NTM3MHwtMTg4MjM1NzMyNA==>.
>
>
>


-- 
Jez Humble
Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
http://continuousdelivery.com/
http://jezhumble.net/

-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3259078.html
Sent from the Maven - Users mailing list archive at Nabble.com.

RE: RE: Continuous Delivery and Maven

["Thiessen, Todd (Todd)" <tt...@avaya.com>]

Agreed Stephen. I think your proposal is the best so far. I just want to make sure we don't go back into a discussion about promoting snapshots to releases, as I believe that is where this discussion started.  To do that I think would require a significant re-architecture of maven which I don't think would be happening in the near future.

> -----Original Message-----
> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> Sent: Wednesday, November 10, 2010 8:29 AM
> To: Maven Users List
> Subject: Re: RE: Continuous Delivery and Maven
> 
> Imho taking a snapshot artefact and renaming as a release artefact and
> pushing to the remote repo will never be supported by maven, but my
> ship-maven-plugin (not ready for publishing yet) and some extra mojos
> added
> to versions-maven-plugin should enable CD in a way that is in keeping
> with
> the "maven way", as long as ranges are used in place of snapshots. (will
> also need minor tweaks to the maven-release-plugin, but these would be
> backwards compatible tweaks that do not change its current behaviour,
> only
> provide a hook for extending it)
> 
> - Stephen
> 
> On 10 Nov 2010 13:03, "Thiessen, Todd (Todd)" <tt...@avaya.com>
> wrote:
> 
> I don't think thats the same thing. The proposal is to take a snapshot
> artifact which was built using mvn deploy and promote it to the release
> repo. I think what you are referring to here Jason is how the release
> plugin
> first builds the snapshot, tags it, and then rebuilds the tag.
> 
> 
> > -----Original Message-----
> > From: Jason van Zyl [mailto:jason@maven.org]
> > Sent: Wednesday, Nove...
> 
> > Subject: Re: Continuous Delivery and Maven
> >
> >
> > On Nov 9, 2010, at 2:25 PM, Thiessen, Todd (Tod...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: RE: Continuous Delivery and Maven

[Stephen Connolly <st...@gmail.com>]

Imho taking a snapshot artefact and renaming as a release artefact and
pushing to the remote repo will never be supported by maven, but my
ship-maven-plugin (not ready for publishing yet) and some extra mojos added
to versions-maven-plugin should enable CD in a way that is in keeping with
the "maven way", as long as ranges are used in place of snapshots. (will
also need minor tweaks to the maven-release-plugin, but these would be
backwards compatible tweaks that do not change its current behaviour, only
provide a hook for extending it)

- Stephen

On 10 Nov 2010 13:03, "Thiessen, Todd (Todd)" <tt...@avaya.com> wrote:

I don't think thats the same thing. The proposal is to take a snapshot
artifact which was built using mvn deploy and promote it to the release
repo. I think what you are referring to here Jason is how the release plugin
first builds the snapshot, tags it, and then rebuilds the tag.


> -----Original Message-----
> From: Jason van Zyl [mailto:jason@maven.org]
> Sent: Wednesday, Nove...

> Subject: Re: Continuous Delivery and Maven
>
>
> On Nov 9, 2010, at 2:25 PM, Thiessen, Todd (Tod...

RE: Continuous Delivery and Maven

["Thiessen, Todd (Todd)" <tt...@avaya.com>]

I don't think thats the same thing. The proposal is to take a snapshot artifact which was built using mvn deploy and promote it to the release repo. I think what you are referring to here Jason is how the release plugin first builds the snapshot, tags it, and then rebuilds the tag.

> -----Original Message-----
> From: Jason van Zyl [mailto:jason@maven.org]
> Sent: Wednesday, November 10, 2010 5:44 AM
> To: Maven Users List
> Subject: Re: Continuous Delivery and Maven
> 
> 
> On Nov 9, 2010, at 2:25 PM, Thiessen, Todd (Todd) wrote:
> 
> > +1 here. Jez was indicating that it was "Crucial" that a snapshot build
> not get "rebuilt" when creating the release and simply get promoted to a
> release. That is simply not that way maven currently works. I hope that
> is now clear.
> >
> 
> Has nothing to do with Maven per se, this is just the way the Maven
> Release Plugin works. It doesn't mean it's the only way it can work. I
> know lots of of people who have re-implmented all or parts of the release
> plugin to prevent rebuilding.
> 
> > I do like the idea though of rebuilting a CD build after a successful
> CI build. I think that has potential.
> >
> >> -----Original Message-----
> >> From: stug23 [mailto:pat.podenski@gmail.com]
> >> Sent: Monday, November 08, 2010 2:21 PM
> >> To: users@maven.apache.org
> >> Subject: Re: Continuous Delivery and Maven
> >>
> >>
> >> We need to figure out how to best leverage Maven (keeping in mind its
> >> process
> >> and practices) in a Continuous Delivery solution. I like the
> conversation
> >> around this topic and also see that there is this other discussion
> about
> >> the
> >> meaning of CD versus CI.
> >>
> >> From the comments so far, there has been a fair amount of discussion
> >> about
> >> how to use SNAPSHOTs as if they were something that they aren't.
> Namely
> >> retaining SNAPSHOTs all the way through release, possibly mutating the
> >> metadata to make the builds products look like released artifacts
> instead
> >> of
> >> SNAPSHOTs without having to rebuild the binaries. Since a SNAPSHOT
> works
> >> well for a "work in progress" and not for a "thing I want to keep",
> maybe
> >> a
> >> different approach would work better.
> >>
> >> Maybe it would make more sense to just burn lots of version numbers
> (e.g,
> >> 3.5.1099) and always release with a new yet-to-be-defined Maven
> release
> >> plugin that reflects the processes involved with CD. If the concern is
> >> disk
> >> usage or inefficiency, perhaps some automation can make this more
> >> manageable?
> >>
> >> I would be interested in inputs on this topic from the Maven founders
> if
> >> they are following this thread.
> >> --
> >> View this message in context:
> >> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-
> >> tp3245370p3255592.html
> >> Sent from the Maven - Users mailing list archive at Nabble.com.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> 
> Thanks,
> 
> Jason
> 
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
> 
> What matters is not ideas, but the people who have them. Good people can
> fix bad ideas, but good ideas can't save bad people.
> 
>  -- Paul Graham
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[Jason van Zyl <ja...@maven.org>]

On Nov 9, 2010, at 2:25 PM, Thiessen, Todd (Todd) wrote:

> +1 here. Jez was indicating that it was "Crucial" that a snapshot build not get "rebuilt" when creating the release and simply get promoted to a release. That is simply not that way maven currently works. I hope that is now clear.
> 

Has nothing to do with Maven per se, this is just the way the Maven Release Plugin works. It doesn't mean it's the only way it can work. I know lots of of people who have re-implmented all or parts of the release plugin to prevent rebuilding.

> I do like the idea though of rebuilting a CD build after a successful CI build. I think that has potential.
> 
>> -----Original Message-----
>> From: stug23 [mailto:pat.podenski@gmail.com]
>> Sent: Monday, November 08, 2010 2:21 PM
>> To: users@maven.apache.org
>> Subject: Re: Continuous Delivery and Maven
>> 
>> 
>> We need to figure out how to best leverage Maven (keeping in mind its
>> process
>> and practices) in a Continuous Delivery solution. I like the conversation
>> around this topic and also see that there is this other discussion about
>> the
>> meaning of CD versus CI.
>> 
>> From the comments so far, there has been a fair amount of discussion
>> about
>> how to use SNAPSHOTs as if they were something that they aren't. Namely
>> retaining SNAPSHOTs all the way through release, possibly mutating the
>> metadata to make the builds products look like released artifacts instead
>> of
>> SNAPSHOTs without having to rebuild the binaries. Since a SNAPSHOT works
>> well for a "work in progress" and not for a "thing I want to keep", maybe
>> a
>> different approach would work better.
>> 
>> Maybe it would make more sense to just burn lots of version numbers (e.g,
>> 3.5.1099) and always release with a new yet-to-be-defined Maven release
>> plugin that reflects the processes involved with CD. If the concern is
>> disk
>> usage or inefficiency, perhaps some automation can make this more
>> manageable?
>> 
>> I would be interested in inputs on this topic from the Maven founders if
>> they are following this thread.
>> --
>> View this message in context:
>> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-
>> tp3245370p3255592.html
>> Sent from the Maven - Users mailing list archive at Nabble.com.
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. 

 -- Paul Graham

RE: Continuous Delivery and Maven

["Thiessen, Todd (Todd)" <tt...@avaya.com>]

+1 here. Jez was indicating that it was "Crucial" that a snapshot build not get "rebuilt" when creating the release and simply get promoted to a release. That is simply not that way maven currently works. I hope that is now clear.

I do like the idea though of rebuilting a CD build after a successful CI build. I think that has potential.

> -----Original Message-----
> From: stug23 [mailto:pat.podenski@gmail.com]
> Sent: Monday, November 08, 2010 2:21 PM
> To: users@maven.apache.org
> Subject: Re: Continuous Delivery and Maven
> 
> 
> We need to figure out how to best leverage Maven (keeping in mind its
> process
> and practices) in a Continuous Delivery solution. I like the conversation
> around this topic and also see that there is this other discussion about
> the
> meaning of CD versus CI.
> 
> From the comments so far, there has been a fair amount of discussion
> about
> how to use SNAPSHOTs as if they were something that they aren't. Namely
> retaining SNAPSHOTs all the way through release, possibly mutating the
> metadata to make the builds products look like released artifacts instead
> of
> SNAPSHOTs without having to rebuild the binaries. Since a SNAPSHOT works
> well for a "work in progress" and not for a "thing I want to keep", maybe
> a
> different approach would work better.
> 
> Maybe it would make more sense to just burn lots of version numbers (e.g,
> 3.5.1099) and always release with a new yet-to-be-defined Maven release
> plugin that reflects the processes involved with CD. If the concern is
> disk
> usage or inefficiency, perhaps some automation can make this more
> manageable?
> 
> I would be interested in inputs on this topic from the Maven founders if
> they are following this thread.
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-
> tp3245370p3255592.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[jmorrow <jo...@morrowmail.com>]

I think this is an area where NexusPro or the concept of a staging repository
can be helpful. You gladly burn version numbers all through the dev process
and at some point promote a version to the staging repo for "blessed"
deployment. I am not trying to impose a specific point in the pipeline where
this happens, as I think the is organizational. With this model you keep
your non-staging repo small by cleaning up old artifacts on a regular
schedule.

Essentially you treat the non-staging repo as snapshots within your
organization. With in a team I suppose you could continue to use snapshots.

Granted this approach would require slight different deployment scrips based
on environment, but they could use the same mechanism to deploy which I
think is the heart of CD.
-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3255916.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Thiessen, Todd (Todd)" <tt...@avaya.com>]

Staging is definitely helpful and I don't think it satisfies what Jez is looking for. As far as my understanding goes, NexusPro staging does not promote a snapshot to a release. Rather is simply allows you to stage a release in a repo that is not publicly visible so you can test it. Once your testing passes, you promote to a public place.

This ensures there is no massaging of the repository layout or the names of the artifacts.

> -----Original Message-----
> From: jmorrow [mailto:jon@morrowmail.com]
> Sent: Monday, November 08, 2010 6:01 PM
> To: users@maven.apache.org
> Subject: Re: Continuous Delivery and Maven
> 
> 
> I think this is an area where NexusPro or the concept of a staging
> repository
> can be helpful. You gladly burn version numbers all through the dev
> process
> and at some point promote a version to the staging repo for "blessed"
> deployment. I am not trying to impose a specific point in the pipeline
> where
> this happens, as I think the is organizational. With this model you keep
> your non-staging repo small by cleaning up old artifacts on a regular
> schedule.
> 
> Essentially you treat the non-staging repo as snapshots within your
> organization. With in a team I suppose you could continue to use
> snapshots.
> 
> Granted this approach would require slight different deployment scrips
> based
> on environment, but they could use the same mechanism to deploy which I
> think is the heart of CD.
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-
> tp3245370p3255954.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[jmorrow <jo...@morrowmail.com>]

I think this is an area where NexusPro or the concept of a staging repository
can be helpful. You gladly burn version numbers all through the dev process
and at some point promote a version to the staging repo for "blessed"
deployment. I am not trying to impose a specific point in the pipeline where
this happens, as I think the is organizational. With this model you keep
your non-staging repo small by cleaning up old artifacts on a regular
schedule.

Essentially you treat the non-staging repo as snapshots within your
organization. With in a team I suppose you could continue to use snapshots.

Granted this approach would require slight different deployment scrips based
on environment, but they could use the same mechanism to deploy which I
think is the heart of CD.
-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3255954.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[Hilco Wijbenga <hi...@gmail.com>]

On 24 November 2010 10:27, Stephen Connolly
<st...@gmail.com> wrote:
> http://mojo.codehaus.org/ship-maven-plugin
>
> Let me know what you think?

FYI, the links to "Re-deploying an old version" do not seem to work.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: RE: Continuous Delivery and Maven

[Stephen Connolly <st...@gmail.com>]

OK that one is done now r1039453...

I'll see what the story is about pushing a release of m-r-p soonish...

Last step is the v-m-p...

-Stephen

On 25 November 2010 16:14, Stephen Connolly <stephen.alan.connolly@gmail.com
> wrote:

> http://jira.codehaus.org/browse/MRELEASE-621 will be needed to get the
> hooks in place for v-m-p... once I have that done (and pushed a m-r-p
> release) then I will do the v-m-p stuff (assuming I have got v-m-p's
> integration tests portable by then!)
>
> -Stephen
>
>
> On 24 November 2010 20:02, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> That's an enhancement to versions-maven-plugin
>>
>> This is the hook for deployment (aka shipping)
>>
>> - Stephen
>>
>> ---
>> Sent from my Android phone, so random spelling mistakes are a direct
>> result of using swype to type on the screen
>>
>> On 24 Nov 2010 18:45, "Yanko, Curtis" <cu...@uhc.com> wrote:
>>
>> I though the idea we talked about was to re-write the POM that get's
>> packaged with the actual version used from a version range?
>>
>> ________________________________
>>
>> Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
>> Making IT Happen, one build at a time, 600 times a day
>>
>>
>>
>> > -----Original Message-----
>> > From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
>> >...
>> This e-mail, including attachments, may include confidential and/or
>> proprietary information, and may be used only by the person or entity
>> to which it is addressed. If the reader of this e-mail is not the intended
>> recipient or his or her authorized agent, the reader is hereby notified
>> that any dissemination, distribution or copying of this e-mail is
>> prohibited. If you have received this e-mail in error, please notify the
>> sender by replying to this message and delete this e-mail immediately.
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user...
>>
>>
>

Re: RE: Continuous Delivery and Maven

[Stephen Connolly <st...@gmail.com>]

http://jira.codehaus.org/browse/MRELEASE-621 will be needed to get the hooks
in place for v-m-p... once I have that done (and pushed a m-r-p release)
then I will do the v-m-p stuff (assuming I have got v-m-p's integration
tests portable by then!)

-Stephen

On 24 November 2010 20:02, Stephen Connolly <stephen.alan.connolly@gmail.com
> wrote:

> That's an enhancement to versions-maven-plugin
>
> This is the hook for deployment (aka shipping)
>
> - Stephen
>
> ---
> Sent from my Android phone, so random spelling mistakes are a direct result
> of using swype to type on the screen
>
> On 24 Nov 2010 18:45, "Yanko, Curtis" <cu...@uhc.com> wrote:
>
> I though the idea we talked about was to re-write the POM that get's
> packaged with the actual version used from a version range?
>
> ________________________________
>
> Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
> Making IT Happen, one build at a time, 600 times a day
>
>
>
> > -----Original Message-----
> > From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> >...
> This e-mail, including attachments, may include confidential and/or
> proprietary information, and may be used only by the person or entity
> to which it is addressed. If the reader of this e-mail is not the intended
> recipient or his or her authorized agent, the reader is hereby notified
> that any dissemination, distribution or copying of this e-mail is
> prohibited. If you have received this e-mail in error, please notify the
> sender by replying to this message and delete this e-mail immediately.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user...
>
>

Re: RE: Continuous Delivery and Maven

[Stephen Connolly <st...@gmail.com>]

That's an enhancement to versions-maven-plugin

This is the hook for deployment (aka shipping)

- Stephen

---
Sent from my Android phone, so random spelling mistakes are a direct result
of using swype to type on the screen

On 24 Nov 2010 18:45, "Yanko, Curtis" <cu...@uhc.com> wrote:

I though the idea we talked about was to re-write the POM that get's
packaged with the actual version used from a version range?

________________________________

Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time, 600 times a day



> -----Original Message-----
> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
>...
This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.



---------------------------------------------------------------------
To unsubscribe, e-mail: user...

RE: Continuous Delivery and Maven

["Yanko, Curtis" <cu...@uhc.com>]

I though the idea we talked about was to re-write the POM that get's
packaged with the actual version used from a version range?

________________________________

Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
Making IT Happen, one build at a time, 600 times a day
 

> -----Original Message-----
> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com] 
> Sent: Wednesday, November 24, 2010 1:28 PM
> To: Maven Users List
> Subject: Re: Continuous Delivery and Maven
> 
> http://mojo.codehaus.org/ship-maven-plugin
> 
> Let me know what you think?
> 
> -stephen
> 
> On 9 November 2010 09:24, Stephen Connolly
> <st...@gmail.com>wrote:
> 
> > I think some of the issues are around missuse of Maven.
> >
> > Maven is a build tool, use it to do your build.
> >
> > CD needs a separate layer above Maven to do the 
> deployment... now one 
> > could use maven plugins to provide that layer, but there are two 
> > issues I see:
> >
> > 1. the maven lifecycle does not include the phases you require
> >
> > 2. inbetween invokations of maven, we have no means to share state
> >
> > so lets say for #1 we add a phase of "ship"... we'd have 
> the standard 
> > lifecycle something like
> >
> > validate -> ... -> compile -> ... -> test -> ... -> package 
> -> ... -> 
> > verify -> install -> deploy -> ship
> >
> > that would allow us to bind our CD steps to the "ship" 
> phase... ok, so 
> > people would have to get used to the fact that Maven uses 
> "deploy" to 
> > mean "copy artifact to remote maven repo" and not the CD meaning of 
> > deploy... but people can "Just Get Over It(TM)"
> >
> > that allows any build to just go
> >
> > mvn clean ship
> >
> > and away we go... except that we would be dealing with -SNAPSHOTs...
> >
> > so to correct for that we would change the release goals using the 
> > release plugin to be "ship" in place of deploy... to gain speed (at 
> > the expense of better tested releases), we could even modify the 
> > preparation goals using the release plugin to be just 
> "clean validate"
> > and not "clean verify"
> >
> > then
> >
> > mvn release:prepare
> >
> > would be quick
> >
> > mvn release:perform
> >
> > would do the CD
> >
> > Hmmmm... most of this is actually fine for CD, and we don't even 
> > really need the "ship" phase as we could just bind to the 
> deploy phase 
> > using the release profile to ensure that it only takes 
> place during a 
> > release...
> >
> > The down side is we have no way to roll-back easily....
> >
> > e.g. we've just released 2.1.5652 but we have egg on our 
> face due to 
> > an automated QA test that is giving a false pass... we have 
> no way to 
> > revert back to 2.1.5651 except:
> >  A. to revert the commits and roll a new release  B. put in the 
> > 2.1.5651 artifact by hand
> >
> > we can check-out the tag for 2.1.5651 and run "mvn ship -DskipTests"
> > or "mvn deploy -Prelease -DskipTests" depending on whether 
> we actually 
> > got the "ship" phase into the standard lifecycle or whether we just 
> > used the release profile to bind to the deploy phase.... but at the 
> > end of the day, that would be rebuilding the binaries... 
> which (with a 
> > strict QA hat on) invalidates testing...
> >
> > I think what you need to do is have a maven-ship-plugin or a 
> > ship-maven-plugin that works a little like this:
> >
> > it takes a parameter shipVersion which by default evaluates the 
> > property shipVersion, but if that property is not defines then 
> > defaults to ${project.version}
> >
> > The m-s-p then resolves the shipVersion of the project artifact and 
> > passes that file onto a ship script...
> >
> > so if I have a war project foo:bar:1.0-SNAPSHOT:war
> >
> > mvn ship:ship -DshipVersion=1.0.56
> >
> > will redeploy the old version 1.0.56
> >
> > mvn package ship:ship
> >
> > will build the current source code and ship that
> >
> > mvn ship:ship
> >
> > will resolve the latest 1.0-SNAPSHOT from the local/remote 
> repos and 
> > ship that
> >
> > we could add a parameter allowSnapshots that will default 
> to false in 
> > order to prevent accidental deployment of non-releases
> >
> > and if you are doing CD you can bind ship:ship to the 
> deploy phase in 
> > your release profile.
> >
> > I think I'll knock something together @mojo to help with this
> >
> > On 8 November 2010 19:20, stug23 <pa...@gmail.com> wrote:
> > >
> > > We need to figure out how to best leverage Maven (keeping in mind 
> > > its
> > process
> > > and practices) in a Continuous Delivery solution. I like the 
> > > conversation around this topic and also see that there is 
> this other 
> > > discussion about
> > the
> > > meaning of CD versus CI.
> > >
> > > From the comments so far, there has been a fair amount of 
> discussion
> > about
> > > how to use SNAPSHOTs as if they were something that they aren't. 
> > > Namely retaining SNAPSHOTs all the way through release, possibly 
> > > mutating the metadata to make the builds products look 
> like released 
> > > artifacts instead
> > of
> > > SNAPSHOTs without having to rebuild the binaries. Since a 
> SNAPSHOT 
> > > works well for a "work in progress" and not for a "thing 
> I want to 
> > > keep", maybe
> > a
> > > different approach would work better.
> > >
> > > Maybe it would make more sense to just burn lots of 
> version numbers 
> > > (e.g,
> > > 3.5.1099) and always release with a new yet-to-be-defined Maven 
> > > release plugin that reflects the processes involved with 
> CD. If the 
> > > concern is
> > disk
> > > usage or inefficiency, perhaps some automation can make this more 
> > > manageable?
> > >
> > > I would be interested in inputs on this topic from the Maven 
> > > founders if they are following this thread.
> > > --
> > > View this message in context:
> > 
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32453
> > 70p3255592.html
> > > Sent from the Maven - Users mailing list archive at Nabble.com.
> > >
> > > 
> --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
> 

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[Stephen Connolly <st...@gmail.com>]

http://mojo.codehaus.org/ship-maven-plugin

Let me know what you think?

-stephen

On 9 November 2010 09:24, Stephen Connolly
<st...@gmail.com>wrote:

> I think some of the issues are around missuse of Maven.
>
> Maven is a build tool, use it to do your build.
>
> CD needs a separate layer above Maven to do the deployment... now one
> could use maven plugins to provide that layer, but there are two
> issues I see:
>
> 1. the maven lifecycle does not include the phases you require
>
> 2. inbetween invokations of maven, we have no means to share state
>
> so lets say for #1 we add a phase of "ship"... we'd have the standard
> lifecycle something like
>
> validate -> ... -> compile -> ... -> test -> ... -> package -> ... ->
> verify -> install -> deploy -> ship
>
> that would allow us to bind our CD steps to the "ship" phase... ok, so
> people would have to get used to the fact that Maven uses "deploy" to
> mean "copy artifact to remote maven repo" and not the CD meaning of
> deploy... but people can "Just Get Over It(TM)"
>
> that allows any build to just go
>
> mvn clean ship
>
> and away we go... except that we would be dealing with -SNAPSHOTs...
>
> so to correct for that we would change the release goals using the
> release plugin to be "ship" in place of deploy... to gain speed (at
> the expense of better tested releases), we could even modify the
> preparation goals using the release plugin to be just "clean validate"
> and not "clean verify"
>
> then
>
> mvn release:prepare
>
> would be quick
>
> mvn release:perform
>
> would do the CD
>
> Hmmmm... most of this is actually fine for CD, and we don't even
> really need the "ship" phase as we could just bind to the deploy phase
> using the release profile to ensure that it only takes place during a
> release...
>
> The down side is we have no way to roll-back easily....
>
> e.g. we've just released 2.1.5652 but we have egg on our face due to
> an automated QA test that is giving a false pass... we have no way to
> revert back to 2.1.5651 except:
>  A. to revert the commits and roll a new release
>  B. put in the 2.1.5651 artifact by hand
>
> we can check-out the tag for 2.1.5651 and run "mvn ship -DskipTests"
> or "mvn deploy -Prelease -DskipTests" depending on whether we actually
> got the "ship" phase into the standard lifecycle or whether we just
> used the release profile to bind to the deploy phase.... but at the
> end of the day, that would be rebuilding the binaries... which (with a
> strict QA hat on) invalidates testing...
>
> I think what you need to do is have a maven-ship-plugin or a
> ship-maven-plugin that works a little like this:
>
> it takes a parameter shipVersion which by default evaluates the
> property shipVersion, but if that property is not defines then
> defaults to ${project.version}
>
> The m-s-p then resolves the shipVersion of the project artifact and
> passes that file onto a ship script...
>
> so if I have a war project foo:bar:1.0-SNAPSHOT:war
>
> mvn ship:ship -DshipVersion=1.0.56
>
> will redeploy the old version 1.0.56
>
> mvn package ship:ship
>
> will build the current source code and ship that
>
> mvn ship:ship
>
> will resolve the latest 1.0-SNAPSHOT from the local/remote repos and ship
> that
>
> we could add a parameter allowSnapshots that will default to false in
> order to prevent accidental deployment of non-releases
>
> and if you are doing CD you can bind ship:ship to the deploy phase in
> your release profile.
>
> I think I'll knock something together @mojo to help with this
>
> On 8 November 2010 19:20, stug23 <pa...@gmail.com> wrote:
> >
> > We need to figure out how to best leverage Maven (keeping in mind its
> process
> > and practices) in a Continuous Delivery solution. I like the conversation
> > around this topic and also see that there is this other discussion about
> the
> > meaning of CD versus CI.
> >
> > From the comments so far, there has been a fair amount of discussion
> about
> > how to use SNAPSHOTs as if they were something that they aren't. Namely
> > retaining SNAPSHOTs all the way through release, possibly mutating the
> > metadata to make the builds products look like released artifacts instead
> of
> > SNAPSHOTs without having to rebuild the binaries. Since a SNAPSHOT works
> > well for a "work in progress" and not for a "thing I want to keep", maybe
> a
> > different approach would work better.
> >
> > Maybe it would make more sense to just burn lots of version numbers (e.g,
> > 3.5.1099) and always release with a new yet-to-be-defined Maven release
> > plugin that reflects the processes involved with CD. If the concern is
> disk
> > usage or inefficiency, perhaps some automation can make this more
> > manageable?
> >
> > I would be interested in inputs on this topic from the Maven founders if
> > they are following this thread.
> > --
> > View this message in context:
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3255592.html
> > Sent from the Maven - Users mailing list archive at Nabble.com.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>

RE: RE: Continuous Delivery and Maven

["Yanko, Curtis" <cu...@uhc.com>]

Ah! I missed that little nugget. 


________________________________

Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
Making IT Happen, one build at a time, 600 times a day

-----Original Message-----
From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com] 
Sent: Tuesday, November 09, 2010 4:10 PM
To: Maven Users List
Subject: Re: RE: Continuous Delivery and Maven

But if we do it my way, the tag has the resolved versions, while trunk
keeps the ranges... Best of all worlds ;-)

On 9 Nov 2010 16:21, "Yanko, Curtis" <cu...@uhc.com> wrote:

Because I thought we want to keep the version ranges in SCC for
developers and just package the POM fully versioned for that build.



________________________________

Curt Yanko | Continuous Integration Services | UnitedHealth Grou...

Sent: Tuesday, November 09, 2010 11:05 AM
To: Maven Users List
Subject: Re: Continuous Delivery and ...

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: RE: Continuous Delivery and Maven

[Stephen Connolly <st...@gmail.com>]

But if we do it my way, the tag has the resolved versions, while trunk keeps
the ranges... Best of all worlds ;-)

On 9 Nov 2010 16:21, "Yanko, Curtis" <cu...@uhc.com> wrote:

Because I thought we want to keep the version ranges in SCC for developers
and just package the POM fully versioned for that build.



________________________________

Curt Yanko | Continuous Integration Services | UnitedHealth Grou...

Sent: Tuesday, November 09, 2010 11:05 AM
To: Maven Users List
Subject: Re: Continuous Delivery and ...

RE: Continuous Delivery and Maven

["Yanko, Curtis" <cu...@uhc.com>]

Because I thought we want to keep the version ranges in SCC for developers and just package the POM fully versioned for that build.


________________________________

Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
Making IT Happen, one build at a time, 600 times a day

-----Original Message-----
From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com] 
Sent: Tuesday, November 09, 2010 11:05 AM
To: Maven Users List
Subject: Re: Continuous Delivery and Maven

Why bother... the checkin is automatic and actually a good thing IMHO

On 9 November 2010 15:37, Yanko, Curtis <cu...@uhc.com> wrote:
> What if you just avoid the check in?  Only package the pom and deploy the jar?
>
>
> ________________________________
>
> Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
> Making IT Happen, one build at a time, 600 times a day
>
> -----Original Message-----
> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> Sent: Tuesday, November 09, 2010 9:32 AM
> To: Maven Users List
> Subject: Re: Continuous Delivery and Maven
>
> On 9 November 2010 14:10, Thiessen, Todd (Todd) <tt...@avaya.com> wrote:
>> Hey Stephen. I read through your idea a little more closely and I like it.
>>
>> The only thing I think it is missing is the ability to use snapshots as dependencies. That is a very powerful feature of maven that I don't think you'd want to lose if your using CD.
>
> Well I regard that the project being delivered can only have internal -SNAPSHOT dependencies, all external (to the reactor) dependencies should be release dependencies.
>
> One of the things I have wanted to do with v-m-p is to hack around version ranges... for example...
>
> if we develop using
>
> <dependency>
>  <groupId>foo</groupId>
>  <artifactId>bar</artifactId>
>  <version>[1.0,2.0)</version>
> </dependency>
>
> when we run the preparation goals in release:prepare, we have the opertunity to modify the pom and have that modified pom checked in, so there is nothing stopping us from resolving the range, e.g.
>
> <dependency>
>  <groupId>foo</groupId>
>  <artifactId>bar</artifactId>
>  <version>1.1.3</version>
> </dependency>
>
> and now the tag is a locked down reproducible build.... but the developer is stuck with the locked down version...
>
> so, if somehow we can tweak things... stick in a comment... or better 
> yet an XML PI
>
> <dependency>
>  <groupId>foo</groupId>
>  <artifactId>bar</artifactId>
>  <version>1.1.3</version>
>  <?org.codehaus.mojo:versions-maven-plugin range="[1.0,2.0)"?> 
> </dependency>
>
> then all we need is a postReleaseGoals added to release:prepare and we can have v-m-p put the version ranges back in...
>
> Which would give you repeatable releases and bleeding edge dependencies... but only released dependencies.
>
> The problem with -SNAPSHOTs is that they can be deployed without having passed testing.
>
> MRM staging support is really about having atomic releases of multi-module artifacts, e.g. make sure they either all get deployed or none get deployed.
>
> -Stephen
>
>>
>> It is almost like you'd want a mode in Maven. Say you had some kind of flag that said "Continuous Delivery" mode. In this mode, you would only use release repositories when deploying artifacts or downloading artifacts. Nothing would ever get built as a snapshot, even if your pom has snapshot versions. In CD mode, you always use the latest release artifact of your dependencies. You could never pull artifacts from a snapshot repository in this mode.
>>
>> So, for example lets my project's version iss 1.0-SNAPSHOT. When I do:
>>
>> mvn deploy
>>
>> it would deploy release 1.0-0001 to the release repo.
>>
>> If my project had any snapshot dependencies, it wouldn't have to checkout and rebuild these. Those dependencies would also have to be in "CD mode" and all artifacts would have to be to the release repo. So if my project has a dependency on some artifact with version:
>>
>> 3.2-SNAPSHOT
>>
>> while in CD mode, maven would query the release repo, find the latest release artifact (say 3.2-0122) and use that.
>>
>> This would of course fill up your release repo but I think you would need to think of a release repo a little differently if your doing CD.
>>
>>> -----Original Message-----
>>> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
>>> Sent: Tuesday, November 09, 2010 4:24 AM
>>> To: Maven Users List
>>> Subject: Re: Continuous Delivery and Maven
>>>
>>> I think some of the issues are around missuse of Maven.
>>>
>>> Maven is a build tool, use it to do your build.
>>>
>>> CD needs a separate layer above Maven to do the deployment... now 
>>> one could use maven plugins to provide that layer, but there are two 
>>> issues I see:
>>>
>>> 1. the maven lifecycle does not include the phases you require
>>>
>>> 2. inbetween invokations of maven, we have no means to share state
>>>
>>> so lets say for #1 we add a phase of "ship"... we'd have the 
>>> standard lifecycle something like
>>>
>>> validate -> ... -> compile -> ... -> test -> ... -> package -> ... 
>>> -> verify -> install -> deploy -> ship
>>>
>>> that would allow us to bind our CD steps to the "ship" phase... ok, 
>>> so people would have to get used to the fact that Maven uses "deploy"
>>> to mean "copy artifact to remote maven repo" and not the CD meaning 
>>> of deploy... but people can "Just Get Over It(TM)"
>>>
>>> that allows any build to just go
>>>
>>> mvn clean ship
>>>
>>> and away we go... except that we would be dealing with -SNAPSHOTs...
>>>
>>> so to correct for that we would change the release goals using the 
>>> release plugin to be "ship" in place of deploy... to gain speed (at 
>>> the expense of better tested releases), we could even modify the 
>>> preparation goals using the release plugin to be just "clean validate"
>>> and not "clean verify"
>>>
>>> then
>>>
>>> mvn release:prepare
>>>
>>> would be quick
>>>
>>> mvn release:perform
>>>
>>> would do the CD
>>>
>>> Hmmmm... most of this is actually fine for CD, and we don't even 
>>> really need the "ship" phase as we could just bind to the deploy 
>>> phase using the release profile to ensure that it only takes place 
>>> during a release...
>>>
>>> The down side is we have no way to roll-back easily....
>>>
>>> e.g. we've just released 2.1.5652 but we have egg on our face due to 
>>> an automated QA test that is giving a false pass... we have no way 
>>> to revert back to 2.1.5651 except:
>>>  A. to revert the commits and roll a new release
>>>  B. put in the 2.1.5651 artifact by hand
>>>
>>> we can check-out the tag for 2.1.5651 and run "mvn ship -DskipTests"
>>> or "mvn deploy -Prelease -DskipTests" depending on whether we 
>>> actually got the "ship" phase into the standard lifecycle or whether 
>>> we just used the release profile to bind to the deploy phase.... but 
>>> at the end of the day, that would be rebuilding the binaries... 
>>> which (with a strict QA hat on) invalidates testing...
>>>
>>> I think what you need to do is have a maven-ship-plugin or a 
>>> ship-maven-plugin that works a little like this:
>>>
>>> it takes a parameter shipVersion which by default evaluates the 
>>> property shipVersion, but if that property is not defines then 
>>> defaults to ${project.version}
>>>
>>> The m-s-p then resolves the shipVersion of the project artifact and 
>>> passes that file onto a ship script...
>>>
>>> so if I have a war project foo:bar:1.0-SNAPSHOT:war
>>>
>>> mvn ship:ship -DshipVersion=1.0.56
>>>
>>> will redeploy the old version 1.0.56
>>>
>>> mvn package ship:ship
>>>
>>> will build the current source code and ship that
>>>
>>> mvn ship:ship
>>>
>>> will resolve the latest 1.0-SNAPSHOT from the local/remote repos and 
>>> ship that
>>>
>>> we could add a parameter allowSnapshots that will default to false 
>>> in order to prevent accidental deployment of non-releases
>>>
>>> and if you are doing CD you can bind ship:ship to the deploy phase 
>>> in your release profile.
>>>
>>> I think I'll knock something together @mojo to help with this
>>>
>>> On 8 November 2010 19:20, stug23 <pa...@gmail.com> wrote:
>>> >
>>> > We need to figure out how to best leverage Maven (keeping in mind 
>>> > its
>>> process
>>> > and practices) in a Continuous Delivery solution. I like the
>>> conversation
>>> > around this topic and also see that there is this other discussion
>>> about the
>>> > meaning of CD versus CI.
>>> >
>>> > From the comments so far, there has been a fair amount of 
>>> > discussion
>>> about
>>> > how to use SNAPSHOTs as if they were something that they aren't.
>>> > Namely retaining SNAPSHOTs all the way through release, possibly 
>>> > mutating the metadata to make the builds products look like 
>>> > released artifacts
>>> instead of
>>> > SNAPSHOTs without having to rebuild the binaries. Since a SNAPSHOT
>>> works
>>> > well for a "work in progress" and not for a "thing I want to 
>>> > keep",
>>> maybe a
>>> > different approach would work better.
>>> >
>>> > Maybe it would make more sense to just burn lots of version 
>>> > numbers
>>> (e.g,
>>> > 3.5.1099) and always release with a new yet-to-be-defined Maven 
>>> > release plugin that reflects the processes involved with CD. If 
>>> > the concern is
>>> disk
>>> > usage or inefficiency, perhaps some automation can make this more 
>>> > manageable?
>>> >
>>> > I would be interested in inputs on this topic from the Maven 
>>> > founders
>>> if
>>> > they are following this thread.
>>> > --
>>> > View this message in context:
>>> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-
>>> tp3245370p3255592.html
>>> > Sent from the Maven - Users mailing list archive at Nabble.com.
>>> >
>>> > ------------------------------------------------------------------
>>> > -
>>> > -- To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> > For additional commands, e-mail: users-help@maven.apache.org
>>> >
>>> >
>>>
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> This e-mail, including attachments, may include confidential and/or 
> proprietary information, and may be used only by the person or entity 
> to which it is addressed. If the reader of this e-mail is not the 
> intended recipient or his or her authorized agent, the reader is 
> hereby notified that any dissemination, distribution or copying of 
> this e-mail is prohibited. If you have received this e-mail in error, 
> please notify the sender by replying to this message and delete this e-mail immediately.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[Stephen Connolly <st...@gmail.com>]

Why bother... the checkin is automatic and actually a good thing IMHO

On 9 November 2010 15:37, Yanko, Curtis <cu...@uhc.com> wrote:
> What if you just avoid the check in?  Only package the pom and deploy the jar?
>
>
> ________________________________
>
> Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
> Making IT Happen, one build at a time, 600 times a day
>
> -----Original Message-----
> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> Sent: Tuesday, November 09, 2010 9:32 AM
> To: Maven Users List
> Subject: Re: Continuous Delivery and Maven
>
> On 9 November 2010 14:10, Thiessen, Todd (Todd) <tt...@avaya.com> wrote:
>> Hey Stephen. I read through your idea a little more closely and I like it.
>>
>> The only thing I think it is missing is the ability to use snapshots as dependencies. That is a very powerful feature of maven that I don't think you'd want to lose if your using CD.
>
> Well I regard that the project being delivered can only have internal -SNAPSHOT dependencies, all external (to the reactor) dependencies should be release dependencies.
>
> One of the things I have wanted to do with v-m-p is to hack around version ranges... for example...
>
> if we develop using
>
> <dependency>
>  <groupId>foo</groupId>
>  <artifactId>bar</artifactId>
>  <version>[1.0,2.0)</version>
> </dependency>
>
> when we run the preparation goals in release:prepare, we have the opertunity to modify the pom and have that modified pom checked in, so there is nothing stopping us from resolving the range, e.g.
>
> <dependency>
>  <groupId>foo</groupId>
>  <artifactId>bar</artifactId>
>  <version>1.1.3</version>
> </dependency>
>
> and now the tag is a locked down reproducible build.... but the developer is stuck with the locked down version...
>
> so, if somehow we can tweak things... stick in a comment... or better yet an XML PI
>
> <dependency>
>  <groupId>foo</groupId>
>  <artifactId>bar</artifactId>
>  <version>1.1.3</version>
>  <?org.codehaus.mojo:versions-maven-plugin range="[1.0,2.0)"?> </dependency>
>
> then all we need is a postReleaseGoals added to release:prepare and we can have v-m-p put the version ranges back in...
>
> Which would give you repeatable releases and bleeding edge dependencies... but only released dependencies.
>
> The problem with -SNAPSHOTs is that they can be deployed without having passed testing.
>
> MRM staging support is really about having atomic releases of multi-module artifacts, e.g. make sure they either all get deployed or none get deployed.
>
> -Stephen
>
>>
>> It is almost like you'd want a mode in Maven. Say you had some kind of flag that said "Continuous Delivery" mode. In this mode, you would only use release repositories when deploying artifacts or downloading artifacts. Nothing would ever get built as a snapshot, even if your pom has snapshot versions. In CD mode, you always use the latest release artifact of your dependencies. You could never pull artifacts from a snapshot repository in this mode.
>>
>> So, for example lets my project's version iss 1.0-SNAPSHOT. When I do:
>>
>> mvn deploy
>>
>> it would deploy release 1.0-0001 to the release repo.
>>
>> If my project had any snapshot dependencies, it wouldn't have to checkout and rebuild these. Those dependencies would also have to be in "CD mode" and all artifacts would have to be to the release repo. So if my project has a dependency on some artifact with version:
>>
>> 3.2-SNAPSHOT
>>
>> while in CD mode, maven would query the release repo, find the latest release artifact (say 3.2-0122) and use that.
>>
>> This would of course fill up your release repo but I think you would need to think of a release repo a little differently if your doing CD.
>>
>>> -----Original Message-----
>>> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
>>> Sent: Tuesday, November 09, 2010 4:24 AM
>>> To: Maven Users List
>>> Subject: Re: Continuous Delivery and Maven
>>>
>>> I think some of the issues are around missuse of Maven.
>>>
>>> Maven is a build tool, use it to do your build.
>>>
>>> CD needs a separate layer above Maven to do the deployment... now one
>>> could use maven plugins to provide that layer, but there are two
>>> issues I see:
>>>
>>> 1. the maven lifecycle does not include the phases you require
>>>
>>> 2. inbetween invokations of maven, we have no means to share state
>>>
>>> so lets say for #1 we add a phase of "ship"... we'd have the standard
>>> lifecycle something like
>>>
>>> validate -> ... -> compile -> ... -> test -> ... -> package -> ... ->
>>> verify -> install -> deploy -> ship
>>>
>>> that would allow us to bind our CD steps to the "ship" phase... ok,
>>> so people would have to get used to the fact that Maven uses "deploy"
>>> to mean "copy artifact to remote maven repo" and not the CD meaning
>>> of deploy... but people can "Just Get Over It(TM)"
>>>
>>> that allows any build to just go
>>>
>>> mvn clean ship
>>>
>>> and away we go... except that we would be dealing with -SNAPSHOTs...
>>>
>>> so to correct for that we would change the release goals using the
>>> release plugin to be "ship" in place of deploy... to gain speed (at
>>> the expense of better tested releases), we could even modify the
>>> preparation goals using the release plugin to be just "clean validate"
>>> and not "clean verify"
>>>
>>> then
>>>
>>> mvn release:prepare
>>>
>>> would be quick
>>>
>>> mvn release:perform
>>>
>>> would do the CD
>>>
>>> Hmmmm... most of this is actually fine for CD, and we don't even
>>> really need the "ship" phase as we could just bind to the deploy
>>> phase using the release profile to ensure that it only takes place
>>> during a release...
>>>
>>> The down side is we have no way to roll-back easily....
>>>
>>> e.g. we've just released 2.1.5652 but we have egg on our face due to
>>> an automated QA test that is giving a false pass... we have no way to
>>> revert back to 2.1.5651 except:
>>>  A. to revert the commits and roll a new release
>>>  B. put in the 2.1.5651 artifact by hand
>>>
>>> we can check-out the tag for 2.1.5651 and run "mvn ship -DskipTests"
>>> or "mvn deploy -Prelease -DskipTests" depending on whether we
>>> actually got the "ship" phase into the standard lifecycle or whether
>>> we just used the release profile to bind to the deploy phase.... but
>>> at the end of the day, that would be rebuilding the binaries... which
>>> (with a strict QA hat on) invalidates testing...
>>>
>>> I think what you need to do is have a maven-ship-plugin or a
>>> ship-maven-plugin that works a little like this:
>>>
>>> it takes a parameter shipVersion which by default evaluates the
>>> property shipVersion, but if that property is not defines then
>>> defaults to ${project.version}
>>>
>>> The m-s-p then resolves the shipVersion of the project artifact and
>>> passes that file onto a ship script...
>>>
>>> so if I have a war project foo:bar:1.0-SNAPSHOT:war
>>>
>>> mvn ship:ship -DshipVersion=1.0.56
>>>
>>> will redeploy the old version 1.0.56
>>>
>>> mvn package ship:ship
>>>
>>> will build the current source code and ship that
>>>
>>> mvn ship:ship
>>>
>>> will resolve the latest 1.0-SNAPSHOT from the local/remote repos and
>>> ship that
>>>
>>> we could add a parameter allowSnapshots that will default to false in
>>> order to prevent accidental deployment of non-releases
>>>
>>> and if you are doing CD you can bind ship:ship to the deploy phase in
>>> your release profile.
>>>
>>> I think I'll knock something together @mojo to help with this
>>>
>>> On 8 November 2010 19:20, stug23 <pa...@gmail.com> wrote:
>>> >
>>> > We need to figure out how to best leverage Maven (keeping in mind
>>> > its
>>> process
>>> > and practices) in a Continuous Delivery solution. I like the
>>> conversation
>>> > around this topic and also see that there is this other discussion
>>> about the
>>> > meaning of CD versus CI.
>>> >
>>> > From the comments so far, there has been a fair amount of
>>> > discussion
>>> about
>>> > how to use SNAPSHOTs as if they were something that they aren't.
>>> > Namely retaining SNAPSHOTs all the way through release, possibly
>>> > mutating the metadata to make the builds products look like
>>> > released artifacts
>>> instead of
>>> > SNAPSHOTs without having to rebuild the binaries. Since a SNAPSHOT
>>> works
>>> > well for a "work in progress" and not for a "thing I want to keep",
>>> maybe a
>>> > different approach would work better.
>>> >
>>> > Maybe it would make more sense to just burn lots of version numbers
>>> (e.g,
>>> > 3.5.1099) and always release with a new yet-to-be-defined Maven
>>> > release plugin that reflects the processes involved with CD. If the
>>> > concern is
>>> disk
>>> > usage or inefficiency, perhaps some automation can make this more
>>> > manageable?
>>> >
>>> > I would be interested in inputs on this topic from the Maven
>>> > founders
>>> if
>>> > they are following this thread.
>>> > --
>>> > View this message in context:
>>> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-
>>> tp3245370p3255592.html
>>> > Sent from the Maven - Users mailing list archive at Nabble.com.
>>> >
>>> > -------------------------------------------------------------------
>>> > -- To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> > For additional commands, e-mail: users-help@maven.apache.org
>>> >
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> This e-mail, including attachments, may include confidential and/or
> proprietary information, and may be used only by the person or entity
> to which it is addressed. If the reader of this e-mail is not the intended
> recipient or his or her authorized agent, the reader is hereby notified
> that any dissemination, distribution or copying of this e-mail is
> prohibited. If you have received this e-mail in error, please notify the
> sender by replying to this message and delete this e-mail immediately.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Yanko, Curtis" <cu...@uhc.com>]

What if you just avoid the check in?  Only package the pom and deploy the jar?


________________________________

Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
Making IT Happen, one build at a time, 600 times a day

-----Original Message-----
From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com] 
Sent: Tuesday, November 09, 2010 9:32 AM
To: Maven Users List
Subject: Re: Continuous Delivery and Maven

On 9 November 2010 14:10, Thiessen, Todd (Todd) <tt...@avaya.com> wrote:
> Hey Stephen. I read through your idea a little more closely and I like it.
>
> The only thing I think it is missing is the ability to use snapshots as dependencies. That is a very powerful feature of maven that I don't think you'd want to lose if your using CD.

Well I regard that the project being delivered can only have internal -SNAPSHOT dependencies, all external (to the reactor) dependencies should be release dependencies.

One of the things I have wanted to do with v-m-p is to hack around version ranges... for example...

if we develop using

<dependency>
  <groupId>foo</groupId>
  <artifactId>bar</artifactId>
  <version>[1.0,2.0)</version>
</dependency>

when we run the preparation goals in release:prepare, we have the opertunity to modify the pom and have that modified pom checked in, so there is nothing stopping us from resolving the range, e.g.

<dependency>
  <groupId>foo</groupId>
  <artifactId>bar</artifactId>
  <version>1.1.3</version>
</dependency>

and now the tag is a locked down reproducible build.... but the developer is stuck with the locked down version...

so, if somehow we can tweak things... stick in a comment... or better yet an XML PI

<dependency>
  <groupId>foo</groupId>
  <artifactId>bar</artifactId>
  <version>1.1.3</version>
  <?org.codehaus.mojo:versions-maven-plugin range="[1.0,2.0)"?> </dependency>

then all we need is a postReleaseGoals added to release:prepare and we can have v-m-p put the version ranges back in...

Which would give you repeatable releases and bleeding edge dependencies... but only released dependencies.

The problem with -SNAPSHOTs is that they can be deployed without having passed testing.

MRM staging support is really about having atomic releases of multi-module artifacts, e.g. make sure they either all get deployed or none get deployed.

-Stephen

>
> It is almost like you'd want a mode in Maven. Say you had some kind of flag that said "Continuous Delivery" mode. In this mode, you would only use release repositories when deploying artifacts or downloading artifacts. Nothing would ever get built as a snapshot, even if your pom has snapshot versions. In CD mode, you always use the latest release artifact of your dependencies. You could never pull artifacts from a snapshot repository in this mode.
>
> So, for example lets my project's version iss 1.0-SNAPSHOT. When I do:
>
> mvn deploy
>
> it would deploy release 1.0-0001 to the release repo.
>
> If my project had any snapshot dependencies, it wouldn't have to checkout and rebuild these. Those dependencies would also have to be in "CD mode" and all artifacts would have to be to the release repo. So if my project has a dependency on some artifact with version:
>
> 3.2-SNAPSHOT
>
> while in CD mode, maven would query the release repo, find the latest release artifact (say 3.2-0122) and use that.
>
> This would of course fill up your release repo but I think you would need to think of a release repo a little differently if your doing CD.
>
>> -----Original Message-----
>> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
>> Sent: Tuesday, November 09, 2010 4:24 AM
>> To: Maven Users List
>> Subject: Re: Continuous Delivery and Maven
>>
>> I think some of the issues are around missuse of Maven.
>>
>> Maven is a build tool, use it to do your build.
>>
>> CD needs a separate layer above Maven to do the deployment... now one 
>> could use maven plugins to provide that layer, but there are two 
>> issues I see:
>>
>> 1. the maven lifecycle does not include the phases you require
>>
>> 2. inbetween invokations of maven, we have no means to share state
>>
>> so lets say for #1 we add a phase of "ship"... we'd have the standard 
>> lifecycle something like
>>
>> validate -> ... -> compile -> ... -> test -> ... -> package -> ... -> 
>> verify -> install -> deploy -> ship
>>
>> that would allow us to bind our CD steps to the "ship" phase... ok, 
>> so people would have to get used to the fact that Maven uses "deploy" 
>> to mean "copy artifact to remote maven repo" and not the CD meaning 
>> of deploy... but people can "Just Get Over It(TM)"
>>
>> that allows any build to just go
>>
>> mvn clean ship
>>
>> and away we go... except that we would be dealing with -SNAPSHOTs...
>>
>> so to correct for that we would change the release goals using the 
>> release plugin to be "ship" in place of deploy... to gain speed (at 
>> the expense of better tested releases), we could even modify the 
>> preparation goals using the release plugin to be just "clean validate"
>> and not "clean verify"
>>
>> then
>>
>> mvn release:prepare
>>
>> would be quick
>>
>> mvn release:perform
>>
>> would do the CD
>>
>> Hmmmm... most of this is actually fine for CD, and we don't even 
>> really need the "ship" phase as we could just bind to the deploy 
>> phase using the release profile to ensure that it only takes place 
>> during a release...
>>
>> The down side is we have no way to roll-back easily....
>>
>> e.g. we've just released 2.1.5652 but we have egg on our face due to 
>> an automated QA test that is giving a false pass... we have no way to 
>> revert back to 2.1.5651 except:
>>  A. to revert the commits and roll a new release
>>  B. put in the 2.1.5651 artifact by hand
>>
>> we can check-out the tag for 2.1.5651 and run "mvn ship -DskipTests"
>> or "mvn deploy -Prelease -DskipTests" depending on whether we 
>> actually got the "ship" phase into the standard lifecycle or whether 
>> we just used the release profile to bind to the deploy phase.... but 
>> at the end of the day, that would be rebuilding the binaries... which 
>> (with a strict QA hat on) invalidates testing...
>>
>> I think what you need to do is have a maven-ship-plugin or a 
>> ship-maven-plugin that works a little like this:
>>
>> it takes a parameter shipVersion which by default evaluates the 
>> property shipVersion, but if that property is not defines then 
>> defaults to ${project.version}
>>
>> The m-s-p then resolves the shipVersion of the project artifact and 
>> passes that file onto a ship script...
>>
>> so if I have a war project foo:bar:1.0-SNAPSHOT:war
>>
>> mvn ship:ship -DshipVersion=1.0.56
>>
>> will redeploy the old version 1.0.56
>>
>> mvn package ship:ship
>>
>> will build the current source code and ship that
>>
>> mvn ship:ship
>>
>> will resolve the latest 1.0-SNAPSHOT from the local/remote repos and 
>> ship that
>>
>> we could add a parameter allowSnapshots that will default to false in 
>> order to prevent accidental deployment of non-releases
>>
>> and if you are doing CD you can bind ship:ship to the deploy phase in 
>> your release profile.
>>
>> I think I'll knock something together @mojo to help with this
>>
>> On 8 November 2010 19:20, stug23 <pa...@gmail.com> wrote:
>> >
>> > We need to figure out how to best leverage Maven (keeping in mind 
>> > its
>> process
>> > and practices) in a Continuous Delivery solution. I like the
>> conversation
>> > around this topic and also see that there is this other discussion
>> about the
>> > meaning of CD versus CI.
>> >
>> > From the comments so far, there has been a fair amount of 
>> > discussion
>> about
>> > how to use SNAPSHOTs as if they were something that they aren't. 
>> > Namely retaining SNAPSHOTs all the way through release, possibly 
>> > mutating the metadata to make the builds products look like 
>> > released artifacts
>> instead of
>> > SNAPSHOTs without having to rebuild the binaries. Since a SNAPSHOT
>> works
>> > well for a "work in progress" and not for a "thing I want to keep",
>> maybe a
>> > different approach would work better.
>> >
>> > Maybe it would make more sense to just burn lots of version numbers
>> (e.g,
>> > 3.5.1099) and always release with a new yet-to-be-defined Maven 
>> > release plugin that reflects the processes involved with CD. If the 
>> > concern is
>> disk
>> > usage or inefficiency, perhaps some automation can make this more 
>> > manageable?
>> >
>> > I would be interested in inputs on this topic from the Maven 
>> > founders
>> if
>> > they are following this thread.
>> > --
>> > View this message in context:
>> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-
>> tp3245370p3255592.html
>> > Sent from the Maven - Users mailing list archive at Nabble.com.
>> >
>> > -------------------------------------------------------------------
>> > -- To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: users-help@maven.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[Stephen Connolly <st...@gmail.com>]

On 9 November 2010 14:10, Thiessen, Todd (Todd) <tt...@avaya.com> wrote:
> Hey Stephen. I read through your idea a little more closely and I like it.
>
> The only thing I think it is missing is the ability to use snapshots as dependencies. That is a very powerful feature of maven that I don't think you'd want to lose if your using CD.

Well I regard that the project being delivered can only have internal
-SNAPSHOT dependencies, all external (to the reactor) dependencies
should be release dependencies.

One of the things I have wanted to do with v-m-p is to hack around
version ranges... for example...

if we develop using

<dependency>
  <groupId>foo</groupId>
  <artifactId>bar</artifactId>
  <version>[1.0,2.0)</version>
</dependency>

when we run the preparation goals in release:prepare, we have the
opertunity to modify the pom and have that modified pom checked in, so
there is nothing stopping us from resolving the range, e.g.

<dependency>
  <groupId>foo</groupId>
  <artifactId>bar</artifactId>
  <version>1.1.3</version>
</dependency>

and now the tag is a locked down reproducible build.... but the
developer is stuck with the locked down version...

so, if somehow we can tweak things... stick in a comment... or better
yet an XML PI

<dependency>
  <groupId>foo</groupId>
  <artifactId>bar</artifactId>
  <version>1.1.3</version>
  <?org.codehaus.mojo:versions-maven-plugin range="[1.0,2.0)"?>
</dependency>

then all we need is a postReleaseGoals added to release:prepare and we
can have v-m-p put the version ranges back in...

Which would give you repeatable releases and bleeding edge
dependencies... but only released dependencies.

The problem with -SNAPSHOTs is that they can be deployed without
having passed testing.

MRM staging support is really about having atomic releases of
multi-module artifacts, e.g. make sure they either all get deployed or
none get deployed.

-Stephen

>
> It is almost like you'd want a mode in Maven. Say you had some kind of flag that said "Continuous Delivery" mode. In this mode, you would only use release repositories when deploying artifacts or downloading artifacts. Nothing would ever get built as a snapshot, even if your pom has snapshot versions. In CD mode, you always use the latest release artifact of your dependencies. You could never pull artifacts from a snapshot repository in this mode.
>
> So, for example lets my project's version iss 1.0-SNAPSHOT. When I do:
>
> mvn deploy
>
> it would deploy release 1.0-0001 to the release repo.
>
> If my project had any snapshot dependencies, it wouldn't have to checkout and rebuild these. Those dependencies would also have to be in "CD mode" and all artifacts would have to be to the release repo. So if my project has a dependency on some artifact with version:
>
> 3.2-SNAPSHOT
>
> while in CD mode, maven would query the release repo, find the latest release artifact (say 3.2-0122) and use that.
>
> This would of course fill up your release repo but I think you would need to think of a release repo a little differently if your doing CD.
>
>> -----Original Message-----
>> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
>> Sent: Tuesday, November 09, 2010 4:24 AM
>> To: Maven Users List
>> Subject: Re: Continuous Delivery and Maven
>>
>> I think some of the issues are around missuse of Maven.
>>
>> Maven is a build tool, use it to do your build.
>>
>> CD needs a separate layer above Maven to do the deployment... now one
>> could use maven plugins to provide that layer, but there are two
>> issues I see:
>>
>> 1. the maven lifecycle does not include the phases you require
>>
>> 2. inbetween invokations of maven, we have no means to share state
>>
>> so lets say for #1 we add a phase of "ship"... we'd have the standard
>> lifecycle something like
>>
>> validate -> ... -> compile -> ... -> test -> ... -> package -> ... ->
>> verify -> install -> deploy -> ship
>>
>> that would allow us to bind our CD steps to the "ship" phase... ok, so
>> people would have to get used to the fact that Maven uses "deploy" to
>> mean "copy artifact to remote maven repo" and not the CD meaning of
>> deploy... but people can "Just Get Over It(TM)"
>>
>> that allows any build to just go
>>
>> mvn clean ship
>>
>> and away we go... except that we would be dealing with -SNAPSHOTs...
>>
>> so to correct for that we would change the release goals using the
>> release plugin to be "ship" in place of deploy... to gain speed (at
>> the expense of better tested releases), we could even modify the
>> preparation goals using the release plugin to be just "clean validate"
>> and not "clean verify"
>>
>> then
>>
>> mvn release:prepare
>>
>> would be quick
>>
>> mvn release:perform
>>
>> would do the CD
>>
>> Hmmmm... most of this is actually fine for CD, and we don't even
>> really need the "ship" phase as we could just bind to the deploy phase
>> using the release profile to ensure that it only takes place during a
>> release...
>>
>> The down side is we have no way to roll-back easily....
>>
>> e.g. we've just released 2.1.5652 but we have egg on our face due to
>> an automated QA test that is giving a false pass... we have no way to
>> revert back to 2.1.5651 except:
>>  A. to revert the commits and roll a new release
>>  B. put in the 2.1.5651 artifact by hand
>>
>> we can check-out the tag for 2.1.5651 and run "mvn ship -DskipTests"
>> or "mvn deploy -Prelease -DskipTests" depending on whether we actually
>> got the "ship" phase into the standard lifecycle or whether we just
>> used the release profile to bind to the deploy phase.... but at the
>> end of the day, that would be rebuilding the binaries... which (with a
>> strict QA hat on) invalidates testing...
>>
>> I think what you need to do is have a maven-ship-plugin or a
>> ship-maven-plugin that works a little like this:
>>
>> it takes a parameter shipVersion which by default evaluates the
>> property shipVersion, but if that property is not defines then
>> defaults to ${project.version}
>>
>> The m-s-p then resolves the shipVersion of the project artifact and
>> passes that file onto a ship script...
>>
>> so if I have a war project foo:bar:1.0-SNAPSHOT:war
>>
>> mvn ship:ship -DshipVersion=1.0.56
>>
>> will redeploy the old version 1.0.56
>>
>> mvn package ship:ship
>>
>> will build the current source code and ship that
>>
>> mvn ship:ship
>>
>> will resolve the latest 1.0-SNAPSHOT from the local/remote repos and ship
>> that
>>
>> we could add a parameter allowSnapshots that will default to false in
>> order to prevent accidental deployment of non-releases
>>
>> and if you are doing CD you can bind ship:ship to the deploy phase in
>> your release profile.
>>
>> I think I'll knock something together @mojo to help with this
>>
>> On 8 November 2010 19:20, stug23 <pa...@gmail.com> wrote:
>> >
>> > We need to figure out how to best leverage Maven (keeping in mind its
>> process
>> > and practices) in a Continuous Delivery solution. I like the
>> conversation
>> > around this topic and also see that there is this other discussion
>> about the
>> > meaning of CD versus CI.
>> >
>> > From the comments so far, there has been a fair amount of discussion
>> about
>> > how to use SNAPSHOTs as if they were something that they aren't. Namely
>> > retaining SNAPSHOTs all the way through release, possibly mutating the
>> > metadata to make the builds products look like released artifacts
>> instead of
>> > SNAPSHOTs without having to rebuild the binaries. Since a SNAPSHOT
>> works
>> > well for a "work in progress" and not for a "thing I want to keep",
>> maybe a
>> > different approach would work better.
>> >
>> > Maybe it would make more sense to just burn lots of version numbers
>> (e.g,
>> > 3.5.1099) and always release with a new yet-to-be-defined Maven release
>> > plugin that reflects the processes involved with CD. If the concern is
>> disk
>> > usage or inefficiency, perhaps some automation can make this more
>> > manageable?
>> >
>> > I would be interested in inputs on this topic from the Maven founders
>> if
>> > they are following this thread.
>> > --
>> > View this message in context:
>> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-
>> tp3245370p3255592.html
>> > Sent from the Maven - Users mailing list archive at Nabble.com.
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: users-help@maven.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Thiessen, Todd (Todd)" <tt...@avaya.com>]

Hey Stephen. I read through your idea a little more closely and I like it.

The only thing I think it is missing is the ability to use snapshots as dependencies. That is a very powerful feature of maven that I don't think you'd want to lose if your using CD.

It is almost like you'd want a mode in Maven. Say you had some kind of flag that said "Continuous Delivery" mode. In this mode, you would only use release repositories when deploying artifacts or downloading artifacts. Nothing would ever get built as a snapshot, even if your pom has snapshot versions. In CD mode, you always use the latest release artifact of your dependencies. You could never pull artifacts from a snapshot repository in this mode.

So, for example lets my project's version iss 1.0-SNAPSHOT. When I do:

mvn deploy

it would deploy release 1.0-0001 to the release repo.

If my project had any snapshot dependencies, it wouldn't have to checkout and rebuild these. Those dependencies would also have to be in "CD mode" and all artifacts would have to be to the release repo. So if my project has a dependency on some artifact with version:

3.2-SNAPSHOT

while in CD mode, maven would query the release repo, find the latest release artifact (say 3.2-0122) and use that.

This would of course fill up your release repo but I think you would need to think of a release repo a little differently if your doing CD.

> -----Original Message-----
> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> Sent: Tuesday, November 09, 2010 4:24 AM
> To: Maven Users List
> Subject: Re: Continuous Delivery and Maven
> 
> I think some of the issues are around missuse of Maven.
> 
> Maven is a build tool, use it to do your build.
> 
> CD needs a separate layer above Maven to do the deployment... now one
> could use maven plugins to provide that layer, but there are two
> issues I see:
> 
> 1. the maven lifecycle does not include the phases you require
> 
> 2. inbetween invokations of maven, we have no means to share state
> 
> so lets say for #1 we add a phase of "ship"... we'd have the standard
> lifecycle something like
> 
> validate -> ... -> compile -> ... -> test -> ... -> package -> ... ->
> verify -> install -> deploy -> ship
> 
> that would allow us to bind our CD steps to the "ship" phase... ok, so
> people would have to get used to the fact that Maven uses "deploy" to
> mean "copy artifact to remote maven repo" and not the CD meaning of
> deploy... but people can "Just Get Over It(TM)"
> 
> that allows any build to just go
> 
> mvn clean ship
> 
> and away we go... except that we would be dealing with -SNAPSHOTs...
> 
> so to correct for that we would change the release goals using the
> release plugin to be "ship" in place of deploy... to gain speed (at
> the expense of better tested releases), we could even modify the
> preparation goals using the release plugin to be just "clean validate"
> and not "clean verify"
> 
> then
> 
> mvn release:prepare
> 
> would be quick
> 
> mvn release:perform
> 
> would do the CD
> 
> Hmmmm... most of this is actually fine for CD, and we don't even
> really need the "ship" phase as we could just bind to the deploy phase
> using the release profile to ensure that it only takes place during a
> release...
> 
> The down side is we have no way to roll-back easily....
> 
> e.g. we've just released 2.1.5652 but we have egg on our face due to
> an automated QA test that is giving a false pass... we have no way to
> revert back to 2.1.5651 except:
>  A. to revert the commits and roll a new release
>  B. put in the 2.1.5651 artifact by hand
> 
> we can check-out the tag for 2.1.5651 and run "mvn ship -DskipTests"
> or "mvn deploy -Prelease -DskipTests" depending on whether we actually
> got the "ship" phase into the standard lifecycle or whether we just
> used the release profile to bind to the deploy phase.... but at the
> end of the day, that would be rebuilding the binaries... which (with a
> strict QA hat on) invalidates testing...
> 
> I think what you need to do is have a maven-ship-plugin or a
> ship-maven-plugin that works a little like this:
> 
> it takes a parameter shipVersion which by default evaluates the
> property shipVersion, but if that property is not defines then
> defaults to ${project.version}
> 
> The m-s-p then resolves the shipVersion of the project artifact and
> passes that file onto a ship script...
> 
> so if I have a war project foo:bar:1.0-SNAPSHOT:war
> 
> mvn ship:ship -DshipVersion=1.0.56
> 
> will redeploy the old version 1.0.56
> 
> mvn package ship:ship
> 
> will build the current source code and ship that
> 
> mvn ship:ship
> 
> will resolve the latest 1.0-SNAPSHOT from the local/remote repos and ship
> that
> 
> we could add a parameter allowSnapshots that will default to false in
> order to prevent accidental deployment of non-releases
> 
> and if you are doing CD you can bind ship:ship to the deploy phase in
> your release profile.
> 
> I think I'll knock something together @mojo to help with this
> 
> On 8 November 2010 19:20, stug23 <pa...@gmail.com> wrote:
> >
> > We need to figure out how to best leverage Maven (keeping in mind its
> process
> > and practices) in a Continuous Delivery solution. I like the
> conversation
> > around this topic and also see that there is this other discussion
> about the
> > meaning of CD versus CI.
> >
> > From the comments so far, there has been a fair amount of discussion
> about
> > how to use SNAPSHOTs as if they were something that they aren't. Namely
> > retaining SNAPSHOTs all the way through release, possibly mutating the
> > metadata to make the builds products look like released artifacts
> instead of
> > SNAPSHOTs without having to rebuild the binaries. Since a SNAPSHOT
> works
> > well for a "work in progress" and not for a "thing I want to keep",
> maybe a
> > different approach would work better.
> >
> > Maybe it would make more sense to just burn lots of version numbers
> (e.g,
> > 3.5.1099) and always release with a new yet-to-be-defined Maven release
> > plugin that reflects the processes involved with CD. If the concern is
> disk
> > usage or inefficiency, perhaps some automation can make this more
> > manageable?
> >
> > I would be interested in inputs on this topic from the Maven founders
> if
> > they are following this thread.
> > --
> > View this message in context:
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-
> tp3245370p3255592.html
> > Sent from the Maven - Users mailing list archive at Nabble.com.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[Stephen Connolly <st...@gmail.com>]

I think some of the issues are around missuse of Maven.

Maven is a build tool, use it to do your build.

CD needs a separate layer above Maven to do the deployment... now one
could use maven plugins to provide that layer, but there are two
issues I see:

1. the maven lifecycle does not include the phases you require

2. inbetween invokations of maven, we have no means to share state

so lets say for #1 we add a phase of "ship"... we'd have the standard
lifecycle something like

validate -> ... -> compile -> ... -> test -> ... -> package -> ... ->
verify -> install -> deploy -> ship

that would allow us to bind our CD steps to the "ship" phase... ok, so
people would have to get used to the fact that Maven uses "deploy" to
mean "copy artifact to remote maven repo" and not the CD meaning of
deploy... but people can "Just Get Over It(TM)"

that allows any build to just go

mvn clean ship

and away we go... except that we would be dealing with -SNAPSHOTs...

so to correct for that we would change the release goals using the
release plugin to be "ship" in place of deploy... to gain speed (at
the expense of better tested releases), we could even modify the
preparation goals using the release plugin to be just "clean validate"
and not "clean verify"

then

mvn release:prepare

would be quick

mvn release:perform

would do the CD

Hmmmm... most of this is actually fine for CD, and we don't even
really need the "ship" phase as we could just bind to the deploy phase
using the release profile to ensure that it only takes place during a
release...

The down side is we have no way to roll-back easily....

e.g. we've just released 2.1.5652 but we have egg on our face due to
an automated QA test that is giving a false pass... we have no way to
revert back to 2.1.5651 except:
 A. to revert the commits and roll a new release
 B. put in the 2.1.5651 artifact by hand

we can check-out the tag for 2.1.5651 and run "mvn ship -DskipTests"
or "mvn deploy -Prelease -DskipTests" depending on whether we actually
got the "ship" phase into the standard lifecycle or whether we just
used the release profile to bind to the deploy phase.... but at the
end of the day, that would be rebuilding the binaries... which (with a
strict QA hat on) invalidates testing...

I think what you need to do is have a maven-ship-plugin or a
ship-maven-plugin that works a little like this:

it takes a parameter shipVersion which by default evaluates the
property shipVersion, but if that property is not defines then
defaults to ${project.version}

The m-s-p then resolves the shipVersion of the project artifact and
passes that file onto a ship script...

so if I have a war project foo:bar:1.0-SNAPSHOT:war

mvn ship:ship -DshipVersion=1.0.56

will redeploy the old version 1.0.56

mvn package ship:ship

will build the current source code and ship that

mvn ship:ship

will resolve the latest 1.0-SNAPSHOT from the local/remote repos and ship that

we could add a parameter allowSnapshots that will default to false in
order to prevent accidental deployment of non-releases

and if you are doing CD you can bind ship:ship to the deploy phase in
your release profile.

I think I'll knock something together @mojo to help with this

On 8 November 2010 19:20, stug23 <pa...@gmail.com> wrote:
>
> We need to figure out how to best leverage Maven (keeping in mind its process
> and practices) in a Continuous Delivery solution. I like the conversation
> around this topic and also see that there is this other discussion about the
> meaning of CD versus CI.
>
> From the comments so far, there has been a fair amount of discussion about
> how to use SNAPSHOTs as if they were something that they aren't. Namely
> retaining SNAPSHOTs all the way through release, possibly mutating the
> metadata to make the builds products look like released artifacts instead of
> SNAPSHOTs without having to rebuild the binaries. Since a SNAPSHOT works
> well for a "work in progress" and not for a "thing I want to keep", maybe a
> different approach would work better.
>
> Maybe it would make more sense to just burn lots of version numbers (e.g,
> 3.5.1099) and always release with a new yet-to-be-defined Maven release
> plugin that reflects the processes involved with CD. If the concern is disk
> usage or inefficiency, perhaps some automation can make this more
> manageable?
>
> I would be interested in inputs on this topic from the Maven founders if
> they are following this thread.
> --
> View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3255592.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[stug23 <pa...@gmail.com>]

We need to figure out how to best leverage Maven (keeping in mind its process
and practices) in a Continuous Delivery solution. I like the conversation
around this topic and also see that there is this other discussion about the
meaning of CD versus CI.

>From the comments so far, there has been a fair amount of discussion about
how to use SNAPSHOTs as if they were something that they aren't. Namely
retaining SNAPSHOTs all the way through release, possibly mutating the
metadata to make the builds products look like released artifacts instead of
SNAPSHOTs without having to rebuild the binaries. Since a SNAPSHOT works
well for a "work in progress" and not for a "thing I want to keep", maybe a
different approach would work better.

Maybe it would make more sense to just burn lots of version numbers (e.g,
3.5.1099) and always release with a new yet-to-be-defined Maven release
plugin that reflects the processes involved with CD. If the concern is disk
usage or inefficiency, perhaps some automation can make this more
manageable?

I would be interested in inputs on this topic from the Maven founders if
they are following this thread.
-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3255592.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Thiessen, Todd (Todd)" <tt...@avaya.com>]

> Todd, I have read all of your posts and I have come to the conclusion
> that
> you're missing the point of CD. I was really hoping to avoid an argument
> about process, because I just want to work out what needs to be done to
> Maven to make it support CD, and that's already a big enough discussion
> for
> one thread. However since the thread has (perhaps inevitably) been taken
> over by a discussion about what continuous delivery is, I will add my 1c.

Ok. I will refocus here. Let me just say that this discussion is inevitable. It is important as the value of CD will help determine if Maven should consider working towards supporting this kind of process.  The basic architecture of Maven today does not lend well to it.  So we can table it for now. You comments I think took what I am trying to get across very much out of context but *snip* them for now and defer the discussion to a later date.

 
> *What I want from Maven*
> *===================*
> 
> We want the simplicity of snapshots with the traceability of proper
> releases. So I think from what Brian said, I'd like the the Maven
> snapshot
> build process to create enough metadata in the pom file such that when
> you
> ran the release plugin, it wouldn't be necessary for it to rebuild the
> artifact - it could just do the various bits of tagging and metadata
> creation using the information in the pom associated with the snapshot.

I don't think that is enough.  Using timed snapshots is already not recommended in general; as others have noted they don't persist. But for now lets assume that you configured your environment for them to persist and to use them.

The final artifacts and all the meta do not represent what is considered a released artifact.  The meta data is different and the artifact names are different. So the release process would have to "massage" the snapshot artifacts to "look" like releases. This will of course invalidate much of the testing done by your CI.

When I say meta data here, I am referring to the meta data maven stores about the artifact. This information doesn't appear in the pom.

Also if you do this you will be breaking the idea of CI. If your dependencies point to specific time stamp then that build won't be getting the latest version of those dependencies. You'd need some process to constantly update the pom to always point to the latest version of all your dependencies.  This I think would be fairly complex as your pom files would be constantly changing, even if you as a developer didn't need to change it.

So your process would be something like:

1. Commit code.
2. Fire off CI build that builds using snapshots. (say version 1.0-SNAPSHOT)
3. Fire of CD build. First thing it does is create a release of all transitive dependencies and then the core build (say version 1.0-01).
4. Whether CD build passes or not it has to revert the source back to its CI state (ie: versions abck to 1.0-SNAPSHOT).

I think what you would want is to not use snapshots at all. Treat everything as a release and work around that.  So instead you'd  have something like:

1. Version in all points represents a release. Say 1.0-01
2. Commit code.
3. Build 1.0-01 release.
4. Bump pom to 1.0-02.

We use to have guys do something like this sometime ago and it worked fairly well. A little more complicated since they had to script a lot of things themselves but I am sure a lot of this complexity can be hidden in a plugin.  They eventually moved to snapshots though as the idea of continually releasing proved to have little value.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Yanko, Curtis" <cu...@uhc.com>]

 
I didn't see a reply from a Brian. What answer did he provided that
answered your question?

________________________________

Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
Making IT Happen, one build at a time, 600 times a day

-----Original Message-----
From: jhumble [mailto:jez@jezhumble.net] 
Sent: Monday, November 08, 2010 11:58 AM
To: users@maven.apache.org
Subject: Re: Continuous Delivery and Maven


Todd, I have read all of your posts and I have come to the conclusion
that you're missing the point of CD. I was really hoping to avoid an
argument about process, because I just want to work out what needs to be
done to Maven to make it support CD, and that's already a big enough
discussion for one thread. However since the thread has (perhaps
inevitably) been taken over by a discussion about what continuous
delivery is, I will add my 1c. In any case I think I have what I need
from the discussion with Brian.

With CD, the software is *always* production ready, right from the start
of the project. Any work of any kind that doesn't result in a deployable
build is waste.

If you are at the start of a release, your product owner will have a
good
> idea of how much content needs to get to the customer to fullfill that

> release. Doing CD through the entire lifecycle is largely a waste
IMHO.


Wrong. In fact, it's the opposite - any work that doesn't keep the
software in a deployable, releasable state is waste, because you can't
know whether or not the work you have done is actually useful, or even
whether it keeps the software working. And you can't know whether or not
the software is working - i.e. whether or not the build can be deployed
- until it has passed end-to-end acceptance tests under realistic loads
in a production-like environment.

I am fine with you using the process you describe. If it works for you,
that's great. But please don't call it continuous delivery - it isn't.

Now, assuming we are working in a cd process, the crucial thing is that
we don't waste any cycles creating a build that couldn't be released. We
then take this binary and put it through the rest of the deployment
pipeline (or build life or whatever you want to call it). But crucially,
we don't want to recreate the binary later on. If you want more detail
on the mechanics of how it works, you can read the free chapter from my
book here:
http://www.informit.com/articles/article.aspx?p=1621865

*What I want from Maven*
*===================*

We want the simplicity of snapshots with the traceability of proper
releases. So I think from what Brian said, I'd like the the Maven
snapshot build process to create enough metadata in the pom file such
that when you ran the release plugin, it wouldn't be necessary for it to
rebuild the artifact - it could just do the various bits of tagging and
metadata creation using the information in the pom associated with the
snapshot. We might also want the release plugin to try and recreate the
binary using its process and verify the md5 is the same as the md5 of
the snapshot.

If anybody has any feedback on this hypothesis, I'd be very grateful.

Thanks,

Jez.

On 8 November 2010 08:49, Thiessen, Todd (Todd) [via Maven] <
ml-node+3255336-1962346083-143561@n5.nabble.com<ml-node%2B3255336-196234
ml-node+6083-143561@n5.nabble.com>
> wrote:

> > I'm thinking tha Ci wouldn't be affected at all, CD still requires 
> > Ci as a quality metric preventing deployment to the customer.
>
> I am curious to see that. Or how it would work. How do you put in 
> fixed release numbers into a CD build and then switch back to CI 
> building? And I can only imagine it being quite complex.
>
> The only thing I can think of is something like:
>
> 1. CI build produces 1.0-SNAPSHOT
> 2. CD build produces 1.0-01
> 3. CD build reverts source back to 1.0-SNAPSHOT 4. Repeat
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden
email]<http://user/SendEmail.jtp?type=node&node=3255336&i=0>
> For additional commands, e-mail: [hidden
email]<http://user/SendEmail.jtp?type=node&node=3255336&i=1>
>
>
>
> ------------------------------
>  View message @
>
http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370
p3255336.html
> To unsubscribe from Continuous Delivery and Maven, click
here<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubs
cribe_by_code&node=3245370&code=amV6QGplemh1bWJsZS5uZXR8MzI0NTM3MHwtMTg4
MjM1NzMyNA==>.
>
>
>


-- 
Jez Humble
Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
http://continuousdelivery.com/
http://jezhumble.net/

-- 
View this message in context:
http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370
p3255361.html
Sent from the Maven - Users mailing list archive at Nabble.com.

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[jhumble <je...@jezhumble.net>]

Todd, I have read all of your posts and I have come to the conclusion that
you're missing the point of CD. I was really hoping to avoid an argument
about process, because I just want to work out what needs to be done to
Maven to make it support CD, and that's already a big enough discussion for
one thread. However since the thread has (perhaps inevitably) been taken
over by a discussion about what continuous delivery is, I will add my 1c. In
any case I think I have what I need from the discussion with Brian.

With CD, the software is *always* production ready, right from the start of
the project. Any work of any kind that doesn't result in a deployable build
is waste.

If you are at the start of a release, your product owner will have a good
> idea of how much content needs to get to the customer to fullfill that
> release. Doing CD through the entire lifecycle is largely a waste IMHO.


Wrong. In fact, it's the opposite - any work that doesn't keep the software
in a deployable, releasable state is waste, because you can't know whether
or not the work you have done is actually useful, or even whether it keeps
the software working. And you can't know whether or not the software is
working - i.e. whether or not the build can be deployed - until it has
passed end-to-end acceptance tests under realistic loads in a
production-like environment.

I am fine with you using the process you describe. If it works for you,
that's great. But please don't call it continuous delivery - it isn't.

Now, assuming we are working in a cd process, the crucial thing is that we
don't waste any cycles creating a build that couldn't be released. We then
take this binary and put it through the rest of the deployment pipeline (or
build life or whatever you want to call it). But crucially, we don't want to
recreate the binary later on. If you want more detail on the mechanics of
how it works, you can read the free chapter from my book here:
http://www.informit.com/articles/article.aspx?p=1621865

*What I want from Maven*
*===================*

We want the simplicity of snapshots with the traceability of proper
releases. So I think from what Brian said, I'd like the the Maven snapshot
build process to create enough metadata in the pom file such that when you
ran the release plugin, it wouldn't be necessary for it to rebuild the
artifact - it could just do the various bits of tagging and metadata
creation using the information in the pom associated with the snapshot. We
might also want the release plugin to try and recreate the binary using its
process and verify the md5 is the same as the md5 of the snapshot.

If anybody has any feedback on this hypothesis, I'd be very grateful.

Thanks,

Jez.

On 8 November 2010 08:49, Thiessen, Todd (Todd) [via Maven] <
ml-node+3255336-1962346083-143561@n5.nabble.com<ml...@n5.nabble.com>
> wrote:

> > I'm thinking tha Ci wouldn't be affected at all, CD still requires Ci
> > as a quality metric preventing deployment to the customer.
>
> I am curious to see that. Or how it would work. How do you put in fixed
> release numbers into a CD build and then switch back to CI building? And I
> can only imagine it being quite complex.
>
> The only thing I can think of is something like:
>
> 1. CI build produces 1.0-SNAPSHOT
> 2. CD build produces 1.0-01
> 3. CD build reverts source back to 1.0-SNAPSHOT
> 4. Repeat
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3255336&i=0>
> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3255336&i=1>
>
>
>
> ------------------------------
>  View message @
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3255336.html
> To unsubscribe from Continuous Delivery and Maven, click here<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_code&node=3245370&code=amV6QGplemh1bWJsZS5uZXR8MzI0NTM3MHwtMTg4MjM1NzMyNA==>.
>
>
>


-- 
Jez Humble
Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
http://continuousdelivery.com/
http://jezhumble.net/

-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3255361.html
Sent from the Maven - Users mailing list archive at Nabble.com.

RE: Continuous Delivery and Maven

["Thiessen, Todd (Todd)" <tt...@avaya.com>]

> 
> BTW. We deploy our snapshot builds to a live system and do real
> functional testing of a snapshot install.  But this is still not a
> release build and thus wouldn't go to a final customer.  I think the line
> here between CI and CD is blurred.
> 

To clarify on this last point here. All these tests are automated and occur right after a commit. So we have a couple layers of triggers here, similar to what you are suggesting Stephen:

1. Commit triggers a build. This creates a snapshot artifact of installer. Many in memory Junit tests run here. Nothing live.
2. Once build from 1 is done, take installer artifact, upload to a production server and install.
3. Run further live automated tests.

The only difference in our case is that it is all done using snapshots. Any problems are fixed on the trunk of everything. Don't need to worry about released versions when doing these live tests. That just slows things down.

Once you need to deliver something that could potentially go to a customer, trigger CD build, run same live automated tests and go through a bit more human verification testing.

We have found that this can significantly reduce build complexity and improves speed at which the team can deliver a releasable product.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Yanko, Curtis" <cu...@uhc.com>]

You can turn on unique snapshots in your repo manager or, like us, set
all module versions from the parent POM.

To release, we update the version of the Parent POM and commit then do
it again to set it back to snapshot. So, all of *our* modules can be in
flux but any *external ones* (not managed by this POM) have to be
*released*.

Since we are a CI system we use all push style dependencies (C -> B ->
A) and the Parent POM is always the lowest dependency so committing it
triggers a build of everything, from the bottom up.
________________________________

Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
Making IT Happen, one build at a time, 600 times a day

-----Original Message-----
From: Thiessen, Todd (Todd) [mailto:tthiessen@avaya.com] 
Sent: Monday, November 08, 2010 11:48 AM
To: Maven Users List
Subject: RE: Continuous Delivery and Maven

> I'm thinking tha Ci wouldn't be affected at all, CD still requires Ci 
> as a quality metric preventing deployment to the customer.

I am curious to see that. Or how it would work. How do you put in fixed
release numbers into a CD build and then switch back to CI building? And
I can only imagine it being quite complex.

The only thing I can think of is something like:

1. CI build produces 1.0-SNAPSHOT
2. CD build produces 1.0-01
3. CD build reverts source back to 1.0-SNAPSHOT 4. Repeat


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Thiessen, Todd (Todd)" <tt...@avaya.com>]

> I'm thinking tha Ci wouldn't be affected at all, CD still requires Ci
> as a quality metric preventing deployment to the customer.

I am curious to see that. Or how it would work. How do you put in fixed release numbers into a CD build and then switch back to CI building? And I can only imagine it being quite complex.

The only thing I can think of is something like:

1. CI build produces 1.0-SNAPSHOT
2. CD build produces 1.0-01
3. CD build reverts source back to 1.0-SNAPSHOT
4. Repeat


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: RE: Continuous Delivery and Maven

[Stephen Connolly <st...@gmail.com>]

Then I'm not sure you get it

On 8 Nov 2010 17:21, "Thiessen, Todd (Todd)" <tt...@avaya.com> wrote:


> Except you won't know until you go to start up CD that you CD process
> got broken.
Why wouldn't your CI build tell you? You can test everything with your CI
build. No need to mandate going to a customer server to do it.


---------------------------------------------------------------------
To unsubscribe, e-mail: users...

RE: Continuous Delivery and Maven

["Thiessen, Todd (Todd)" <tt...@avaya.com>]

 
> Except you won't know until you go to start up CD that you CD process
> got broken.

Why wouldn't your CI build tell you? You can test everything with your CI build. No need to mandate going to a customer server to do it.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[Stephen Connolly <st...@gmail.com>]

On 8 November 2010 15:41, Thiessen, Todd (Todd) <tt...@avaya.com> wrote:
> I agree with most of your points here Stephen. Sounds like we may be in "violent" agreement ;-).
>
> The point that I disagree with is trigging a CD off a commit or CI build. You don't need to ALWAYS be doing CD. If you are at the start of a release, your product owner will have a good idea of how much content needs to get to the customer to fullfill that release. Doing CD through the entire lifecycle is largely a waste IMHO.
>

Except you won't know until you go to start up CD that you CD process
got broken.

The point of CD is that the process is _always_ there, so you know
that it's _always_ working

If there are critical features that must prevent deploying to the
customer, then write CD verification tests for those features and they
will block deployment until the features are ready... leave the
process in place and let the process prevent the deployment until the
features blocking deployment are ready

> And it isn't just a waste of hard drive or other "mechanical" resources. It just adds complexity to your lifecycle and processes that just aren't needed. If you know you are not delivering to a customer for a couple of months, stick with snapshots so you can more easily do CI. If you are doing CD all the time, it makes CI much more difficult and complicated.

Only fi you haven't automated your CD properly ;-)

>
> I am all for automating CD. But not at the cost of making CI more complicated.
>
> Or perhaps you are thinking that CI wouldn't be affected at all?

I'm thinking tha Ci wouldn't be affected at all, CD still requires Ci
as a quality metric preventing deployment to the customer.

>
> BTW. We deploy our snapshot builds to a live system and do real functional testing of a snapshot install.  But this is still not a release build and thus wouldn't go to a final customer.  I think the line here between CI and CD is blurred.

CD is deploying to a live customer accesible system, anything short of
that is just another level of CI

-Stephen

BTW, CD is more useful with SaaS than with shipping physical media

>
>> -----Original Message-----
>> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
>> Sent: Monday, November 08, 2010 9:51 AM
>> To: Maven Users List
>> Subject: Re: Continuous Delivery and Maven
>>
>> CI does not end up on production systems, so CI does not require as
>> rigourously reproducible a build as CD.
>>
>> With CI, what you want to have happen is the latest code ends up on an
>> integration system and integration tests are run against the
>> integration system in order to identify integration issues before the
>> code goes to QA.
>>
>> With CD you have as much of the QA process automated as you are
>> comfrtable with, and when you kick off a build, it will automatically
>> run though an entirely automated process that ends up with the build
>> either failing or being deployed onto the live system... (note that
>> you might have one or two manual verifications before deploying to
>> production systems, but sooner or later you will have developed enough
>> confidence in your CD process that you can feel confident removing the
>> manual blocks)
>>
>> With CI, I can quite happily work with -SNAPSHOTs because all I need
>> to know is that something is broken.
>>
>> With CD, I need releases (but perhaps more lightweight than Maven's
>> current release process... perhaps I do not need to create tags).
>>
>> The question is what triggers the deploy in CD.
>>
>> There are a number of possible triggers:
>>
>> 1. Manual trigger... where I click a button and the whole process starts
>> 2. CI trigger... where a CI build passing triggers the whole process
>> 3. Commit trigger... where any commit triggers the whole process.
>>
>> The problem with #1 is that you have to remember to trigger
>>
>> If you are doing CD correctly, then #2 and #3 are actually the same
>> thing with just a re-ordered pipeline.
>>
>> #2 goes a little something like this
>> 2.1 A commit triggers a build
>> 2.2 The build passes and triggers a CI build
>> 2.3 The CI build deploys to the integration system and runs the
>> integration tests
>> 2.4 The CI build passes and triggers the CD build
>> 2.5 The CD build runs a release of the software
>> 2.6 The CD build deploys the release to the integration system and
>> runs the integration tests
>> 2.7 The CD build runs the last ditch "no egg on face" tests that could
>> take a bit longer than integration tests (e.g. full regression)
>> 2.8 All tests have passed and the CD build meets the release to
>> customer criteria
>> 2.9 The CD build deploys the release to production systems
>> 2.10 we are live
>>
>> while #3 goes a little something like this
>> 3.1 The CD build runs a release of the software
>> 3.2 The CD build deploys the release to the integration system and
>> runs the integration tests
>> 3.3 The CD build runs the last ditch "no egg on face" tests that could
>> take a bit longer than integration tests (e.g. full regression)
>> 3.4 All tests have passed and the CD build meets the release to
>> customer criteria
>> 3.5 The CD build deploys the release to production systems
>> 3.6 we are live
>>
>> #2 saves on the churn of making releases but reduces the response time
>> for deployment.
>>
>> In any case you also want an automated process that allows you to roll
>> the production system back to a previous state just in case the "no
>> egg on face" tests let some egg slip through to your face!
>>
>> -Stephen
>> On 8 November 2010 14:27, Thiessen, Todd (Todd) <tt...@avaya.com>
>> wrote:
>> > True. But how does that change my statement? It still appears we may
>> have a different definition of CI.  Because in order to do CD, you would
>> no longer be doing CI.
>> >
>> > Unless of course the original poster is suggesting to abandon CI.
>> >
>> >> -----Original Message-----
>> >> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
>> >> Sent: Monday, November 08, 2010 9:17 AM
>> >> To: Maven Users List
>> >> Subject: Re: Continuous Delivery and Maven
>> >>
>> >> On 8 November 2010 13:30, Thiessen, Todd (Todd) <tt...@avaya.com>
>> >> wrote:
>> >> > Interestingly enough, I kind of feel that we have a different
>> >> definition of continuous integration.
>> >> >
>> >>
>> >> Interestingly enought, the original poster is talking about Continuous
>> >> _D_E_L_I_V_E_R_Y_ as distinct fron Continuous Integrration ;-)
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: users-help@maven.apache.org
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: users-help@maven.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Thiessen, Todd (Todd)" <tt...@avaya.com>]

I agree with most of your points here Stephen. Sounds like we may be in "violent" agreement ;-).

The point that I disagree with is trigging a CD off a commit or CI build. You don't need to ALWAYS be doing CD. If you are at the start of a release, your product owner will have a good idea of how much content needs to get to the customer to fullfill that release. Doing CD through the entire lifecycle is largely a waste IMHO.

And it isn't just a waste of hard drive or other "mechanical" resources. It just adds complexity to your lifecycle and processes that just aren't needed. If you know you are not delivering to a customer for a couple of months, stick with snapshots so you can more easily do CI. If you are doing CD all the time, it makes CI much more difficult and complicated.

I am all for automating CD. But not at the cost of making CI more complicated.

Or perhaps you are thinking that CI wouldn't be affected at all?

BTW. We deploy our snapshot builds to a live system and do real functional testing of a snapshot install.  But this is still not a release build and thus wouldn't go to a final customer.  I think the line here between CI and CD is blurred.

> -----Original Message-----
> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> Sent: Monday, November 08, 2010 9:51 AM
> To: Maven Users List
> Subject: Re: Continuous Delivery and Maven
> 
> CI does not end up on production systems, so CI does not require as
> rigourously reproducible a build as CD.
> 
> With CI, what you want to have happen is the latest code ends up on an
> integration system and integration tests are run against the
> integration system in order to identify integration issues before the
> code goes to QA.
> 
> With CD you have as much of the QA process automated as you are
> comfrtable with, and when you kick off a build, it will automatically
> run though an entirely automated process that ends up with the build
> either failing or being deployed onto the live system... (note that
> you might have one or two manual verifications before deploying to
> production systems, but sooner or later you will have developed enough
> confidence in your CD process that you can feel confident removing the
> manual blocks)
> 
> With CI, I can quite happily work with -SNAPSHOTs because all I need
> to know is that something is broken.
> 
> With CD, I need releases (but perhaps more lightweight than Maven's
> current release process... perhaps I do not need to create tags).
> 
> The question is what triggers the deploy in CD.
> 
> There are a number of possible triggers:
> 
> 1. Manual trigger... where I click a button and the whole process starts
> 2. CI trigger... where a CI build passing triggers the whole process
> 3. Commit trigger... where any commit triggers the whole process.
> 
> The problem with #1 is that you have to remember to trigger
> 
> If you are doing CD correctly, then #2 and #3 are actually the same
> thing with just a re-ordered pipeline.
> 
> #2 goes a little something like this
> 2.1 A commit triggers a build
> 2.2 The build passes and triggers a CI build
> 2.3 The CI build deploys to the integration system and runs the
> integration tests
> 2.4 The CI build passes and triggers the CD build
> 2.5 The CD build runs a release of the software
> 2.6 The CD build deploys the release to the integration system and
> runs the integration tests
> 2.7 The CD build runs the last ditch "no egg on face" tests that could
> take a bit longer than integration tests (e.g. full regression)
> 2.8 All tests have passed and the CD build meets the release to
> customer criteria
> 2.9 The CD build deploys the release to production systems
> 2.10 we are live
> 
> while #3 goes a little something like this
> 3.1 The CD build runs a release of the software
> 3.2 The CD build deploys the release to the integration system and
> runs the integration tests
> 3.3 The CD build runs the last ditch "no egg on face" tests that could
> take a bit longer than integration tests (e.g. full regression)
> 3.4 All tests have passed and the CD build meets the release to
> customer criteria
> 3.5 The CD build deploys the release to production systems
> 3.6 we are live
> 
> #2 saves on the churn of making releases but reduces the response time
> for deployment.
> 
> In any case you also want an automated process that allows you to roll
> the production system back to a previous state just in case the "no
> egg on face" tests let some egg slip through to your face!
> 
> -Stephen
> On 8 November 2010 14:27, Thiessen, Todd (Todd) <tt...@avaya.com>
> wrote:
> > True. But how does that change my statement? It still appears we may
> have a different definition of CI.  Because in order to do CD, you would
> no longer be doing CI.
> >
> > Unless of course the original poster is suggesting to abandon CI.
> >
> >> -----Original Message-----
> >> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> >> Sent: Monday, November 08, 2010 9:17 AM
> >> To: Maven Users List
> >> Subject: Re: Continuous Delivery and Maven
> >>
> >> On 8 November 2010 13:30, Thiessen, Todd (Todd) <tt...@avaya.com>
> >> wrote:
> >> > Interestingly enough, I kind of feel that we have a different
> >> definition of continuous integration.
> >> >
> >>
> >> Interestingly enought, the original poster is talking about Continuous
> >> _D_E_L_I_V_E_R_Y_ as distinct fron Continuous Integrration ;-)
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[Stephen Connolly <st...@gmail.com>]

CI does not end up on production systems, so CI does not require as
rigourously reproducible a build as CD.

With CI, what you want to have happen is the latest code ends up on an
integration system and integration tests are run against the
integration system in order to identify integration issues before the
code goes to QA.

With CD you have as much of the QA process automated as you are
comfrtable with, and when you kick off a build, it will automatically
run though an entirely automated process that ends up with the build
either failing or being deployed onto the live system... (note that
you might have one or two manual verifications before deploying to
production systems, but sooner or later you will have developed enough
confidence in your CD process that you can feel confident removing the
manual blocks)

With CI, I can quite happily work with -SNAPSHOTs because all I need
to know is that something is broken.

With CD, I need releases (but perhaps more lightweight than Maven's
current release process... perhaps I do not need to create tags).

The question is what triggers the deploy in CD.

There are a number of possible triggers:

1. Manual trigger... where I click a button and the whole process starts
2. CI trigger... where a CI build passing triggers the whole process
3. Commit trigger... where any commit triggers the whole process.

The problem with #1 is that you have to remember to trigger

If you are doing CD correctly, then #2 and #3 are actually the same
thing with just a re-ordered pipeline.

#2 goes a little something like this
2.1 A commit triggers a build
2.2 The build passes and triggers a CI build
2.3 The CI build deploys to the integration system and runs the
integration tests
2.4 The CI build passes and triggers the CD build
2.5 The CD build runs a release of the software
2.6 The CD build deploys the release to the integration system and
runs the integration tests
2.7 The CD build runs the last ditch "no egg on face" tests that could
take a bit longer than integration tests (e.g. full regression)
2.8 All tests have passed and the CD build meets the release to
customer criteria
2.9 The CD build deploys the release to production systems
2.10 we are live

while #3 goes a little something like this
3.1 The CD build runs a release of the software
3.2 The CD build deploys the release to the integration system and
runs the integration tests
3.3 The CD build runs the last ditch "no egg on face" tests that could
take a bit longer than integration tests (e.g. full regression)
3.4 All tests have passed and the CD build meets the release to
customer criteria
3.5 The CD build deploys the release to production systems
3.6 we are live

#2 saves on the churn of making releases but reduces the response time
for deployment.

In any case you also want an automated process that allows you to roll
the production system back to a previous state just in case the "no
egg on face" tests let some egg slip through to your face!

-Stephen
On 8 November 2010 14:27, Thiessen, Todd (Todd) <tt...@avaya.com> wrote:
> True. But how does that change my statement? It still appears we may have a different definition of CI.  Because in order to do CD, you would no longer be doing CI.
>
> Unless of course the original poster is suggesting to abandon CI.
>
>> -----Original Message-----
>> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
>> Sent: Monday, November 08, 2010 9:17 AM
>> To: Maven Users List
>> Subject: Re: Continuous Delivery and Maven
>>
>> On 8 November 2010 13:30, Thiessen, Todd (Todd) <tt...@avaya.com>
>> wrote:
>> > Interestingly enough, I kind of feel that we have a different
>> definition of continuous integration.
>> >
>>
>> Interestingly enought, the original poster is talking about Continuous
>> _D_E_L_I_V_E_R_Y_ as distinct fron Continuous Integrration ;-)
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Thiessen, Todd (Todd)" <tt...@avaya.com>]

True. But how does that change my statement? It still appears we may have a different definition of CI.  Because in order to do CD, you would no longer be doing CI.

Unless of course the original poster is suggesting to abandon CI.

> -----Original Message-----
> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> Sent: Monday, November 08, 2010 9:17 AM
> To: Maven Users List
> Subject: Re: Continuous Delivery and Maven
> 
> On 8 November 2010 13:30, Thiessen, Todd (Todd) <tt...@avaya.com>
> wrote:
> > Interestingly enough, I kind of feel that we have a different
> definition of continuous integration.
> >
> 
> Interestingly enought, the original poster is talking about Continuous
> _D_E_L_I_V_E_R_Y_ as distinct fron Continuous Integrration ;-)
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[Stephen Connolly <st...@gmail.com>]

On 8 November 2010 13:30, Thiessen, Todd (Todd) <tt...@avaya.com> wrote:
> Interestingly enough, I kind of feel that we have a different definition of continuous integration.
>

Interestingly enought, the original poster is talking about Continuous
_D_E_L_I_V_E_R_Y_ as distinct fron Continuous Integrration ;-)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Thiessen, Todd (Todd)" <tt...@avaya.com>]

Interestingly enough, I kind of feel that we have a different definition of continuous integration.

You generally don't want to, and hopefully very rarely need to, go back to a specific revision.  The whole idea is that you are always reproducing problems on the latest version of your project's trunk and all latest trunks of all its dependencies.  Reproducing it on a specific revision has little value. If you are not reproducing, fixes and adding new features on the latest trunk, then you are not really doing continuous integration.

Why? Older revisions are simply just that; old. If you do go back and reproduce it on a specific revision, you still have to fix and reproduce on the latest trunk. 99% of the time, you can go right to the latter. For this, Maven is excellent and is what I would hope you are your book would recommend.

For those few cases where you do need to reproduce a specific revision and all of its dependencies, you are right, it can get very messy with snapshots everywhere.  I think you are making a mountain out of mole hill here.

> -----Original Message-----
> From: jhumble [mailto:jez@jezhumble.net]
> Sent: Sunday, November 07, 2010 11:41 PM
> To: users@maven.apache.org
> Subject: Re: Continuous Delivery and Maven
> 
> 
> Hi Curtis
> 
> I'm the first to admit I'm no Maven expert.
> 
> So please let me just confirm. Let's assume I am working on project A
> which
> depends on projects B and C. For the sake of argument, let's say that the
> source code for A, B and C have separate roots in SVN, and are usually
> checked out independently. The CI system builds A at version 50 using
> snapshot dependencies on B and C, which are fetched from a central
> snapshot
> repository.
> 
> Later, there are multiple updates to projects B and C which result in new
> versions of them becoming available.
> 
> Say I now check out the source code to project A to version 50, because I
> want to try and debug some issue that cropped up in a performance testing
> environment, and I run a maven build. Will that use the latest versions
> of
> the snapshots from the repo, or the versions that were originally fetched
> when it was run on the CI system?
> 
> Can I even find out exactly which versions from svn the snapshots of B
> and C
> came from that were used by the CI system to generate the original build
> of
> A?
> 
> Thanks,
> 
> Jez.
> 
> On 7 November 2010 20:10, Yanko, Curtis [via Maven] <
> ml-node+3254520-1036569885-143561@n5.nabble.com<ml-node%2B3254520-
> 1036569885-143561@n5.nabble.com>
> > wrote:
> 
> > Very interesting discussion. With all due respect to Mr. Humble, and I
> > am a big fan of CD, I am going to venture to say that you don't
> > understand Maven very well. As a thought experiment, you are correct in
> > saying that a build based on snapshots is not reproducible. As a more
> > practical matter however, I feel it is.
> >
> > Dependencies come in two flavors, our and theirs (internal and 3rd
> > party). If, all of *our* dependencies are SNAPSHOT (we're doing the
> > developing) and all of *theirs* are 'versioned' then the build is in
> > fact reproducible assuming you build everything from a particular repo
> > version even with the default auto-update setting (in fact, it's
> > required).
> > ________________________________
> >
> > Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
> > Making IT Happen, one build at a time, 600 times a day
> >
> > -----Original Message-----
> > From: jhumble [mailto:[hidden
> email]<http://user/SendEmail.jtp?type=node&node=3254520&i=0>]
> >
> > Sent: Sunday, November 07, 2010 11:15 AM
> > To: [hidden email]
> <http://user/SendEmail.jtp?type=node&node=3254520&i=1>
> > Subject: RE: Continuous Delivery and Maven
> >
> >
> > Hey Todd
> >
> > The whole point of continuous delivery is that every check-in creates a
> > potential release candidate.
> >
> > When you're doing continuous deployment, you could be releasing
> multiple
> > times a day, so you don't bother cutting branches or tagging or any of
> > that stuff because of the overhead. I'd rather not get into the
> > justification for this process on this thread - but I wrote a book on
> it
> > if you're interested:
> > http://www.amazon.com/gp/product/0321601912 and many other people have
> > blogged about it.
> >
> > You're right that creating a concrete release for each commit could
> > potentially use up a lot of space - but that's fine, you can just
> delete
> > the older ones. What this *does* mean in turn though is that it is
> > essential to be able to recreate any given build given the version in
> > source control it came from, and this is where Maven falls down.
> > Snapshots just aren't suitable because they aren't reproducible: what
> > the snapshot looks like depends not only on what versions of the
> > dependencies are available at the time the snapshot is created, but
> also
> > what Maven's configuration and plug-ins happen to be at the time you
> run
> > it (assuming Maven is configured to auto-update - the default). I can't
> > revert back to a particular revision in version control, run maven, and
> > be sure that the artifact it generates is identical to the one it
> > created when the commit was initially triggered.
> >
> > Ideally what I'd like is for Maven to explicitly support the continuous
> > delivery model and provide snapshots that are reproducible. Failing
> > that, a guide to configuring Maven so that its binaries are
> reproducible
> > (for example by switching off auto-update, and having sufficient
> > metadata stored in pom files and Maven's artifacts repository to know
> > what the state of each of the dependencies was at any given time.
> > --
> > View this message in context:
> > http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-
> tp3245370<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-
> tp3245370?by-user=t>
> > p3254090.html
> > Sent from the Maven - Users mailing list archive at Nabble.com.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden
> email]<http://user/SendEmail.jtp?type=node&node=3254520&i=2>
> > For additional commands, e-mail: [hidden
> email]<http://user/SendEmail.jtp?type=node&node=3254520&i=3>
> >
> >
> > This e-mail, including attachments, may include confidential and/or
> > proprietary information, and may be used only by the person or entity
> > to which it is addressed. If the reader of this e-mail is not the
> intended
> > recipient or his or her authorized agent, the reader is hereby notified
> > that any dissemination, distribution or copying of this e-mail is
> > prohibited. If you have received this e-mail in error, please notify
> the
> > sender by replying to this message and delete this e-mail immediately.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden
> email]<http://user/SendEmail.jtp?type=node&node=3254520&i=4>
> > For additional commands, e-mail: [hidden
> email]<http://user/SendEmail.jtp?type=node&node=3254520&i=5>
> >
> >
> >
> > ------------------------------
> >  View message @
> > http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-
> tp3245370p3254520.html
> > To unsubscribe from Continuous Delivery and Maven, click
> here<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubsc
> ribe_by_code&node=3245370&code=amV6QGplemh1bWJsZS5uZXR8MzI0NTM3MHwtMTg4Mj
> M1NzMyNA==>.
> >
> >
> >
> 
> 
> --
> Jez Humble
> Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
> http://continuousdelivery.com/
> http://jezhumble.net/
> 
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-
> tp3245370p3254534.html
> Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[jhumble <je...@jezhumble.net>]

Hi Curtis

I'm the first to admit I'm no Maven expert.

So please let me just confirm. Let's assume I am working on project A which
depends on projects B and C. For the sake of argument, let's say that the
source code for A, B and C have separate roots in SVN, and are usually
checked out independently. The CI system builds A at version 50 using
snapshot dependencies on B and C, which are fetched from a central snapshot
repository.

Later, there are multiple updates to projects B and C which result in new
versions of them becoming available.

Say I now check out the source code to project A to version 50, because I
want to try and debug some issue that cropped up in a performance testing
environment, and I run a maven build. Will that use the latest versions of
the snapshots from the repo, or the versions that were originally fetched
when it was run on the CI system?

Can I even find out exactly which versions from svn the snapshots of B and C
came from that were used by the CI system to generate the original build of
A?

Thanks,

Jez.

On 7 November 2010 20:10, Yanko, Curtis [via Maven] <
ml-node+3254520-1036569885-143561@n5.nabble.com<ml...@n5.nabble.com>
> wrote:

> Very interesting discussion. With all due respect to Mr. Humble, and I
> am a big fan of CD, I am going to venture to say that you don't
> understand Maven very well. As a thought experiment, you are correct in
> saying that a build based on snapshots is not reproducible. As a more
> practical matter however, I feel it is.
>
> Dependencies come in two flavors, our and theirs (internal and 3rd
> party). If, all of *our* dependencies are SNAPSHOT (we're doing the
> developing) and all of *theirs* are 'versioned' then the build is in
> fact reproducible assuming you build everything from a particular repo
> version even with the default auto-update setting (in fact, it's
> required).
> ________________________________
>
> Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
> Making IT Happen, one build at a time, 600 times a day
>
> -----Original Message-----
> From: jhumble [mailto:[hidden email]<http://user/SendEmail.jtp?type=node&node=3254520&i=0>]
>
> Sent: Sunday, November 07, 2010 11:15 AM
> To: [hidden email] <http://user/SendEmail.jtp?type=node&node=3254520&i=1>
> Subject: RE: Continuous Delivery and Maven
>
>
> Hey Todd
>
> The whole point of continuous delivery is that every check-in creates a
> potential release candidate.
>
> When you're doing continuous deployment, you could be releasing multiple
> times a day, so you don't bother cutting branches or tagging or any of
> that stuff because of the overhead. I'd rather not get into the
> justification for this process on this thread - but I wrote a book on it
> if you're interested:
> http://www.amazon.com/gp/product/0321601912 and many other people have
> blogged about it.
>
> You're right that creating a concrete release for each commit could
> potentially use up a lot of space - but that's fine, you can just delete
> the older ones. What this *does* mean in turn though is that it is
> essential to be able to recreate any given build given the version in
> source control it came from, and this is where Maven falls down.
> Snapshots just aren't suitable because they aren't reproducible: what
> the snapshot looks like depends not only on what versions of the
> dependencies are available at the time the snapshot is created, but also
> what Maven's configuration and plug-ins happen to be at the time you run
> it (assuming Maven is configured to auto-update - the default). I can't
> revert back to a particular revision in version control, run maven, and
> be sure that the artifact it generates is identical to the one it
> created when the commit was initially triggered.
>
> Ideally what I'd like is for Maven to explicitly support the continuous
> delivery model and provide snapshots that are reproducible. Failing
> that, a guide to configuring Maven so that its binaries are reproducible
> (for example by switching off auto-update, and having sufficient
> metadata stored in pom files and Maven's artifacts repository to know
> what the state of each of the dependencies was at any given time.
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370?by-user=t>
> p3254090.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3254520&i=2>
> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3254520&i=3>
>
>
> This e-mail, including attachments, may include confidential and/or
> proprietary information, and may be used only by the person or entity
> to which it is addressed. If the reader of this e-mail is not the intended
> recipient or his or her authorized agent, the reader is hereby notified
> that any dissemination, distribution or copying of this e-mail is
> prohibited. If you have received this e-mail in error, please notify the
> sender by replying to this message and delete this e-mail immediately.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3254520&i=4>
> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3254520&i=5>
>
>
>
> ------------------------------
>  View message @
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3254520.html
> To unsubscribe from Continuous Delivery and Maven, click here<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_code&node=3245370&code=amV6QGplemh1bWJsZS5uZXR8MzI0NTM3MHwtMTg4MjM1NzMyNA==>.
>
>
>


-- 
Jez Humble
Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
http://continuousdelivery.com/
http://jezhumble.net/

-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3254534.html
Sent from the Maven - Users mailing list archive at Nabble.com.

RE: Continuous Delivery and Maven

["Yanko, Curtis" <cu...@uhc.com>]

Very interesting discussion. With all due respect to Mr. Humble, and I
am a big fan of CD, I am going to venture to say that you don't
understand Maven very well. As a thought experiment, you are correct in
saying that a build based on snapshots is not reproducible. As a more
practical matter however, I feel it is.

Dependencies come in two flavors, our and theirs (internal and 3rd
party). If, all of *our* dependencies are SNAPSHOT (we're doing the
developing) and all of *theirs* are 'versioned' then the build is in
fact reproducible assuming you build everything from a particular repo
version even with the default auto-update setting (in fact, it's
required).
________________________________

Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
Making IT Happen, one build at a time, 600 times a day

-----Original Message-----
From: jhumble [mailto:jez@jezhumble.net] 
Sent: Sunday, November 07, 2010 11:15 AM
To: users@maven.apache.org
Subject: RE: Continuous Delivery and Maven


Hey Todd

The whole point of continuous delivery is that every check-in creates a
potential release candidate.

When you're doing continuous deployment, you could be releasing multiple
times a day, so you don't bother cutting branches or tagging or any of
that stuff because of the overhead. I'd rather not get into the
justification for this process on this thread - but I wrote a book on it
if you're interested:
http://www.amazon.com/gp/product/0321601912 and many other people have
blogged about it.

You're right that creating a concrete release for each commit could
potentially use up a lot of space - but that's fine, you can just delete
the older ones. What this *does* mean in turn though is that it is
essential to be able to recreate any given build given the version in
source control it came from, and this is where Maven falls down.
Snapshots just aren't suitable because they aren't reproducible: what
the snapshot looks like depends not only on what versions of the
dependencies are available at the time the snapshot is created, but also
what Maven's configuration and plug-ins happen to be at the time you run
it (assuming Maven is configured to auto-update - the default). I can't
revert back to a particular revision in version control, run maven, and
be sure that the artifact it generates is identical to the one it
created when the commit was initially triggered.

Ideally what I'd like is for Maven to explicitly support the continuous
delivery model and provide snapshots that are reproducible. Failing
that, a guide to configuring Maven so that its binaries are reproducible
(for example by switching off auto-update, and having sufficient
metadata stored in pom files and Maven's artifacts repository to know
what the state of each of the dependencies was at any given time.
--
View this message in context:
http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370
p3254090.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[Ron Wheeler <rw...@artifact-software.com>]

I don't use CI or CD, so you can take my opinions with a grain of salt

My understanding that an application that gets to a CD stage, is ready 
for testing by human beings.
In order to test an application, people need to know what the system is 
supposed to do.
If a person tests a search function  at the CD stage and it always 
returns "John Smith" regardless of criteria, this would be flagged as an 
error.
At this point, I would expect that any behaviour that does not meet the 
spec would require the creation of a trouble ticket.

My understanding is that CI will work very well with SNAPSHOTS.

However, a SNAPSHOT will pass all of its tests even though it may only 
offer stub functions and be tested with mock data.
A SNAPSHOT passes to a "Release Candidate" when the functionality meets 
the specification and it is ready to be tested with real data and will 
interact with the rest of the system according to the specifications.

It makes no sense to me to allow a SNAPSHOT through a CI stage to a CD 
stage.
This would create chaos in the testing group as they would be generating 
all kinds of trouble tickets for nothing.

In my opinion, the use of SNAPSHOTs is essential to an organization 
using CD simply to prevent the CD stage from kicking in as long as there 
is a SNAPSHOT in the CI process. If you do allow SNAPSHOTs into the CD 
stage, this should be a big red flag to the QA team that trouble tickets 
should not be raised and that testing should be closely coordinated with 
the development team to avoid wasting time and pissing off team members.

Ron


On 09/11/2010 6:16 AM, Kief wrote:
>
> Thiessen, Todd (Todd) wrote:
>> Imagine trying to have a CI build while always having enough information
>> in the pom to point to an exact version of your dependencies? Lets say I
>> get a feature working in my checkout, and do a build locally before
>> committing.  The build would have to point to a fixed version of all my
>> dependencies.  If the dependencies change while I am working, they would
>> have to change "on the fly".
>>
>> But of course the formal CI build would also have to ensure it points to
>> the latest fixed version of all dependencies. It would have to modify the
>> pom "on the fly" and it could change to point to a more recent version of
>> a dependency since there is time between when I run the build in my
>> checkout and the time I commit.
>>
> I don't think it's necessary for the local developer builds to be pinned to
> specific versions of dependencies; pinning only needs to happen on commit,
> probably as part of the CI. So the CI would pull together the latest version
> of each dependency at that point in time, and make sure the information is
> included in the artefact.
>
>
> Thiessen, Todd (Todd) wrote:
>> I am against the idea of having an automated process massaging a snapshot
>> and turning it into a release. You simply run the risk of building
>> something that you didn't anticipate. If you want to build a release,
>> build a formal release. This will include ensuring that all of your
>> transtive dependencies are also a formal release. That way you control
>> exactly what revision of what transitive dependencies will be built as a
>> release.
>>
> Reading through this thread, I see two unreconcilable processes for managing
> the build ->  release cycle. One involves running builds through CI with no
> intention of releasing them to production. Call it "progressive delivery",
> since you're progressively building your code to the point where you're
> ready to release it. The other approach involves assuming that any build
> that passes CI will be promoted to the next stage, and may eventually reach
> production, i.e. "continuous delivery".
>
> Although the two approaches are essentially unreconcilable for a given
> project, I don't see any reason why Maven can't support both. The main
> obstacle seems to be resistance to the validity of alternative processes.
>
> I don't think continuous delivery requires massaging snapshots; personally I
> think Maven's snapshot concept isn't useful for CD. Each CI build needs to
> be treated as a release, and dependencies from other teams should only be
> pulled from builds that have passed CI. Promotion of a build through the
> pipeline shouldn't involve fiddling with the artefact, but should be managed
> externally by whatever toolset you're using to manage the pipeline.
>
> CD may or may not require modification to Maven and/or plugins to inject the
> information (at CI) needed to rebuild it. It sounds to me that if the build
> and its dependencies are all treated as releases rather than snapshots, the
> information is probably in there.
>
> Does anyone have a reason why Maven snapshots would be useful or necessary
> to a project following CD?
>
> Kief
>
>> -----Original Message-----
>> From: stug23 [mailto:pat.podenski@gmail.com]
>> Sent: Sunday, November 07, 2010 12:17 PM
>> To: users@maven.apache.org
>> Subject: RE: Continuous Delivery and Maven
>>
>>
>> I suspect that there is a reasonable way to adjust the builds in Maven
>> such
>> that they robustly support Continuous Delivery. I know that Jason van Zyl
>> has started looking at CD as well.
>>
>> On the Google forum
>> <http://groups.google.com/group/continuousdelivery/browse_thread/thread/c
>> 8440681058f2db8>
>> Chris Hilton commented:
>>
>> 3. In my ideal world, I would probably either extend the release
>> plugin or write a new one with functionality to take a snapshot
>> artifact and make it a release artifact, which would still introduce
>> slight changes but pretty mild ones. I thought I had read a feature
>> request or wish list about this, but can't find it now.
>>
>> The current Maven release plugin, as it is, was not designed to handle
>> the
>> notion of CD. So it does make sense to tailor this aspect of releasing
>> Maven
>> artifacts to better support CD.
>>
>> Also a quick examination of the Maven versions plugin shows that it has
>> facilities to handle updating versions of projects and their
>> dependencies.
>> So it looks as if it is more a matter of adjustment of Maven build to
>> produce a result that aligns with CD than a matter of Maven not being
>> suitable for CD. I think that the main stumbling block is SNAPSHOTS
>> because
>> they inherently are not releasable -- part of the process of releasing
>> with
>> the current Maven release plugin is to fail when there are SNAPSHOT
>> dependencies.
>>
>> Another clear requirement for any changes to Maven or its build behavior
>> is
>> that the current behavior must be maintained for the many projects that
>> haven't embraced (or won't embrace) Continuous Delivery. So I imagine a
>> Maven build's behavior being altered through configuration (or a switch
>> of
>> some sort) to comply with the desired behavior inherent in Continuous
>> Delivery with respect to the release of artifacts. The major difference
>> would appear to be with the SNAPSHOT dependencies and the Maven release
>> process. Other aspects of Maven are for the most part already good as
>> they
>> are for CD.
>>
>> This is an interesting challenge that I am sure is best served by a
>> thorough
>> examination by the Maven and CD experts out there.
>> --
>> View this message in context:
>> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-
>> tp3245370p3254121.html
>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[jhumble <je...@jezhumble.net>]

Curt makes a good point - you can do CI without doing CD. The snapshot stuff
works just fine with CI.

It seems to be a tool that is prone to being used foolishly


I think that's probably true of any sufficiently powerful tool or technique.

Jez.

On 15 November 2010 10:23, Yanko, Curtis [via Maven] <
ml-node+3266162-1775935974-143561@n5.nabble.com<ml...@n5.nabble.com>
> wrote:

> I can't help but feel you are confusing the discussion on CD with CI
> which to me, is mostly a natural progression and maturity of a good
> build system.
>
> The other good news is, you don't have to use it foolishly if you choose
> not too! ;-)
>
> > -----Original Message-----
> > From: Ron Wheeler [mailto:[hidden email]<http://user/SendEmail.jtp?type=node&node=3266162&i=0>]
>
> > Sent: Monday, November 15, 2010 10:28 AM
> > To: [hidden email]<http://user/SendEmail.jtp?type=node&node=3266162&i=1>
> > Subject: Re: Continuous Delivery and Maven
> >
> > On 15/11/2010 8:18 AM, Yanko, Curtis wrote:
> > > You're happy about NOT using CI????
> > >
> > Yes. It seems to be a tool that is prone to being used foolishly.
> >
> > We are a small shop maintaining and developing a large
> > (70+POM files) portal application with portlets, web
> > services, servlets and batch process and do not seem to  have
> > the types of issues that the people, trying to use CI, bring
> > to the table.
> >
> > They seem to get into all kinds of troubles with SNAPSHOTs,
> > build repeatability, source control and architectures that
> > are too interdependent.
> > I can not see how they ever test anything with a continually
> > unstable CI build.
> >
> > Of course, I know that I am only seeing the worst cases in
> > the forum so my mind is not completely closed on the subject.
> > I can hardly wait until we have a "Best Practice" section on
> > the Maven site so that I can see how a CI should be
> > integrated into a Maven environment and perhaps that will
> > make me unhappy that I an not using CI.
> >
> >
> > Ron
> > >> -----Original Message-----
> > >> From: Ron Wheeler [mailto:[hidden email]<http://user/SendEmail.jtp?type=node&node=3266162&i=2>]
>
> > >> Sent: Saturday, November 13, 2010 2:05 PM
> > >> To: [hidden email]<http://user/SendEmail.jtp?type=node&node=3266162&i=3>
> > >> Subject: Re: Continuous Delivery and Maven
> > >>
> > >> I would add the following bits of reality.
> > >> We don't use CI and a lot of the discussion makes me very
> > happy about
> > >> that.
> > >>
> > >
> > > -Curt
> > >
> > > This e-mail, including attachments, may include confidential and/or
> > > proprietary information, and may be used only by the person
> > or entity
> > > to which it is addressed. If the reader of this e-mail is not the
> > > intended recipient or his or her authorized agent, the reader is
> > > hereby notified that any dissemination, distribution or copying of
> > > this e-mail is prohibited. If you have received this e-mail
> > in error,
> > > please notify the sender by replying to this message and
> > delete this e-mail immediately.
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3266162&i=4>
> > > For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3266162&i=5>
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3266162&i=6>
> > For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3266162&i=7>
> >
> >
>
> This e-mail, including attachments, may include confidential and/or
> proprietary information, and may be used only by the person or entity
> to which it is addressed. If the reader of this e-mail is not the intended
> recipient or his or her authorized agent, the reader is hereby notified
> that any dissemination, distribution or copying of this e-mail is
> prohibited. If you have received this e-mail in error, please notify the
> sender by replying to this message and delete this e-mail immediately.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3266162&i=8>
> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3266162&i=9>
>
>
>
> ------------------------------
>  View message @
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3266162.html
> To unsubscribe from Continuous Delivery and Maven, click here<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_code&node=3245370&code=amV6QGplemh1bWJsZS5uZXR8MzI0NTM3MHwtMTg4MjM1NzMyNA==>.
>
>
>


-- 
Jez Humble
Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
http://continuousdelivery.com/
http://jezhumble.net/

-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3266176.html
Sent from the Maven - Users mailing list archive at Nabble.com.

Re: Continuous Delivery and Maven

[Ron Wheeler <rw...@artifact-software.com>]

On 15/11/2010 11:23 AM, jhumble wrote:
>> I would like to see the whole "Best Practice" described. I would like
>> to see how Hudson users deal with mock data and incremental development
>> and testing of on-line applications where the MC and V teams are
>> working together towards a fully functional system or a working bug fix or
>> minor enhancement. How does one manage a production environment  with
>> released systems functioning while new releases are being developed and
>> patches are being applied to the current release?
>
> Without wanting to bang my own drum too much, I just co-authored an entire
> book which covers these topics in detail: Continuous Delivery
> http://www.amazon.com/gp/product/0321601912?tag=contindelive-20
>

Read the sample pages. Nicely written. From the Table of Contents, it 
seems to cover a lot of ground.
Some of the sections look short but the details are probably more 
appropriately covered in other books.

We do not yet have a lot of the problems that are described and I am not 
clear on how CD would help us but your book will certainly be read (as 
much as I get to read anything anymore) before we start down that road.

Thanks for point it out in the forum

Ron

> On 15 November 2010 07:58, Ron Wheeler [via Maven]<
> ml-node+3265918-383914585-143561@n5.nabble.com<ml...@n5.nabble.com>
>> wrote:
>> On 15/11/2010 10:41 AM, Benson Margulies wrote:
>>> Ron,
>>>
>>> It's not too hard to set up a CI process (e.g. on Hudson) that tests
>>> the latest version of everything. Don't publish snapshots to your
>>> repo, set up the cascade of jobs to share correctly.
>>>
>>> If that answers a question that is useful to you, great.
>>>
>> It is never as hard as people seem to think to set something up so that
>> it works correctly but I am amazed at the hacked up development process
>> that get described here.
>>
>> I would like to see the whole "Best Practice" described. I would like to
>> see how Hudson users deal with mock data and incremental development and
>> testing of on-line applications where the MC and V teams are working
>> together towards a fully functional system or a working bug fix or minor
>> enhancement.
>> How does one manage a production environment  with released systems
>> functioning while new releases are being developed and patches are being
>> applied to the current release?
>>
>>> If, rather, you need to somehow model all kinds of combinations of
>>> -SNAPSHOT and non-SNAPSHOT dependencies, or you feel compelled to
>>> publish snapshots to your local repo, chaos is just around the corner.
>>>
>> In maintenance and bug-fixing, you do need to mix Releases with
>> SNAPSHOTs to build a full system since you might only be releasing 2
>> portlets out of 50 to add a new small function or fix a bug.  The
>> overhead of rebuilding 70 modules to get 2 fixed is just not something
>> that we can support.
>>
>> We do publish SNAPSHOTS to the internal repo but they come with a
>> warranty and some functional spec that the rest of the team can live with.
>> This does not cause a problem because we know what we are building and
>> know the combination that has to be tested within the scope of each
>> active project.
>>
>>
>> Ron
>>
>>> On Mon, Nov 15, 2010 at 10:27 AM, Ron Wheeler
>>> <[hidden email]<http://user/SendEmail.jtp?type=node&node=3265918&i=0>>
>>   wrote:
>>>> On 15/11/2010 8:18 AM, Yanko, Curtis wrote:
>>>>> You're happy about NOT using CI????
>>>>>
>>>> Yes. It seems to be a tool that is prone to being used foolishly.
>>>>
>>>> We are a small shop maintaining and developing a large (70+POM files)
>> portal
>>>> application with portlets, web services, servlets and batch process and
>> do
>>>> not seem to  have the types of issues that the people, trying to use CI,
>>>> bring to the table.
>>>>
>>>> They seem to get into all kinds of troubles with SNAPSHOTs, build
>>>> repeatability, source control and architectures that are too
>> interdependent.
>>>> I can not see how they ever test anything with a continually unstable CI
>>>> build.
>>>>
>>>> Of course, I know that I am only seeing the worst cases in the forum so
>> my
>>>> mind is not completely closed on the subject.
>>>> I can hardly wait until we have a "Best Practice" section on the Maven
>> site
>>>> so that I can see how a CI should be integrated into a Maven environment
>> and
>>>> perhaps that will make me unhappy that I an not using CI.
>>>>
>>>>
>>>> Ron
>>>>>> -----Original Message-----
>>>>>> From: Ron Wheeler [mailto:[hidden email]<http://user/SendEmail.jtp?type=node&node=3265918&i=1>]
>>>>>> Sent: Saturday, November 13, 2010 2:05 PM
>>>>>> To: [hidden email]<http://user/SendEmail.jtp?type=node&node=3265918&i=2>
>>>>>> Subject: Re: Continuous Delivery and Maven
>>>>>>
>>>>>> I would add the following bits of reality.
>>>>>> We don't use CI and a lot of the discussion makes me very
>>>>>> happy about that.
>>>>>>
>>>>> -Curt
>>>>>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[jhumble <je...@jezhumble.net>]

>
> I would like to see the whole "Best Practice" described. I would like
> to see how Hudson users deal with mock data and incremental development
> and testing of on-line applications where the MC and V teams are
> working together towards a fully functional system or a working bug fix or
> minor enhancement. How does one manage a production environment  with
> released systems functioning while new releases are being developed and
> patches are being applied to the current release?


Without wanting to bang my own drum too much, I just co-authored an entire
book which covers these topics in detail: Continuous Delivery
http://www.amazon.com/gp/product/0321601912?tag=contindelive-20

On 15 November 2010 07:58, Ron Wheeler [via Maven] <
ml-node+3265918-383914585-143561@n5.nabble.com<ml...@n5.nabble.com>
> wrote:

> On 15/11/2010 10:41 AM, Benson Margulies wrote:
> > Ron,
> >
> > It's not too hard to set up a CI process (e.g. on Hudson) that tests
> > the latest version of everything. Don't publish snapshots to your
> > repo, set up the cascade of jobs to share correctly.
> >
> > If that answers a question that is useful to you, great.
> >
> It is never as hard as people seem to think to set something up so that
> it works correctly but I am amazed at the hacked up development process
> that get described here.
>
> I would like to see the whole "Best Practice" described. I would like to
> see how Hudson users deal with mock data and incremental development and
> testing of on-line applications where the MC and V teams are working
> together towards a fully functional system or a working bug fix or minor
> enhancement.
> How does one manage a production environment  with released systems
> functioning while new releases are being developed and patches are being
> applied to the current release?
>
> > If, rather, you need to somehow model all kinds of combinations of
> > -SNAPSHOT and non-SNAPSHOT dependencies, or you feel compelled to
> > publish snapshots to your local repo, chaos is just around the corner.
> >
> In maintenance and bug-fixing, you do need to mix Releases with
> SNAPSHOTs to build a full system since you might only be releasing 2
> portlets out of 50 to add a new small function or fix a bug.  The
> overhead of rebuilding 70 modules to get 2 fixed is just not something
> that we can support.
>
> We do publish SNAPSHOTS to the internal repo but they come with a
> warranty and some functional spec that the rest of the team can live with.
> This does not cause a problem because we know what we are building and
> know the combination that has to be tested within the scope of each
> active project.
>
>
> Ron
>
> >
> > On Mon, Nov 15, 2010 at 10:27 AM, Ron Wheeler
> > <[hidden email] <http://user/SendEmail.jtp?type=node&node=3265918&i=0>>
>  wrote:
> >> On 15/11/2010 8:18 AM, Yanko, Curtis wrote:
> >>> You're happy about NOT using CI????
> >>>
> >> Yes. It seems to be a tool that is prone to being used foolishly.
> >>
> >> We are a small shop maintaining and developing a large (70+POM files)
> portal
> >> application with portlets, web services, servlets and batch process and
> do
> >> not seem to  have the types of issues that the people, trying to use CI,
>
> >> bring to the table.
> >>
> >> They seem to get into all kinds of troubles with SNAPSHOTs, build
> >> repeatability, source control and architectures that are too
> interdependent.
> >> I can not see how they ever test anything with a continually unstable CI
>
> >> build.
> >>
> >> Of course, I know that I am only seeing the worst cases in the forum so
> my
> >> mind is not completely closed on the subject.
> >> I can hardly wait until we have a "Best Practice" section on the Maven
> site
> >> so that I can see how a CI should be integrated into a Maven environment
> and
> >> perhaps that will make me unhappy that I an not using CI.
> >>
> >>
> >> Ron
> >>>> -----Original Message-----
> >>>> From: Ron Wheeler [mailto:[hidden email]<http://user/SendEmail.jtp?type=node&node=3265918&i=1>]
>
> >>>> Sent: Saturday, November 13, 2010 2:05 PM
> >>>> To: [hidden email]<http://user/SendEmail.jtp?type=node&node=3265918&i=2>
> >>>> Subject: Re: Continuous Delivery and Maven
> >>>>
> >>>> I would add the following bits of reality.
> >>>> We don't use CI and a lot of the discussion makes me very
> >>>> happy about that.
> >>>>
> >>> -Curt
> >>>
> >>> This e-mail, including attachments, may include confidential and/or
> >>> proprietary information, and may be used only by the person or entity
> >>> to which it is addressed. If the reader of this e-mail is not the
> intended
> >>> recipient or his or her authorized agent, the reader is hereby notified
>
> >>> that any dissemination, distribution or copying of this e-mail is
> >>> prohibited. If you have received this e-mail in error, please notify
> the
> >>> sender by replying to this message and delete this e-mail immediately.
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3265918&i=3>
> >>> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3265918&i=4>
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3265918&i=5>
> >> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3265918&i=6>
> >>
> >>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3265918&i=7>
> > For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3265918&i=8>
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3265918&i=9>
> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3265918&i=10>
>
>
>
> ------------------------------
>  View message @
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3265918.html
> To unsubscribe from Continuous Delivery and Maven, click here<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_code&node=3245370&code=amV6QGplemh1bWJsZS5uZXR8MzI0NTM3MHwtMTg4MjM1NzMyNA==>.
>
>
>


-- 
Jez Humble
Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
http://continuousdelivery.com/
http://jezhumble.net/

-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3265962.html
Sent from the Maven - Users mailing list archive at Nabble.com.

Re: Continuous Delivery and Maven

[Ron Wheeler <rw...@artifact-software.com>]

On 15/11/2010 10:41 AM, Benson Margulies wrote:
> Ron,
>
> It's not too hard to set up a CI process (e.g. on Hudson) that tests
> the latest version of everything. Don't publish snapshots to your
> repo, set up the cascade of jobs to share correctly.
>
> If that answers a question that is useful to you, great.
>
It is never as hard as people seem to think to set something up so that 
it works correctly but I am amazed at the hacked up development process 
that get described here.

I would like to see the whole "Best Practice" described. I would like to 
see how Hudson users deal with mock data and incremental development and 
testing of on-line applications where the MC and V teams are working 
together towards a fully functional system or a working bug fix or minor 
enhancement.
How does one manage a production environment  with released systems 
functioning while new releases are being developed and patches are being 
applied to the current release?

> If, rather, you need to somehow model all kinds of combinations of
> -SNAPSHOT and non-SNAPSHOT dependencies, or you feel compelled to
> publish snapshots to your local repo, chaos is just around the corner.
>
In maintenance and bug-fixing, you do need to mix Releases with 
SNAPSHOTs to build a full system since you might only be releasing 2 
portlets out of 50 to add a new small function or fix a bug.  The 
overhead of rebuilding 70 modules to get 2 fixed is just not something 
that we can support.

We do publish SNAPSHOTS to the internal repo but they come with a 
warranty and some functional spec that the rest of the team can live with.
This does not cause a problem because we know what we are building and 
know the combination that has to be tested within the scope of each 
active project.


Ron
>
> On Mon, Nov 15, 2010 at 10:27 AM, Ron Wheeler
> <rw...@artifact-software.com>  wrote:
>> On 15/11/2010 8:18 AM, Yanko, Curtis wrote:
>>> You're happy about NOT using CI????
>>>
>> Yes. It seems to be a tool that is prone to being used foolishly.
>>
>> We are a small shop maintaining and developing a large (70+POM files) portal
>> application with portlets, web services, servlets and batch process and do
>> not seem to  have the types of issues that the people, trying to use CI,
>> bring to the table.
>>
>> They seem to get into all kinds of troubles with SNAPSHOTs, build
>> repeatability, source control and architectures that are too interdependent.
>> I can not see how they ever test anything with a continually unstable CI
>> build.
>>
>> Of course, I know that I am only seeing the worst cases in the forum so my
>> mind is not completely closed on the subject.
>> I can hardly wait until we have a "Best Practice" section on the Maven site
>> so that I can see how a CI should be integrated into a Maven environment and
>> perhaps that will make me unhappy that I an not using CI.
>>
>>
>> Ron
>>>> -----Original Message-----
>>>> From: Ron Wheeler [mailto:rwheeler@artifact-software.com]
>>>> Sent: Saturday, November 13, 2010 2:05 PM
>>>> To: users@maven.apache.org
>>>> Subject: Re: Continuous Delivery and Maven
>>>>
>>>> I would add the following bits of reality.
>>>> We don't use CI and a lot of the discussion makes me very
>>>> happy about that.
>>>>
>>> -Curt
>>>
>>> This e-mail, including attachments, may include confidential and/or
>>> proprietary information, and may be used only by the person or entity
>>> to which it is addressed. If the reader of this e-mail is not the intended
>>> recipient or his or her authorized agent, the reader is hereby notified
>>> that any dissemination, distribution or copying of this e-mail is
>>> prohibited. If you have received this e-mail in error, please notify the
>>> sender by replying to this message and delete this e-mail immediately.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[Benson Margulies <bi...@gmail.com>]

Ron,

It's not too hard to set up a CI process (e.g. on Hudson) that tests
the latest version of everything. Don't publish snapshots to your
repo, set up the cascade of jobs to share correctly.

If that answers a question that is useful to you, great.

If, rather, you need to somehow model all kinds of combinations of
-SNAPSHOT and non-SNAPSHOT dependencies, or you feel compelled to
publish snapshots to your local repo, chaos is just around the corner.



On Mon, Nov 15, 2010 at 10:27 AM, Ron Wheeler
<rw...@artifact-software.com> wrote:
> On 15/11/2010 8:18 AM, Yanko, Curtis wrote:
>>
>> You're happy about NOT using CI????
>>
> Yes. It seems to be a tool that is prone to being used foolishly.
>
> We are a small shop maintaining and developing a large (70+POM files) portal
> application with portlets, web services, servlets and batch process and do
> not seem to  have the types of issues that the people, trying to use CI,
> bring to the table.
>
> They seem to get into all kinds of troubles with SNAPSHOTs, build
> repeatability, source control and architectures that are too interdependent.
> I can not see how they ever test anything with a continually unstable CI
> build.
>
> Of course, I know that I am only seeing the worst cases in the forum so my
> mind is not completely closed on the subject.
> I can hardly wait until we have a "Best Practice" section on the Maven site
> so that I can see how a CI should be integrated into a Maven environment and
> perhaps that will make me unhappy that I an not using CI.
>
>
> Ron
>>>
>>> -----Original Message-----
>>> From: Ron Wheeler [mailto:rwheeler@artifact-software.com]
>>> Sent: Saturday, November 13, 2010 2:05 PM
>>> To: users@maven.apache.org
>>> Subject: Re: Continuous Delivery and Maven
>>>
>>> I would add the following bits of reality.
>>> We don't use CI and a lot of the discussion makes me very
>>> happy about that.
>>>
>>
>> -Curt
>>
>> This e-mail, including attachments, may include confidential and/or
>> proprietary information, and may be used only by the person or entity
>> to which it is addressed. If the reader of this e-mail is not the intended
>> recipient or his or her authorized agent, the reader is hereby notified
>> that any dissemination, distribution or copying of this e-mail is
>> prohibited. If you have received this e-mail in error, please notify the
>> sender by replying to this message and delete this e-mail immediately.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[Ron Wheeler <rw...@artifact-software.com>]

On 15/11/2010 1:22 PM, Yanko, Curtis wrote:
> I can't help but feel you are confusing the discussion on CD with CI
> which to me, is mostly a natural progression and maturity of a good
> build system.
Yes. I am not sure which one seemed to evoke the most silliness.
> The other good news is, you don't have to use it foolishly if you choose
> not too! ;-)
>

I gather that this must be true since they would have died a natural 
death in the hands of some of the people showing up here.

Ron

>> -----Original Message-----
>> From: Ron Wheeler [mailto:rwheeler@artifact-software.com]
>> Sent: Monday, November 15, 2010 10:28 AM
>> To: users@maven.apache.org
>> Subject: Re: Continuous Delivery and Maven
>>
>> On 15/11/2010 8:18 AM, Yanko, Curtis wrote:
>>> You're happy about NOT using CI????
>>>
>> Yes. It seems to be a tool that is prone to being used foolishly.
>>
>> We are a small shop maintaining and developing a large
>> (70+POM files) portal application with portlets, web
>> services, servlets and batch process and do not seem to  have
>> the types of issues that the people, trying to use CI, bring
>> to the table.
>>
>> They seem to get into all kinds of troubles with SNAPSHOTs,
>> build repeatability, source control and architectures that
>> are too interdependent.
>> I can not see how they ever test anything with a continually
>> unstable CI build.
>>
>> Of course, I know that I am only seeing the worst cases in
>> the forum so my mind is not completely closed on the subject.
>> I can hardly wait until we have a "Best Practice" section on
>> the Maven site so that I can see how a CI should be
>> integrated into a Maven environment and perhaps that will
>> make me unhappy that I an not using CI.
>>
>>
>> Ron
>>>> -----Original Message-----
>>>> From: Ron Wheeler [mailto:rwheeler@artifact-software.com]
>>>> Sent: Saturday, November 13, 2010 2:05 PM
>>>> To: users@maven.apache.org
>>>> Subject: Re: Continuous Delivery and Maven
>>>>
>>>> I would add the following bits of reality.
>>>> We don't use CI and a lot of the discussion makes me very
>> happy about
>>>> that.
>>>>
>>> -Curt
>>>
>>> This e-mail, including attachments, may include confidential and/or
>>> proprietary information, and may be used only by the person
>> or entity
>>> to which it is addressed. If the reader of this e-mail is not the
>>> intended recipient or his or her authorized agent, the reader is
>>> hereby notified that any dissemination, distribution or copying of
>>> this e-mail is prohibited. If you have received this e-mail
>> in error,
>>> please notify the sender by replying to this message and
>> delete this e-mail immediately.
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
> This e-mail, including attachments, may include confidential and/or
> proprietary information, and may be used only by the person or entity
> to which it is addressed. If the reader of this e-mail is not the intended
> recipient or his or her authorized agent, the reader is hereby notified
> that any dissemination, distribution or copying of this e-mail is
> prohibited. If you have received this e-mail in error, please notify the
> sender by replying to this message and delete this e-mail immediately.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Yanko, Curtis" <cu...@uhc.com>]

I can't help but feel you are confusing the discussion on CD with CI
which to me, is mostly a natural progression and maturity of a good
build system.

The other good news is, you don't have to use it foolishly if you choose
not too! ;-)

> -----Original Message-----
> From: Ron Wheeler [mailto:rwheeler@artifact-software.com] 
> Sent: Monday, November 15, 2010 10:28 AM
> To: users@maven.apache.org
> Subject: Re: Continuous Delivery and Maven
> 
> On 15/11/2010 8:18 AM, Yanko, Curtis wrote:
> > You're happy about NOT using CI????
> >
> Yes. It seems to be a tool that is prone to being used foolishly.
> 
> We are a small shop maintaining and developing a large 
> (70+POM files) portal application with portlets, web 
> services, servlets and batch process and do not seem to  have 
> the types of issues that the people, trying to use CI, bring 
> to the table.
> 
> They seem to get into all kinds of troubles with SNAPSHOTs, 
> build repeatability, source control and architectures that 
> are too interdependent.
> I can not see how they ever test anything with a continually 
> unstable CI build.
> 
> Of course, I know that I am only seeing the worst cases in 
> the forum so my mind is not completely closed on the subject.
> I can hardly wait until we have a "Best Practice" section on 
> the Maven site so that I can see how a CI should be 
> integrated into a Maven environment and perhaps that will 
> make me unhappy that I an not using CI.
> 
> 
> Ron
> >> -----Original Message-----
> >> From: Ron Wheeler [mailto:rwheeler@artifact-software.com]
> >> Sent: Saturday, November 13, 2010 2:05 PM
> >> To: users@maven.apache.org
> >> Subject: Re: Continuous Delivery and Maven
> >>
> >> I would add the following bits of reality.
> >> We don't use CI and a lot of the discussion makes me very 
> happy about 
> >> that.
> >>
> >
> > -Curt
> >
> > This e-mail, including attachments, may include confidential and/or 
> > proprietary information, and may be used only by the person 
> or entity 
> > to which it is addressed. If the reader of this e-mail is not the 
> > intended recipient or his or her authorized agent, the reader is 
> > hereby notified that any dissemination, distribution or copying of 
> > this e-mail is prohibited. If you have received this e-mail 
> in error, 
> > please notify the sender by replying to this message and 
> delete this e-mail immediately.
> >
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
> 

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[Ron Wheeler <rw...@artifact-software.com>]

On 15/11/2010 8:18 AM, Yanko, Curtis wrote:
> You're happy about NOT using CI????
>
Yes. It seems to be a tool that is prone to being used foolishly.

We are a small shop maintaining and developing a large (70+POM files) 
portal application with portlets, web services, servlets and batch 
process and do not seem to  have the types of issues that the people, 
trying to use CI, bring to the table.

They seem to get into all kinds of troubles with SNAPSHOTs, build 
repeatability, source control and architectures that are too interdependent.
I can not see how they ever test anything with a continually unstable CI 
build.

Of course, I know that I am only seeing the worst cases in the forum so 
my mind is not completely closed on the subject.
I can hardly wait until we have a "Best Practice" section on the Maven 
site so that I can see how a CI should be integrated into a Maven 
environment and perhaps that will make me unhappy that I an not using CI.


Ron
>> -----Original Message-----
>> From: Ron Wheeler [mailto:rwheeler@artifact-software.com]
>> Sent: Saturday, November 13, 2010 2:05 PM
>> To: users@maven.apache.org
>> Subject: Re: Continuous Delivery and Maven
>>
>> I would add the following bits of reality.
>> We don't use CI and a lot of the discussion makes me very
>> happy about that.
>>
>
> -Curt
>
> This e-mail, including attachments, may include confidential and/or
> proprietary information, and may be used only by the person or entity
> to which it is addressed. If the reader of this e-mail is not the intended
> recipient or his or her authorized agent, the reader is hereby notified
> that any dissemination, distribution or copying of this e-mail is
> prohibited. If you have received this e-mail in error, please notify the
> sender by replying to this message and delete this e-mail immediately.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Yanko, Curtis" <cu...@uhc.com>]

You're happy about NOT using CI????
 

> -----Original Message-----
> From: Ron Wheeler [mailto:rwheeler@artifact-software.com] 
> Sent: Saturday, November 13, 2010 2:05 PM
> To: users@maven.apache.org
> Subject: Re: Continuous Delivery and Maven
> 
> I would add the following bits of reality.
> We don't use CI and a lot of the discussion makes me very 
> happy about that.
> 


-Curt

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[Ron Wheeler <rw...@artifact-software.com>]

I would add the following bits of reality.
We don't use CI and a lot of the discussion makes me very happy about that.

SNAPSHOTs are important. They should be installed in the repo very 
carefully.
Each SNAPSHOT release should have a functional description (verbal or 
written) and some sort of warranty about its usability.

Lets say  you have 2 people working on getting a portlet built and one 
is building the view and the other is building the Controller and Model, 
as often is the case.
There is a spec that determines the actions that the MC guy needs to 
implement.
The V guy needs a SNAPSHOT from the MC guy that gives him mock data for 
testing. The MC guy makes a SNAPSHOT of the MC that supports the actions 
that they have agreed are needed(hopefully all of them will be mocked 
but sometimes only an initial set). This SNAPSHOT is deployed.
The V guy now has a stable test environment with a known set of 
functionality.
The MC guy continues his development and will codes additional real and 
mock functions.
 From time to time, the V and MC guy will agree to a deployment of the 
MC SNAPSHOT that changes the behaviour of the V guy's tests.
MC SNAPSHOTS that do not come with a warranty or provide unannounced 
changes in functionality will cause problems for the V guy.

The V guy may also deploy interim SNAPSHOTs to allow the portlet to be 
incorporated into the portal for testing at that level.
The portlet integration team wants to know what the portlet is supposed 
to do and not supposed to do.
Perhaps it is alright for every customer search to return "Jones 
Plumbing Supplies" regardless of search criteria entered.
It completely violates the final functional specification but for the 
moment it means that the SNAPSHOTs are all working as intended.
The portal team can carry on its work on navigation and page layouts 
with the SNAPSHOTS but they need to know what the state of the portlet 
is, since later SNAPSHOTS and the FINAL release may require a lot more 
real estate than the initial SNAPSHOT of the V.
They also need to know when a new V SNAPSHOT is released, specially if 
changes the size.


Uncontrolled deployment of SNAPSHOTS can not be a good thing in a 
project with more than 1 person.

Identifying a particular SNAPSHOT version as a dependency is often a 
good thing to allow your project to have some stability and not be 
forced to incorporate a newer SNAPSHOT dependency before your code is 
ready for it.

Maven is a great tool for supporting orderly and effective development 
if it is used properly.

Ron


On 12/11/2010 8:24 PM, Graham Leggett wrote:
> On 13 Nov 2010, at 2:37 AM, Christopher Hunt wrote:
>
>> Please correct me if I do not have this right, but in effect the 
>> requirement is to take a snapshot release, the developer do their 
>> testing and then, if satisfied, release it in effect by renaming the 
>> artifact to drop the "-SNAPSHOT"? My apologies if this is an over 
>> simplification, but if it is indeed the case then I think there is a 
>> flaw. Just because the developer has done their testing doesn't mean 
>> that everyone in the team has done their testing.
>
> One of the things that needs to be kept in mind also is that SNAPSHOT 
> means the following:
>
> "All bets are off. This was probably created from someone's 
> non-checked-in working copy. The build is definitely not repeatable, 
> don't even try think it is, as if you do you're fooling yourself".
>
> Dropping the -SNAPSHOT just means mayhem.
>
> I think the cleanest way for maven to do CD is to create a plugin that 
> slots in where you would normally use maven-release-plugin, and when 
> invoked does this:
>
> - Checks out a pristine copy of the latest trunk or branch (or 
> optionally a user specified revision).
> - Checks all files are checked in as maven-release-plugin does now, 
> fail if not.
> - Sets the version number of the pom to match the revision number in 
> scm, taking out the SNAPSHOT.
> - Runs the build.
> - Runs the tests.
> - Runs "mvn site"
> - Runs "mvn deploy" and "mvn site-deploy"
>
> Regards,
> Graham
> -- 
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[Graham Leggett <mi...@sharp.fm>]

On 13 Nov 2010, at 2:37 AM, Christopher Hunt wrote:

> Please correct me if I do not have this right, but in effect the  
> requirement is to take a snapshot release, the developer do their  
> testing and then, if satisfied, release it in effect by renaming the  
> artifact to drop the "-SNAPSHOT"? My apologies if this is an over  
> simplification, but if it is indeed the case then I think there is a  
> flaw. Just because the developer has done their testing doesn't mean  
> that everyone in the team has done their testing.

One of the things that needs to be kept in mind also is that SNAPSHOT  
means the following:

"All bets are off. This was probably created from someone's non- 
checked-in working copy. The build is definitely not repeatable, don't  
even try think it is, as if you do you're fooling yourself".

Dropping the -SNAPSHOT just means mayhem.

I think the cleanest way for maven to do CD is to create a plugin that  
slots in where you would normally use maven-release-plugin, and when  
invoked does this:

- Checks out a pristine copy of the latest trunk or branch (or  
optionally a user specified revision).
- Checks all files are checked in as maven-release-plugin does now,  
fail if not.
- Sets the version number of the pom to match the revision number in  
scm, taking out the SNAPSHOT.
- Runs the build.
- Runs the tests.
- Runs "mvn site"
- Runs "mvn deploy" and "mvn site-deploy"

Regards,
Graham
--


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[Stephen Connolly <st...@gmail.com>]

I think the reusing snapshots idea is a false version of continuous
delivery.

In CD you don't deploy _every_ commit, because that would mandate that you
only ever commit changes that don't break.

In CD you are in a position to deploy after any commit, and you do deploy
frequently.

- Stephen

---
Sent from my Android phone, so random spelling mistakes are a direct result
of using swype to type on the screen

On 13 Nov 2010 00:38, "Christopher Hunt" <hu...@internode.on.net> wrote:

Please correct me if I do not have this right, but in effect the requirement
is to take a snapshot release, the developer do their testing and then, if
satisfied, release it in effect by renaming the artifact to drop the
"-SNAPSHOT"? My apologies if this is an over simplification, but if it is
indeed the case then I think there is a flaw. Just because the developer has
done their testing doesn't mean that everyone in the team has done their
testing.

For example when I release, I login into a user blessed with the rights to
make a release. I check out the specific rev from the repo and then run the
release plugin on it. The resultant assembly is then made available to the
test teams for their functional testing. This process, while it can be quite
automated, is nonetheless triggered as a manual request from the test teams
(generally raised as a JIRA issue in my case). I've found that the testers
do not generally want a release per day. Some days they may want two
releases in a day, sometimes two per week; generally depending on where they
are in their cycle etc. The releases that they get are not snapshots.
Initially there are alpha and then beta releases.

If a beta release is approved then the specific rev (the same rev as the
last beta) will be checked out from scm and the release plugin will be run
again on it, this time producing a final version. The testers will then do
some sanity testing on this release.

Before this thread I was really happy with my release process, but now I'm
having doubts. Am I overlooking something here?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-...

Re: Continuous Delivery and Maven

[Christopher Hunt <hu...@internode.on.net>]

Please correct me if I do not have this right, but in effect the requirement is to take a snapshot release, the developer do their testing and then, if satisfied, release it in effect by renaming the artifact to drop the "-SNAPSHOT"? My apologies if this is an over simplification, but if it is indeed the case then I think there is a flaw. Just because the developer has done their testing doesn't mean that everyone in the team has done their testing.

For example when I release, I login into a user blessed with the rights to make a release. I check out the specific rev from the repo and then run the release plugin on it. The resultant assembly is then made available to the test teams for their functional testing. This process, while it can be quite automated, is nonetheless triggered as a manual request from the test teams (generally raised as a JIRA issue in my case). I've found that the testers do not generally want a release per day. Some days they may want two releases in a day, sometimes two per week; generally depending on where they are in their cycle etc. The releases that they get are not snapshots. Initially there are alpha and then beta releases.

If a beta release is approved then the specific rev (the same rev as the last beta) will be checked out from scm and the release plugin will be run again on it, this time producing a final version. The testers will then do some sanity testing on this release.

Before this thread I was really happy with my release process, but now I'm having doubts. Am I overlooking something here?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Thiessen, Todd (Todd)" <tt...@avaya.com>]

> 
> Does anyone have a reason why Maven snapshots would be useful or
> necessary
> to a project following CD?
> 

>From what I am understanding from Jez is that it is crucial that your CI built with snapshots isn't "wasted". That you can treat that build as a release without having to rebuild. That I think was the crux of our back and forth banter ;-).

I agree that if you used releases only for CD, it makes much more sense. But then how do we reconcile the flexibility one gets from working with snapshots?

I think someone else on this thread had a good idea; you'd have your CI/CD process automatically cut a release of the core project and all of its snapshot transitive dependencies. Once the released CD build is done, it would then have to revert itself back to a snapshot and all versions of all transitive dependencies that were snapshots back to snapshots.

This would definitely require some work but could be done.

I think the only loose end we have is the ability to promote a CI build (ie: something built as a snapshot) to a release build. I don't see a solution to that.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

[Kief <ma...@kief.com>]

Thiessen, Todd (Todd) wrote:
> 
> Imagine trying to have a CI build while always having enough information
> in the pom to point to an exact version of your dependencies? Lets say I
> get a feature working in my checkout, and do a build locally before
> committing.  The build would have to point to a fixed version of all my
> dependencies.  If the dependencies change while I am working, they would
> have to change "on the fly".
> 
> But of course the formal CI build would also have to ensure it points to
> the latest fixed version of all dependencies. It would have to modify the
> pom "on the fly" and it could change to point to a more recent version of
> a dependency since there is time between when I run the build in my
> checkout and the time I commit.
> 

I don't think it's necessary for the local developer builds to be pinned to
specific versions of dependencies; pinning only needs to happen on commit,
probably as part of the CI. So the CI would pull together the latest version
of each dependency at that point in time, and make sure the information is
included in the artefact. 


Thiessen, Todd (Todd) wrote:
> 
> I am against the idea of having an automated process massaging a snapshot
> and turning it into a release. You simply run the risk of building
> something that you didn't anticipate. If you want to build a release,
> build a formal release. This will include ensuring that all of your
> transtive dependencies are also a formal release. That way you control
> exactly what revision of what transitive dependencies will be built as a
> release.
> 

Reading through this thread, I see two unreconcilable processes for managing
the build -> release cycle. One involves running builds through CI with no
intention of releasing them to production. Call it "progressive delivery",
since you're progressively building your code to the point where you're
ready to release it. The other approach involves assuming that any build
that passes CI will be promoted to the next stage, and may eventually reach
production, i.e. "continuous delivery".

Although the two approaches are essentially unreconcilable for a given
project, I don't see any reason why Maven can't support both. The main
obstacle seems to be resistance to the validity of alternative processes.

I don't think continuous delivery requires massaging snapshots; personally I
think Maven's snapshot concept isn't useful for CD. Each CI build needs to
be treated as a release, and dependencies from other teams should only be
pulled from builds that have passed CI. Promotion of a build through the
pipeline shouldn't involve fiddling with the artefact, but should be managed
externally by whatever toolset you're using to manage the pipeline.

CD may or may not require modification to Maven and/or plugins to inject the
information (at CI) needed to rebuild it. It sounds to me that if the build
and its dependencies are all treated as releases rather than snapshots, the
information is probably in there.

Does anyone have a reason why Maven snapshots would be useful or necessary
to a project following CD?

Kief

> -----Original Message-----
> From: stug23 [mailto:pat.podenski@gmail.com]
> Sent: Sunday, November 07, 2010 12:17 PM
> To: users@maven.apache.org
> Subject: RE: Continuous Delivery and Maven
> 
> 
> I suspect that there is a reasonable way to adjust the builds in Maven
> such
> that they robustly support Continuous Delivery. I know that Jason van Zyl
> has started looking at CD as well.
> 
> On the Google forum
> <http://groups.google.com/group/continuousdelivery/browse_thread/thread/c
> 8440681058f2db8>
> Chris Hilton commented:
> 
> 3. In my ideal world, I would probably either extend the release
> plugin or write a new one with functionality to take a snapshot
> artifact and make it a release artifact, which would still introduce
> slight changes but pretty mild ones. I thought I had read a feature
> request or wish list about this, but can't find it now.
> 
> The current Maven release plugin, as it is, was not designed to handle
> the
> notion of CD. So it does make sense to tailor this aspect of releasing
> Maven
> artifacts to better support CD.
> 
> Also a quick examination of the Maven versions plugin shows that it has
> facilities to handle updating versions of projects and their
> dependencies.
> So it looks as if it is more a matter of adjustment of Maven build to
> produce a result that aligns with CD than a matter of Maven not being
> suitable for CD. I think that the main stumbling block is SNAPSHOTS
> because
> they inherently are not releasable -- part of the process of releasing
> with
> the current Maven release plugin is to fail when there are SNAPSHOT
> dependencies.
> 
> Another clear requirement for any changes to Maven or its build behavior
> is
> that the current behavior must be maintained for the many projects that
> haven't embraced (or won't embrace) Continuous Delivery. So I imagine a
> Maven build's behavior being altered through configuration (or a switch
> of
> some sort) to comply with the desired behavior inherent in Continuous
> Delivery with respect to the release of artifacts. The major difference
> would appear to be with the SNAPSHOT dependencies and the Maven release
> process. Other aspects of Maven are for the most part already good as
> they
> are for CD.
> 
> This is an interesting challenge that I am sure is best served by a
> thorough
> examination by the Maven and CD experts out there.
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-
> tp3245370p3254121.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org




-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3256621.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[Ron Wheeler <rw...@artifact-software.com>]

On 08/11/2010 9:06 AM, Thiessen, Todd (Todd) wrote:
> I think I see two points here.
>
> 1. Reproducing a problem on a particular revision.
> 2. Delivering a CI build to your final customer.
>
> While somewhat related, I think it is important to distinguish these two things in this dicussion.
>
> The concept of snapshots I think works extremely well.  True, you don't want to be delivering snapshots to a final customer. But this is ok because it really allows you the flexibility to always be working on the trunk. And it allows you to do so without changing your pom everytime you build.  Your developer build is the same as your CI with respect to your pom.
>
> Imagine trying to have a CI build while always having enough information in the pom to point to an exact version of your dependencies? Lets say I get a feature working in my checkout, and do a build locally before committing.  The build would have to point to a fixed version of all my dependencies.  If the dependencies change while I am working, they would have to change "on the fly".
>
> But of course the formal CI build would also have to ensure it points to the latest fixed version of all dependencies. It would have to modify the pom "on the fly" and it could change to point to a more recent version of a dependency since there is time between when I run the build in my checkout and the time I commit.
>
> It just gets very complicated very quickly. I would rather have all revision numbers in all jars.
>
> I am against the idea of having an automated process massaging a snapshot and turning it into a release. You simply run the risk of building something that you didn't anticipate. If you want to build a release, build a formal release. This will include ensuring that all of your transtive dependencies are also a formal release. That way you control exactly what revision of what transitive dependencies will be built as a release.

It also gives you a place and time to do QC and some sort of management 
sign-off.
CI is not supposed to be a technique of throwing shit together and 
releasing anything that does not set the server on fire.
There should still be a goal written down somewhere that says "We are 
working together to get release x.y.z into production(or to a customer)."
I also prepare a list of the versions of each of the artifacts that will 
make up that version. If you are reversioning all of your artifacts then 
I would recommend a list of which ones will change and which ones are 
not supposed to be changing. This is more common in a project that has 
been around for a while where large chunks of functionality will not 
change in a maintenance release or a minor enhancement release.

I would go further and pre-specify "It will use the following versions 
of these third party tools unless there is an explicit management 
agreement to the contrary."
I want an impact statement (verbal or written) about what has to be 
tested more intensively, if we change a library. There may be a good 
reason to move to the X.Y.Z version of Apache POI but I want everyone to 
be aware that this change MIGHT have an impact on functions that 
currently not under development so that they now require the same 
acceptance tests as if they were being changed since they depend on POI 
and have been tested with the old version not the new one.

Ron
> Now perhaps we could automate the process of building the formal release of the project and all of its transtive dependencies. But massaging existing snapshots into a release I don't think would be wise.
>
> Or maybe there is a completely different kind of architecture here that would allow you to do this. I just don't think that it fits into the current Maven architecture; or any other build management system for that matter.
>
>> -----Original Message-----
>> From: stug23 [mailto:pat.podenski@gmail.com]
>> Sent: Sunday, November 07, 2010 12:17 PM
>> To: users@maven.apache.org
>> Subject: RE: Continuous Delivery and Maven
>>
>>
>> I suspect that there is a reasonable way to adjust the builds in Maven
>> such
>> that they robustly support Continuous Delivery. I know that Jason van Zyl
>> has started looking at CD as well.
>>
>> On the Google forum
>> <http://groups.google.com/group/continuousdelivery/browse_thread/thread/c
>> 8440681058f2db8>
>> Chris Hilton commented:
>>
>> 3. In my ideal world, I would probably either extend the release
>> plugin or write a new one with functionality to take a snapshot
>> artifact and make it a release artifact, which would still introduce
>> slight changes but pretty mild ones. I thought I had read a feature
>> request or wish list about this, but can't find it now.
>>
>> The current Maven release plugin, as it is, was not designed to handle
>> the
>> notion of CD. So it does make sense to tailor this aspect of releasing
>> Maven
>> artifacts to better support CD.
>>
>> Also a quick examination of the Maven versions plugin shows that it has
>> facilities to handle updating versions of projects and their
>> dependencies.
>> So it looks as if it is more a matter of adjustment of Maven build to
>> produce a result that aligns with CD than a matter of Maven not being
>> suitable for CD. I think that the main stumbling block is SNAPSHOTS
>> because
>> they inherently are not releasable -- part of the process of releasing
>> with
>> the current Maven release plugin is to fail when there are SNAPSHOT
>> dependencies.
>>
>> Another clear requirement for any changes to Maven or its build behavior
>> is
>> that the current behavior must be maintained for the many projects that
>> haven't embraced (or won't embrace) Continuous Delivery. So I imagine a
>> Maven build's behavior being altered through configuration (or a switch
>> of
>> some sort) to comply with the desired behavior inherent in Continuous
>> Delivery with respect to the release of artifacts. The major difference
>> would appear to be with the SNAPSHOT dependencies and the Maven release
>> process. Other aspects of Maven are for the most part already good as
>> they
>> are for CD.
>>
>> This is an interesting challenge that I am sure is best served by a
>> thorough
>> examination by the Maven and CD experts out there.
>> --
>> View this message in context:
>> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-
>> tp3245370p3254121.html
>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Thiessen, Todd (Todd)" <tt...@avaya.com>]

I think I see two points here.

1. Reproducing a problem on a particular revision.
2. Delivering a CI build to your final customer.

While somewhat related, I think it is important to distinguish these two things in this dicussion.

The concept of snapshots I think works extremely well.  True, you don't want to be delivering snapshots to a final customer. But this is ok because it really allows you the flexibility to always be working on the trunk. And it allows you to do so without changing your pom everytime you build.  Your developer build is the same as your CI with respect to your pom.

Imagine trying to have a CI build while always having enough information in the pom to point to an exact version of your dependencies? Lets say I get a feature working in my checkout, and do a build locally before committing.  The build would have to point to a fixed version of all my dependencies.  If the dependencies change while I am working, they would have to change "on the fly".

But of course the formal CI build would also have to ensure it points to the latest fixed version of all dependencies. It would have to modify the pom "on the fly" and it could change to point to a more recent version of a dependency since there is time between when I run the build in my checkout and the time I commit.

It just gets very complicated very quickly. I would rather have all revision numbers in all jars.

I am against the idea of having an automated process massaging a snapshot and turning it into a release. You simply run the risk of building something that you didn't anticipate. If you want to build a release, build a formal release. This will include ensuring that all of your transtive dependencies are also a formal release. That way you control exactly what revision of what transitive dependencies will be built as a release.

Now perhaps we could automate the process of building the formal release of the project and all of its transtive dependencies. But massaging existing snapshots into a release I don't think would be wise.

Or maybe there is a completely different kind of architecture here that would allow you to do this. I just don't think that it fits into the current Maven architecture; or any other build management system for that matter. 

> -----Original Message-----
> From: stug23 [mailto:pat.podenski@gmail.com]
> Sent: Sunday, November 07, 2010 12:17 PM
> To: users@maven.apache.org
> Subject: RE: Continuous Delivery and Maven
> 
> 
> I suspect that there is a reasonable way to adjust the builds in Maven
> such
> that they robustly support Continuous Delivery. I know that Jason van Zyl
> has started looking at CD as well.
> 
> On the Google forum
> <http://groups.google.com/group/continuousdelivery/browse_thread/thread/c
> 8440681058f2db8>
> Chris Hilton commented:
> 
> 3. In my ideal world, I would probably either extend the release
> plugin or write a new one with functionality to take a snapshot
> artifact and make it a release artifact, which would still introduce
> slight changes but pretty mild ones. I thought I had read a feature
> request or wish list about this, but can't find it now.
> 
> The current Maven release plugin, as it is, was not designed to handle
> the
> notion of CD. So it does make sense to tailor this aspect of releasing
> Maven
> artifacts to better support CD.
> 
> Also a quick examination of the Maven versions plugin shows that it has
> facilities to handle updating versions of projects and their
> dependencies.
> So it looks as if it is more a matter of adjustment of Maven build to
> produce a result that aligns with CD than a matter of Maven not being
> suitable for CD. I think that the main stumbling block is SNAPSHOTS
> because
> they inherently are not releasable -- part of the process of releasing
> with
> the current Maven release plugin is to fail when there are SNAPSHOT
> dependencies.
> 
> Another clear requirement for any changes to Maven or its build behavior
> is
> that the current behavior must be maintained for the many projects that
> haven't embraced (or won't embrace) Continuous Delivery. So I imagine a
> Maven build's behavior being altered through configuration (or a switch
> of
> some sort) to comply with the desired behavior inherent in Continuous
> Delivery with respect to the release of artifacts. The major difference
> would appear to be with the SNAPSHOT dependencies and the Maven release
> process. Other aspects of Maven are for the most part already good as
> they
> are for CD.
> 
> This is an interesting challenge that I am sure is best served by a
> thorough
> examination by the Maven and CD experts out there.
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-
> tp3245370p3254121.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Thiessen, Todd (Todd)" <tt...@avaya.com>]

Yes. That is a good way to do. All your transitive dependencies would have to do this also to completely reproduce the entire environment. Doable, but a bit of a pain.

My whole point though is that you should very rarely have to do it.

> -----Original Message-----
> From: stug23 [mailto:pat.podenski@gmail.com]
> Sent: Sunday, November 07, 2010 12:21 PM
> To: users@maven.apache.org
> Subject: RE: Continuous Delivery and Maven
> 
> 
> I wanted to comment on something we have done for our builds with respect
> to
> SNAPSHOTS that helps with being able repeat a build for the SNAPSHOT. We
> record the Subversion revision number for each SNAPSHOT in the MANIFEST.
> 
> Also we have a so-called base-pom, which all projects inherit from, that
> locks down all of the Maven plugin versions so that the build is
> repeatable
> at a later time.
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-
> tp3245370p3254127.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

[stug23 <pa...@gmail.com>]

I wanted to comment on something we have done for our builds with respect to
SNAPSHOTS that helps with being able repeat a build for the SNAPSHOT. We
record the Subversion revision number for each SNAPSHOT in the MANIFEST.

Also we have a so-called base-pom, which all projects inherit from, that
locks down all of the Maven plugin versions so that the build is repeatable
at a later time.
-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3254127.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

[stug23 <pa...@gmail.com>]

I suspect that there is a reasonable way to adjust the builds in Maven such
that they robustly support Continuous Delivery. I know that Jason van Zyl
has started looking at CD as well.

On the Google forum
<http://groups.google.com/group/continuousdelivery/browse_thread/thread/c8440681058f2db8>
Chris Hilton commented:

3. In my ideal world, I would probably either extend the release
plugin or write a new one with functionality to take a snapshot
artifact and make it a release artifact, which would still introduce
slight changes but pretty mild ones. I thought I had read a feature
request or wish list about this, but can't find it now. 

The current Maven release plugin, as it is, was not designed to handle the
notion of CD. So it does make sense to tailor this aspect of releasing Maven
artifacts to better support CD.

Also a quick examination of the Maven versions plugin shows that it has
facilities to handle updating versions of projects and their dependencies.
So it looks as if it is more a matter of adjustment of Maven build to
produce a result that aligns with CD than a matter of Maven not being
suitable for CD. I think that the main stumbling block is SNAPSHOTS because
they inherently are not releasable -- part of the process of releasing with
the current Maven release plugin is to fail when there are SNAPSHOT
dependencies.

Another clear requirement for any changes to Maven or its build behavior is
that the current behavior must be maintained for the many projects that
haven't embraced (or won't embrace) Continuous Delivery. So I imagine a
Maven build's behavior being altered through configuration (or a switch of
some sort) to comply with the desired behavior inherent in Continuous
Delivery with respect to the release of artifacts. The major difference
would appear to be with the SNAPSHOT dependencies and the Maven release
process. Other aspects of Maven are for the most part already good as they
are for CD.

This is an interesting challenge that I am sure is best served by a thorough
examination by the Maven and CD experts out there.
-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3254121.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[jhumble <je...@jezhumble.net>]

Hi Brian

It just seems like the rev ID is really useful here for identifying
> reproducible builds without creating releases every time, does it fit with
> your ideas?  If so, a hypothetical repository manager plugin could be
> maintaining information about snapshot dependencies based on SCM rev ID,
> thus allowing for reproducibility without modifying Maven or existing
> snapshot mechanics.  Such a plugin might be able to generate a POM that has
> the extra rev ID metadata that the repo manager would recognize, allowing
> for existing SNAPSHOT-style identifiers to keep working for developer
> desktops (avoiding SCM thrash), but also providing reproducibility through
> synthetic POMs.


I think this is a great idea. If the pom for each snapshot contains enough
metadata about each of its upstream snapshots to be able to reproduce an
identical binary, we're good. Since I believe Maven already stores the md5
for each snapshot, this is verifiable.

Perhaps including in the POM for a snapshot the SCM URIs that were used to
create it and the version id (for SCMs that support atomic commits - I can't
see a happy way to do this for CVS, for example, without using tags) and the
same information nested for any of their upstream snapshots?

And then for extra points a command that could look at this pom, regenerate
the whole thing from scratch, and verify it against the md5 for the original
binary.

Jez.

-- 
Jez Humble
Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
http://continuousdelivery.com/
http://jezhumble.net/

-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3254548.html
Sent from the Maven - Users mailing list archive at Nabble.com.

Re: Continuous Delivery and Maven

[Brian Topping <to...@codehaus.org>]

On Nov 7, 2010, at 1:29 PM, jhumble wrote:

> One possibility to get repeatable builds without filling up an artifacts
> repository too fast could be to make Maven store the fully qualified pom
> files in the artifacts repo and an md5 of the binary but not necessarily the
> actual binary. I know artifacts repos already store some of this
> information.
> 
> That way you could make sure sufficient metadata is publicly available such
> that they can be reproduced, without using up loads of disk space. You could
> also happily delete older binaries, safe in the knowledge that people could
> reproduce them from the metadata in the artifacts repo.

One of the things I like about snapshots is it just simply means "latest".  Though the thing about timestamped snapshots is that they aren't guaranteed to exist (the repository is not typically assumed to be reliable), and they aren't 100% reproducible (the timestamp offset includes the time it took to build the artifact and all the artifacts before it, meaning there's no way to know exactly what point in time the build came from).  Even if one could find the correct timestamp to check out from to get the same binary, whatever subsystem creates the timestamp on upload (wagon?) probably doesn't like being told what to call the snapshot.  

It follows the only way to get a reproducible build is either to tag the original sources or to know the SCM revision id.  The revision id is a natural tag that is automatically generated, and does not clutter the named tag space with thousands of tags that have no organizational meaning.  On my CI builds, the first thing that happens is grabbing the revision ID from SVN, and that's put in a properties file that can be used when the UI is generated.  Where the version number helps users identify the general features to expect of the current software, the revision ID is great for filing issues so devs don't have to guess at what sources have the issue.  

When the sources all come from the same SCM repository tree, the rev ID makes it a cinch to reproduce the build.  Of course, a better solution can span multiple trees and is reproducible.

It just seems like the rev ID is really useful here for identifying reproducible builds without creating releases every time, does it fit with your ideas?  If so, a hypothetical repository manager plugin could be maintaining information about snapshot dependencies based on SCM rev ID, thus allowing for reproducibility without modifying Maven or existing snapshot mechanics.  Such a plugin might be able to generate a POM that has the extra rev ID metadata that the repo manager would recognize, allowing for existing SNAPSHOT-style identifiers to keep working for developer desktops (avoiding SCM thrash), but also providing reproducibility through synthetic POMs.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Continuous Delivery and Maven

[jhumble <je...@jezhumble.net>]

On 7 November 2010 10:02, Brian Topping wrote:


> Does your book discuss ways to get around these issues?


No, it's a patterns / practices book so we don't go into a lot of detail on
the tools because that information tends to go out of date fast. We discuss
Maven a bit at the end of Chapter 13 ("Managing components and
dependencies"), pp375-378

The advice we give is this: "have your CI server produce canonical versions
of each dependency, using the build label as part of the artifact’s version
number, and store these in your organization’s central artifact repoistory.
You can then use Maven’s version quantifiers in your pom file to specify a
range of acceptable versions to use. If you really need to do some
exploratory work on your local machine, you can always edit your pom
definition to temporarily enable snapshots"

This isn't really ideal, partly for the reason you specify: this leads to a
lot of thrashing with the POM file. So I'm interested to see what could be
done to make Maven work better with the CD paradigm, for instance, stug23's
idea:

we have a so-called base-pom, which all projects inherit from, that locks
> down all of the Maven plugin versions so that the build is repeatable at a
> later time.


I think you identify the problem exactly right:

If I understand the paradigm, it's not that developers would want to reject
> the latest version of any dependencies, just that the snapshot builds should
> be reproducible


In fact, I'd go further and say we want to encourage people taking the
latest version of dependencies - otherwise you're not doing continuous
integration. But of course we want all of those dependencies in the artifact
repo, not built from scratch on the developer machines, because then it
means firstly wasted time and secondly that everybody is working with
potentially different binaries.

One possibility to get repeatable builds without filling up an artifacts
repository too fast could be to make Maven store the fully qualified pom
files in the artifacts repo and an md5 of the binary but not necessarily the
actual binary. I know artifacts repos already store some of this
information.

That way you could make sure sufficient metadata is publicly available such
that they can be reproduced, without using up loads of disk space. You could
also happily delete older binaries, safe in the knowledge that people could
reproduce them from the metadata in the artifacts repo.

As you can probably tell I'm no Maven maven, but I do want to help in
whatever way I can to make it work well with a continuous delivery process.

Jez.

-- 
Jez Humble
Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
http://continuousdelivery.com/
http://jezhumble.net/

-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3254183.html
Sent from the Maven - Users mailing list archive at Nabble.com.

Re: Continuous Delivery and Maven

[Brian Topping <to...@codehaus.org>]

On Nov 7, 2010, at 11:14 AM, jhumble wrote:

> Ideally what I'd like is for Maven to explicitly support the continuous
> delivery model and provide snapshots that are reproducible.

Snapshots can be reproducible if developers set dependencies on the timestamped name of the deployed version.  I remember there being reasons that these strategies are discouraged (should be in the list archives), but those reasons may not apply here.

If I understand the paradigm, it's not that developers would want to reject the latest version of any dependencies, just that the snapshot builds should be reproducible.  Since the POM is the source of dependency resolution for any Maven build, it seems like the release plugin in use would have to update the project POMs to the currently resolved name of the actual dependency and check them in before the tag.  

But if the release checks in a POM and this is happening over and over for every checkin (a one line change in a heavily connected project could easily cause several POMs to be updated), suddenly dependent versions need to have their POMs changed, checked in, and new version propagated iteratively.  On developer desktops, all these new POMs would need to be kept up to date constantly to avoid text conflicts.  Maybe a VFS SCM could get around this, but.... ick!  The tooling is suddenly very heavyweight.

Does your book discuss ways to get around these issues?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

[Michael Hüttermann <mi...@huettermann.net>]

Hello fellows,

perhaps it is interesting for you that the book "Agile ALM" [1],
illustrates strategies and tools (especially Maven). I'm also covering
aspects that are discussed here in this thread.

[1] http://huettermann.net/alm


Cheers
Michael

--
-Java Champion-
michael@huettermann.net
http://huettermann.net
http://twitter.com/huettermann

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

[jhumble <je...@jezhumble.net>]

Hey Todd

The whole point of continuous delivery is that every check-in creates a
potential release candidate.

When you're doing continuous deployment, you could be releasing multiple
times a day, so you don't bother cutting branches or tagging or any of that
stuff because of the overhead. I'd rather not get into the justification for
this process on this thread - but I wrote a book on it if you're interested:
http://www.amazon.com/gp/product/0321601912 and many other people have
blogged about it.

You're right that creating a concrete release for each commit could
potentially use up a lot of space - but that's fine, you can just delete the
older ones. What this *does* mean in turn though is that it is essential to
be able to recreate any given build given the version in source control it
came from, and this is where Maven falls down. Snapshots just aren't
suitable because they aren't reproducible: what the snapshot looks like
depends not only on what versions of the dependencies are available at the
time the snapshot is created, but also what Maven's configuration and
plug-ins happen to be at the time you run it (assuming Maven is configured
to auto-update - the default). I can't revert back to a particular revision
in version control, run maven, and be sure that the artifact it generates is
identical to the one it created when the commit was initially triggered.

Ideally what I'd like is for Maven to explicitly support the continuous
delivery model and provide snapshots that are reproducible. Failing that, a
guide to configuring Maven so that its binaries are reproducible (for
example by switching off auto-update, and having sufficient metadata stored
in pom files and Maven's artifacts repository to know what the state of each
of the dependencies was at any given time.
-- 
View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3254090.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Continuous Delivery and Maven

["Thiessen, Todd (Todd)" <tt...@avaya.com>]

We use maven and continuous integration and it works very very well. SNAPSHOTS are a godsend when it comes to being flexible and delivering something quickly and tested quickly.

We commit many times a day and it is unphathomable to create a concrete release for each of those commits. It would waste a lot of time and resources. When working with SNAPSHOTS you don't worry about "what released version was that problem found on?"  You just simply say the error occurs on the trunk and fix it there.

The trick here is to have fast feedback. So if you introduce an error today, you should know about that error today or at the latest tomorrow.  So you don't have days or weeks go by before you get that feedback.

My general advice for devs who get into the rut like the one on the google thread is to switch to concrete releases once you start approaching your release date.  So lets say iterations 1 to 10 are on snapshots. Your product owner then feels that you have enough content to ship a release. Create a branch, cut a formal release and have your testing team test that release and iteration 11 with a release.  You may have a couple of fixes to do on that branch and you may need to cut a new release to test what you fixed.  The idea here though is that 99% of all the feature and bugs were tested and ironed out on SNAPSHOT builds. You just do your last iteration on formal releases. You wait as long as you can before before you move to concrete releases so you don't have to manage multiple branches and tags and all the complication that comes with formal releases. The version numbering would go something like this:

1.0-SNAPSHOT
1.0-SNAPSHOT
1.0-SNAPSHOT
1.0-SNAPSHOT
1.0-SNAPSHOT
...
1.0-01
1.0-02
1.0-03

You release to the field with 1.0-03.

> -----Original Message-----
> From: stug23 [mailto:pat.podenski@gmail.com]
> Sent: Monday, November 01, 2010 1:14 PM
> To: users@maven.apache.org
> Subject: Continuous Delivery and Maven
> 
> 
> I've been reading about Continuous Delivery
> <http://continuousdelivery.com/>
> and trying to understand how to best combine Maven and Continuous
> Delivery.
> There is a thread in the Continuous Delivery google group where this
> discussion has started:
> 
> <http://groups.google.com/group/continuousdelivery/browse_thread/thread/c
> 8440681058f2db8>
> 
> I would be curious as to whether there are other Maven developers
> following
> the Maven Users forum that have been looking Continuous Delivery and
> trying
> to grapple with the best way to use Maven in this approach.
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-
> tp3245370p3245370.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org