Re: Using maven with ant.

[Justin Edelson]

On Nov 8, 2010, at 10:34 PM, asdas adasads  wrote:

> I would prefer Maven rather than Ivy. If I will add Maven to the project
> maybe it will be a starting point and in future I will migrate to maven
> fully.
> 
> Then use the Maven Ant Tasks.
> 
> 
> Ok. But my initial question was: How to force maven to deploy jars created
> during ant build to the remote repository.
> Example:
> 
>I have jar a.jar, b.jar, c.jar in \build dir and I want to deploy them
> remote repository. Normally maven tries to deploy only one jar
> that he finds in \targer\artificate_name.jar. How Maven Ant Tasks is going
> to help with that ?
> 
http://maven.apache.org/ant-tasks/examples/install-deploy.html


> john
> 
> 
> On Mon, Nov 8, 2010 at 5:50 PM, Justin Edelson 
> wrote:
> 
>> 
>> 
>> On 11/8/10 8:33 PM, "asdas adasads"  wrote:
>> 
 
 Why are you even trying to use Maven if you end up using Ant for
 everything?
>>> 
>>> 
>>> To be honest only to be able to automatically push software to the remote
>>> repository.
>> 
>> Then use the Maven Ant Tasks.
>> 
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 
>> 

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

Re: Using maven with ant.

[asdas adasads]

I would prefer Maven rather than Ivy. If I will add Maven to the project
maybe it will be a starting point and in future I will migrate to maven
fully.

Then use the Maven Ant Tasks.


Ok. But my initial question was: How to force maven to deploy jars created
during ant build to the remote repository.
Example:

I have jar a.jar, b.jar, c.jar in \build dir and I want to deploy them
remote repository. Normally maven tries to deploy only one jar
that he finds in \targer\artificate_name.jar. How Maven Ant Tasks is going
to help with that ?

john


On Mon, Nov 8, 2010 at 5:50 PM, Justin Edelson wrote:

>
>
> On 11/8/10 8:33 PM, "asdas adasads"  wrote:
>
> >>
> >>Why are you even trying to use Maven if you end up using Ant for
> >>everything?
> >
> >
> >To be honest only to be able to automatically push software to the remote
> >repository.
>
> Then use the Maven Ant Tasks.
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Using maven with ant.

[Justin Edelson]

On 11/8/10 8:33 PM, "asdas adasads"  wrote:

>>
>>Why are you even trying to use Maven if you end up using Ant for
>>everything?
>
>
>To be honest only to be able to automatically push software to the remote
>repository.

Then use the Maven Ant Tasks.




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

Re: Continuous Delivery and Maven

[jhumble]

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-143...@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]]
>
> Sent: Monday, November 08, 2010 6:54 PM
> To: [hidden email] 
> 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://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: [hidden 
> email]
> For additional commands, e-mail: [hidden 
> email]
>
>
>
> --
>  View message @
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3256136.html
> To unsubscribe from Continuous Delivery and Maven, click 
> here.
>
>
>


-- 
Jez Humble
Co-author, *Continuous Delivery *
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]

> 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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: Continuous Delivery and Maven

[Yanko, Curtis]

 
--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:j...@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://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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Maven Enforcer Plugin 1.0

[Brian Fox]

The Maven team is pleased to announce the release of the Maven
Enforcer Plugin, version 1.0

Maven Enforcer Plugin - The Loving Iron Fist of Maven™ The Enforcer
plugin provides goals to control certain environmental constraints
such as Maven version, JDK version and OS family along with many more
standard rules and user created rules.

http://maven.apache.org/plugins/maven-enforcer-plugin/

You should specify the version in your project's plugin configuration:


org.apache.maven.plugins
maven-enforcer-plugin
1.0



 Release Notes - Maven 2.x Enforcer Plugin - Version 1.0
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530&version=13616

** Bug
* [MENFORCER-71] - Documentation: wrong usage of
unCheckedPluginsList option in sample
* [MENFORCER-76] - Documentation for regex on requireProperty
incorrectly includes quotes around regex
* [MENFORCER-77] - "Require Release Version" rule does not have
documented parameter "onlyWhenRelease"
* [MENFORCER-82] - Project site does not provide valid examples
* [MENFORCER-101] - Enforcer does not allow to restrict based on
SNAPSHOT version as version comparison uses artifact.getVersion()
instead of artifact.getBaseVersion()
* [MENFORCER-102] - Several minor site-bugs
* [MENFORCER-104] - Specifying a message with an alwaysFail rule
doesn't work
* [MENFORCER-105] - requirePluginVersions rule doesn't work with
POM named other than pom.xml
* [MENFORCER-108] - Documentation/Typo : 'unCheckedPluginsList' is
written instead of 'unCheckedPluginList'
* [MENFORCER-109] - Error in logged output message from
dependency-convergence rule, make the rule less usable

** Improvement
* [MENFORCER-72] - Add scope to bannedDependencies rule
* [MENFORCER-73] - Display dependency "path" when
bannedDependencies rule fails
* [MENFORCER-87] - enhance requireNoRepositories to permit
allowing any Snapshot only repos
* [MENFORCER-107] - An enforcer rule that demands developers
ensure all dependency (and transitive dependency) version numbers
converge

** New Feature
* [MENFORCER-81] - Create a banned plugins rule
* [MENFORCER-85] - Ability to exclude modules of multi-module
project from requireReleaseDeps rule


Enjoy,

-The Maven team

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

Re: Using maven with ant.

[asdas adasads]

>
> Why are you even trying to use Maven if you end up using Ant for
> everything?


To be honest only to be able to automatically push software to the remote
repository.
I'm developing a library that is used by external projects that use maven in
their build.
I wanted to avoid sending them jars (that might become obsolete over time)
and I would prefer
to be able to deploy my library to remote repository.

Try using antrun, instead of exec to call ant..


It didn't work, when using antrun maven didn't set the same classpath as I
would get when executing ant from
command line. In general from antrun I would call targets from my build.xml
so it is not a big difference whether I use
antrun or exec.

 What parts of your build make it complicated?


I use some strange classpath manipulations during testing period, also I
have a lot of properties file.
In general ant works perfectly fine for me so I don't want mess things that
works correctly. Especially that I'm not author
of the code and I'm not 100% sure about it's features.

john


On Mon, Nov 8, 2010 at 5:20 PM, Greg Akins  wrote:

> Why are you even trying to use Maven if you end up using Ant for
> everything?
>
> Try using antrun, instead of exec to call ant..
>
> When I migrated a number of projects from Ant to Maven, I began by
> pulling pieces of each project out.  My 5 Ant projects turned into
> about 10 Maven projects.
>
> What parts of your build make it complicated?
>
> On Mon, Nov 8, 2010 at 7:43 PM, asdas adasads
>  wrote:
> > I was expecting that kind of answer :)
> >
> > But, the problem is that we have too complicated build process to migrate
> it
> > to maven.
> > Supporting basic operations(clean, test,compile, package) required only
> few
> > lines in the pom file so I was
> > thinking that supporting install/deploy will be the same. Is there any
> > website (I did research before writing this post)
> > that talks about custom install process ?
> >
> > john
> >
> >
> > On Mon, Nov 8, 2010 at 4:16 PM, Ron Wheeler
> > wrote:
> >
> >> On 08/11/2010 6:58 PM, asdas adasads wrote:
> >>
> >>> Hi
> >>>
> >>> In my current project I try to use maven as wrapper to ant. On each
> >>> phase (clean, test, compile, package) I use exec-maven-plugin and
> execute
> >>> counterpart ant command i.e. ant clean or ant test etc. The problem is
> the
> >>> install phase. Ant creates three jars (in \build directory) called
> a.jar,
> >>> b.jar, c.jar. Unfortunately maven disregards them, creates an empty jar
> in
> >>> \target directory and installs it to the local repository. Is there any
> >>> way
> >>> to inform maven that it should try to install a.jar, b.jar, c.jar ?
> >>>
> >>> Best
> >>>
> >>> john
> >>>
> >>>  Get rid of Ant and get your build working with Maven.
> >>
> >> Or get rid of Maven and just use ANT.
> >>
> >> Mixing the 2 is just going to drive you crazy and generate lots of
> traffic
> >> here for no real advantage.
> >>
> >> Ron
> >>
> >>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >>
> >
>
>
>
> --
> Greg Akins
>
> http://insomnia-consulting.org
> http://www.pghcodingdojo.org
> http://pittjug.dev.java.net
> http://twitter.com/akinsgre
> http://www.linkedin.com/in/akinsgre
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Using maven with ant.

[Greg Akins]

Why are you even trying to use Maven if you end up using Ant for everything?

Try using antrun, instead of exec to call ant..

When I migrated a number of projects from Ant to Maven, I began by
pulling pieces of each project out.  My 5 Ant projects turned into
about 10 Maven projects.

What parts of your build make it complicated?

On Mon, Nov 8, 2010 at 7:43 PM, asdas adasads
 wrote:
> I was expecting that kind of answer :)
>
> But, the problem is that we have too complicated build process to migrate it
> to maven.
> Supporting basic operations(clean, test,compile, package) required only few
> lines in the pom file so I was
> thinking that supporting install/deploy will be the same. Is there any
> website (I did research before writing this post)
> that talks about custom install process ?
>
> john
>
>
> On Mon, Nov 8, 2010 at 4:16 PM, Ron Wheeler
> wrote:
>
>> On 08/11/2010 6:58 PM, asdas adasads wrote:
>>
>>> Hi
>>>
>>>     In my current project I try to use maven as wrapper to ant. On each
>>> phase (clean, test, compile, package) I use exec-maven-plugin and execute
>>> counterpart ant command i.e. ant clean or ant test etc. The problem is the
>>> install phase. Ant creates three jars (in \build directory) called a.jar,
>>> b.jar, c.jar. Unfortunately maven disregards them, creates an empty jar in
>>> \target directory and installs it to the local repository. Is there any
>>> way
>>> to inform maven that it should try to install a.jar, b.jar, c.jar ?
>>>
>>> Best
>>>
>>> john
>>>
>>>  Get rid of Ant and get your build working with Maven.
>>
>> Or get rid of Maven and just use ANT.
>>
>> Mixing the 2 is just going to drive you crazy and generate lots of traffic
>> here for no real advantage.
>>
>> Ron
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>



-- 
Greg Akins

http://insomnia-consulting.org
http://www.pghcodingdojo.org
http://pittjug.dev.java.net
http://twitter.com/akinsgre
http://www.linkedin.com/in/akinsgre

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

Re: Using maven with ant.

[asdas adasads]

I was expecting that kind of answer :)

But, the problem is that we have too complicated build process to migrate it
to maven.
Supporting basic operations(clean, test,compile, package) required only few
lines in the pom file so I was
thinking that supporting install/deploy will be the same. Is there any
website (I did research before writing this post)
that talks about custom install process ?

john


On Mon, Nov 8, 2010 at 4:16 PM, Ron Wheeler
wrote:

> On 08/11/2010 6:58 PM, asdas adasads wrote:
>
>> Hi
>>
>> In my current project I try to use maven as wrapper to ant. On each
>> phase (clean, test, compile, package) I use exec-maven-plugin and execute
>> counterpart ant command i.e. ant clean or ant test etc. The problem is the
>> install phase. Ant creates three jars (in \build directory) called a.jar,
>> b.jar, c.jar. Unfortunately maven disregards them, creates an empty jar in
>> \target directory and installs it to the local repository. Is there any
>> way
>> to inform maven that it should try to install a.jar, b.jar, c.jar ?
>>
>> Best
>>
>> john
>>
>>  Get rid of Ant and get your build working with Maven.
>
> Or get rid of Maven and just use ANT.
>
> Mixing the 2 is just going to drive you crazy and generate lots of traffic
> here for no real advantage.
>
> Ron
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Continuous Delivery and Maven

[rpomeroy]

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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Continuous Delivery and Maven

[Justin Edelson]

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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Using maven with ant.

[Ron Wheeler]

On 08/11/2010 6:58 PM, asdas adasads wrote:

Hi

 In my current project I try to use maven as wrapper to ant. On each
phase (clean, test, compile, package) I use exec-maven-plugin and execute
counterpart ant command i.e. ant clean or ant test etc. The problem is the
install phase. Ant creates three jars (in \build directory) called a.jar,
b.jar, c.jar. Unfortunately maven disregards them, creates an empty jar in
\target directory and installs it to the local repository. Is there any way
to inform maven that it should try to install a.jar, b.jar, c.jar ?

Best

john


Get rid of Ant and get your build working with Maven.

Or get rid of Maven and just use ANT.

Mixing the 2 is just going to drive you crazy and generate lots of 
traffic here for no real advantage.


Ron




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

Re: Continuous Delivery and Maven

[jhumble]

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://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.

Using maven with ant.

[asdas adasads]

Hi

In my current project I try to use maven as wrapper to ant. On each
phase (clean, test, compile, package) I use exec-maven-plugin and execute
counterpart ant command i.e. ant clean or ant test etc. The problem is the
install phase. Ant creates three jars (in \build directory) called a.jar,
b.jar, c.jar. Unfortunately maven disregards them, creates an empty jar in
\target directory and installs it to the local repository. Is there any way
to inform maven that it should try to install a.jar, b.jar, c.jar ?

Best

john

Re: Continuous Delivery and Maven

[jhumble]

>
> 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://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

[Thiessen, Todd (Todd)]

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:j...@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-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org


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

RE: Continuous Delivery and Maven

[Thiessen, Todd (Todd)]

> 
> 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  and 
> tags that are attached to each  we *also* store something
> like
> http://svn.apache.org/blah/blah
> 1423
> 
> 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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: Continuous Delivery and Maven

[Yanko, Curtis]

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:j...@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://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 

Re: Continuous Delivery and Maven

[jmorrow]

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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Continuous Delivery and Maven

[jhumble]

>
>
> 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://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

[jhumble]

>
> 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  and 
tags that are attached to each  we *also* store something like
http://svn.apache.org/blah/blah
1423

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://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

[Thiessen, Todd (Todd)]

> 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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Maven release:branch commiting things on tags

[Jon Paynter]

I ran into simmilar behavior when trying to persuade the plugin to make me a
new branch.  The plugin seems to get very confused when you change the
default values of updateWorkingCopyVersions or updateBranchVersions.

I did not get a strait answer so i found another solution here:
http://mojo.codehaus.org/versions-maven-plugin/

Definately file an issue.
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Re-Maven-release-branch-commiting-things-on-tags-tp3247052p3255932.html
Sent from the Maven - Users mailing list archive at Nabble.com.

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

Re: Maven release:branch commiting things on tags

[Zac Thompson]

Try with -DupdateWorkingCopyVersions=false ... I don't know if it will
solve your problem but it definitely seems like something you should
include

On Tue, Nov 2, 2010 at 9:59 AM, Frederic Camblor  wrote:
> Really nobody has encountered the problem ?
>
> Should I fill an issue then ?
>
> Frederic
>
> On Fri, Oct 15, 2010 at 7:08 PM, Frederic Camblor wrote:
>
>> Hi maven users !
>>
>> I learned something some days ago, about maven-release-plugin about its
>> branch goal.
>>
>> Currently, I execute following command line :
>>
>> mvn --batch-mode org.apache.maven.plugins:maven-release-plugin:2.0:branch 
>> -DautoVersionSubmodules=true -DtagBase=tags/ -Dtag=1.0.0 
>> -DupdateBranchVersions=true -DreleaseVersion=2.0.0 -DbranchBase=branches/ 
>> -DbranchName=2.0.0
>>
>> My goal, here, is to create a new branch called "2.0.0" from the 1.0.0 tag.
>>
>> It works great but I found something crappy : some commit were made on the
>> 1.0.0 tag hierarchy.
>> That is to say, the plugin is acting this way :
>> - Checkout tag ${tagBase}${tag} in working directory
>> - Modify pom to ${releaseVersion}-SNAPSHOT & scm
>> - Commit pom (on tag 1.0.0 !!!)
>> - If something is going bad during the next two lines, your tag
>> hierarchy will be altered
>> - SVN Copy ${tagBase}${tag}/ hierarchy to ${branchBase}${branchName}/
>> hierarchy
>> - Re-Modify pom in working directory to ${tag}
>> - Re-Commit pom on tag 1.0.0
>>
>> I would think it would act this way :
>> - SVN Copy ${tagBase}${tag}/ hierarchy to ${branchBase}${branchName}/
>> hierarchy
>> - Checkout ${branchBase}${branchName}/ in working directory
>> - Modify pom to ${releaseVersion}-SNAPSHOT
>> - Commit pom (on branch !) & scm
>>
>> Would it be some reason why the first strategy is applied ?
>> Am I badly using release:branch goal ?
>>
>> Thanks in advance for your precisions.
>> Frédéric
>>
>

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

RE: Continuous Delivery and Maven

[Thiessen, Todd (Todd)]

> 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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Continuous Delivery and Maven

[jhumble]

>
> 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://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.

AW: How to set some variables in archetypes?

[Sonja Stocker]

Step by step I could resolve some of my problems - thanks for your answers.
My mistake in using the property file was that I used the 
archetype.properties-property in the goal generate instead of the goal 
create-from-archetype. After changing this it works fine.

It remains the message: Parent element not overwritten in ...
Can I change any setting so that the parent element will be overwritten?

  

-Ursprüngliche Nachricht-
Von: Sonja Stocker [mailto:sonja.stoc...@gmx.de] 
Gesendet: Freitag, 5. November 2010 18:39
An: 'Maven Users List'
Betreff: AW: How to set some variables in archetypes?

I think my problem is that I have one hierarchy more than a multi module 
project usually has. The artifactId in the upper level (customer) will be 
replaced with the id I enter during the generation. But I also would like to 
replace the name of the artifactId in the second level - PROJECT. 

In the first step I use the artifactId Template for the top level and PROJECT 
for the second level. Then I use the goal create-from-project and get my 
archetype. Here I execute the changes: I replace PROJECT with ${project} in the 
both POMs. After installing and generating the project with the property 
archetype.properties I get the new project. The string ${project} hasnt been 
replaced.

Can the problem stick together with to the message which I get during the 
generating:
Parent element not overwritten in C:\tmp\archetype\CUSTOMER\PROJECT\pom.xml 
Is there a possibility to force the replacing? The attribute filtered="true" in 
the archetype descriptor is set.


-Ursprngliche Nachricht-
Von: lukewpatterson [mailto:lukewpatter...@gmail.com] 
Gesendet: Freitag, 5. November 2010 16:20
An: users@maven.apache.org
Betreff: Re: How to set some variables in archetypes?



Sonja Stocker wrote:
> 
> Ive tried it with 
> 
> ${project}
> 
> in the upper POM and using archetype.properties where this property was
> declared: project=PROJECTNAME. But it didnt work. 
> 

Just to clarify, are you saying that "${project}" wasn't replaced with the
value of the archetype-gathered property?  Or are you fighting a problem
with folder names matching up with module names?
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/How-to-set-some-variables-in-archetypes-tp3251703p3251980.html
Sent from the Maven - Users mailing list archive at Nabble.com.

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


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


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

Re: Continuous Delivery and Maven

[Brian Topping]

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 tea

Re: Continuous Delivery and Maven

[jhumble]

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://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]

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://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: Continuous Delivery and Maven

[Yanko, Curtis]

 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:topp...@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 
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  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

Re: RE: Continuous Delivery and Maven

[Stephen Connolly]

Then I'm not sure you get it

On 8 Nov 2010 17:21, "Thiessen, Todd (Todd)"  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

[Brian Topping]

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  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  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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: Continuous Delivery and Maven

[Thiessen, Todd (Todd)]

> 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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: Continuous Delivery and Maven

[Yanko, 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).

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:j...@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-143...@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]]
>
> Sent: Monday, November 08, 2010 12:11 PM
> To: [hidden email] 
> 
> Subject: Re: Continuous Delivery and Maven
>
>
> Hi Curt - it was this one:
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32453
> 70 45370?by-user=t>
> p3254439.html
>
> On 8 November 2010 09:07, Yanko, Curtis [via Maven] < [hidden email] 
>  82-1751046
>
> [hidden email] >
> > wrote:
>
> >
> > I didn't see a reply from a Brian. What answer did he provided that 
> > answered 

Re: Problems using maven-dependencies-plugin

[Jon Paynter]

On Sun, Nov 7, 2010 at 10:09 AM, Wayne Fay  wrote:

> > I really need to have maven copy a set of "external" scoped dependencies,
> > and I´d hate to have to make a "company branch" of a maven plugin
>
> Perhaps the Flexmojos project would be willing to take ownership of
> the altered Maven plugin... since they are "causing" the problem in
> the first place.
>

As an interm solution - try using the 'system' scope.  I found it worked
quite well to have the dependency plugin copy files from some other location
when doing final assembly.

Re: Continuous Delivery and Maven

[jhumble]

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-143...@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]]
>
> Sent: Monday, November 08, 2010 12:11 PM
> To: [hidden email] 
> 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] <
> [hidden email] 
> 
> [hidden email] >
> > 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]]
> >
> > Sent: Monday, November 08, 2010 11:58 AM
> > To: [hidden email]
> > 
> > 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.
> >

RE: Continuous Delivery and Maven

[Yanko, Curtis]

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:j...@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-143...@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]]
>
> Sent: Monday, November 08, 2010 11:58 AM
> To: [hidden email] 
> 
> 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 th

RE: Continuous Delivery and Maven

[Thiessen, Todd (Todd)]

 
> 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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Continuous Delivery and Maven

[jhumble]

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-143...@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]]
>
> Sent: Monday, November 08, 2010 11:58 AM
> To: [hidden email] 
> 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] 
> 
> [hidden email] >
> > 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]
> > For additional commands, e-mail: [hidden
> email]
> >
> >
> >
> > --
> >  View message @
> >
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370
> p3255336.html
> > To unsubscribe from Continuous Delivery and Maven, click
> here

RE: Continuous Delivery and Maven

[Yanko, Curtis]

 
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:j...@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-143...@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]
> For additional commands, e-mail: [hidden
email]
>
>
>
> --
>  View message @
>
http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370
p3255336.html
> To unsubscribe from Continuous Delivery and Maven, click
here.
>
>
>


-- 
Jez Humble
Co-author, *Continuous Delivery *
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 au

Re: Continuous Delivery and Maven

[jhumble]

>
>  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-143...@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]
> For additional commands, e-mail: [hidden 
> email]
>
>
>
> --
>  View message @
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3255344.html
> To unsubscribe from Continuous Delivery and Maven, click 
> here.
>
>
>


-- 
Jez Humble
Co-author, *Continuous Delivery *
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]

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:tthies...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: Continuous Delivery and Maven

[Yanko, Curtis]

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:tthies...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Continuous Delivery and Maven

[jhumble]

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-143...@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]
> For additional commands, e-mail: [hidden 
> email]
>
>
>
> --
>  View message @
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3255336.html
> To unsubscribe from Continuous Delivery and Maven, click 
> here.
>
>
>


-- 
Jez Humble
Co-author, *Continuous Delivery *
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)]

 
> 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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: Continuous Delivery and Maven

[Thiessen, Todd (Todd)]

> 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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: Continuous Delivery and Maven

[Yanko, Curtis]

 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.conno...@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  
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)  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.conno...@gmail.com]
>>> Sent: Monday, November 08, 2010 9:17 AM
>>> To: Maven Users List
>>> Subject: Re: Continuous 

Re: Continuous Delivery and Maven

[Ron Wheeler]

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.poden...@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

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 M

Re: Maven Plug-in How do I get the webapp directory

[Wayne Fay]

> So your code would be like:
> /*...@parameter default-value="${warSourceDirectory}" */
> private File warSourceDir;

Hmm actually that's not entirely correct... you may want to just
inject ${project} and dig through it to find the configuration you are
trying to access.

If you fired this up in an IDE and ran your plugin, you could inspect
the MavenProject and find the proper object path to the directory
you're looking for.

Wayne

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

Re: Maven Plug-in How do I get the webapp directory

[Wayne Fay]

> I'm creating my own mojos and I need to get the webapp directory. What
> expression can I apply to a path to get the directory?. Can I have a List of

Refer to the documentation:
http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html

Which tells us you are looking for the following:
warSourceDirectory of type File

So your code would be like:
/*...@parameter default-value="${warSourceDirectory}" */
private File warSourceDir;

Wayne

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

Re: Change artifactId by Profile

[Ron Wheeler]

This has been covered before (many times).
A common problem.

Make a POM for each client that ONLY contains resources that are branded 
or configured for a specific client.
Make each one depend on the common, shared core and then you can easily 
build and deploy each client's artifact's properly.


Ron


On 08/11/2010 9:03 AM, Darren Hartford wrote:

Hey all,
I have a number of builds that, depending on the profile selected, should 
deploy a different artifact.  Usually this is related to branding using the 
profiles to change the /src/main/resources to instead use branded versions.

Problem is, my current approach definitely has some issues with various tooling 
and plugins:

pom.xml:${myCustomArtifactId}

profile1:
app-profile1


profile2:
app-profile2


Is there a cleaner way to change the 'artifactId' based on the selected profile 
instead of this property approach, while still keeping support for things like 
-source/-javadoc deploys as well (each branded).

thanks!

-D





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





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

Re: Continuous Delivery and Maven

[Stephen Connolly]

On 8 November 2010 15:41, Thiessen, Todd (Todd)  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.conno...@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

RE: Continuous Delivery and Maven

[Thiessen, Todd (Todd)]

> 
> 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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: Continuous Delivery and Maven

[Thiessen, Todd (Todd)]

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.conno...@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) 
> 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.conno...@gmail.com]
> >> Sent: Monday, November 08, 2010 9:17 AM
> >> To: Mave

Order of properties resolution within POM and inheritance

[Vincent Latombe]

Hi everyone,

I just got surprised by the way Maven resolves properties between parent,
profiles and current pom.

I made an example project to illustrate that (one parent pom, one child) :
https://gist.github.com/667731
With this example project, from the child project, I get the following :

mvn validate => myproperty = child
mvn validate -Pmyprofile => myproperty = child

I would rather expect using the second command to get myproperty =
myprofile. But anyway, if this is how it works...

Vincent

Re: Continuous Delivery and Maven

[Stephen Connolly]

On 8 November 2010 14:50, Stephen Connolly
 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)  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.conno...@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) 
>>> 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-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>

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

RE: Continuous Delivery and Maven

[Yanko, Curtis]

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.conno...@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) 
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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Continuous Delivery and Maven

[Stephen Connolly]

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)  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.conno...@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) 
>> 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-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

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

RE: Continuous Delivery and Maven

[Yanko, Curtis]

 
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.conno...@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) 
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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Change artifactId by Profile

[Vincent Latombe]

I don't know about your context, but you should make different artifacts
instead.

Vincent


2010/11/8 Darren Hartford 

> Hey all,
> I have a number of builds that, depending on the profile selected, should
> deploy a different artifact.  Usually this is related to branding using the
> profiles to change the /src/main/resources to instead use branded versions.
>
> Problem is, my current approach definitely has some issues with various
> tooling and plugins:
>
> pom.xml: ${myCustomArtifactId}
>
> profile1:
>
> app-profile1
>
>
> profile2:
>
> app-profile2
>
>
> Is there a cleaner way to change the 'artifactId' based on the selected
> profile instead of this property approach, while still keeping support for
> things like -source/-javadoc deploys as well (each branded).
>
> thanks!
>
> -D
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

RE: Continuous Delivery and Maven

[Yanko, Curtis]

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:j...@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-143...@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]]
>
> Sent: Sunday, November 07, 201

RE: Continuous Delivery and Maven

[Thiessen, Todd (Todd)]

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.conno...@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) 
> 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-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org


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

Re: Continuous Delivery and Maven

[Stephen Connolly]

On 8 November 2010 13:30, Thiessen, Todd (Todd)  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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: run a bash script after creating war file

[Justin Edelson]

On 11/7/10 2:52 PM, "paladine"  wrote:

>Basically, i want to send my war file to a remote server that doesn't
>contain a maven repo so i think deploy phase is not good method to do this
>job because deploy phase requires a maven repo.

You're conflating the deploy *phase* with the deploy *plugin*. The deploy
phase is the correct place to bind a plugin goal which sends something to
a remote server. As with any phase in Maven, you can bind additional
plugin goals beyond the default deploy:deploy goal.

Justin



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

RE: Continuous Delivery and Maven

[Thiessen, Todd (Todd)]

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.poden...@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
>  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-unsubscr...@maven.apache.or

Change artifactId by Profile

[Darren Hartford]

Hey all,
I have a number of builds that, depending on the profile selected, should 
deploy a different artifact.  Usually this is related to branding using the 
profiles to change the /src/main/resources to instead use branded versions.

Problem is, my current approach definitely has some issues with various tooling 
and plugins:

pom.xml: ${myCustomArtifactId}

profile1:
app-profile1


profile2:
app-profile2


Is there a cleaner way to change the 'artifactId' based on the selected profile 
instead of this property approach, while still keeping support for things like 
-source/-javadoc deploys as well (each branded).

thanks!

-D



  

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

RE: Continuous Delivery and Maven

[Thiessen, Todd (Todd)]

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.poden...@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-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org


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

Reporting plugins: How to report a plugin's configuration?

[Andreas Sewe]

Hi all,

I have written a Maven plugin (custom packaging) which so far works 
fine. :-) Now I want to accompany it with a reporting mojo, which 
presents the plugin's configuration as a project report.


This, alas, proves to be quite difficult; not only is the ${project} 
MavenProject quite unwieldy, but I also need to access the *effective* 
configuration of the plugin, i.e., I need to take executions and active 
profiles into account.


Can someone provide me with some pointers to plugins doing similar 
things? (I already had a look at the m-plugin-p and the 
m-project-info-reports-p, but that didn't help much.)


Best wishes,

Andreas

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

RE: Continuous Delivery and Maven

[Thiessen, Todd (Todd)]

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:j...@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-143...@n5.nabble.com 1036569885-143...@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]]
> >
> > Sent: Sunday, November 07, 2010 11:15 AM
> > To: [hidden email]
> 
> > 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 i

Re: Maven achetype name

[Benjamin Dreux]

I tryied to generate my archetype in the interactive maner. But the property
that are asked, are the same that on the property file.
This wasn't helping, thanks for your try.

2010/11/8 Asmann, Roland 

> When the plugin asks you if the configuration is correct, answer 'N' and
> fill out all values it then requests.
>
> If it doesn't ask this, start it with added parameter '-Dinteractive=true'
>
>
> On 08.11.2010 13:28, Benjamin Dreux wrote:
> > Hi
> > I would like to create an archetype with a property file.
> > I founded this
> > tutorial<
> http://www.bluesunrise.com:8080/webcontent/rproxy/maven_apache/archetype/maven-archetype-plugin/examples/create-with-property-file.html
> >.
> > I manage to create my archetype.
> > But now i would like to know, what can i do to change the resulting
> achetype
> > name.
> > Apparently, the name is defined via the archetype.artifactId, but what if
> i
> > want to have an archetype name and a artifact id that are different.
> >
> > Thanks for your help
> >
>
> --
> Roland Asmann
> Senior Software Engineer
>
> adesso Austria GmbH
> Floridotower 26. Stock  T +43 1 2198790-27
> Floridsdorfer Hauptstr. 1   F +43 1 2198790-927
> A-1210 Wien M +43 664 88657566
>E roland.asm...@adesso.at
>W www.adesso.at
>
> -
> >>> business. people. technology. <<<
> -
>

Re: Maven achetype name

[Asmann, Roland]

When the plugin asks you if the configuration is correct, answer 'N' and 
fill out all values it then requests.

If it doesn't ask this, start it with added parameter '-Dinteractive=true'


On 08.11.2010 13:28, Benjamin Dreux wrote:
> Hi
> I would like to create an archetype with a property file.
> I founded this
> tutorial.
> I manage to create my archetype.
> But now i would like to know, what can i do to change the resulting achetype
> name.
> Apparently, the name is defined via the archetype.artifactId, but what if i
> want to have an archetype name and a artifact id that are different.
>
> Thanks for your help
>

-- 
Roland Asmann
Senior Software Engineer

adesso Austria GmbH
Floridotower 26. Stock  T +43 1 2198790-27
Floridsdorfer Hauptstr. 1   F +43 1 2198790-927
A-1210 Wien M +43 664 88657566
E roland.asm...@adesso.at
W www.adesso.at

-
 >>> business. people. technology. <<<
-

Maven achetype name

[Benjamin Dreux]

Hi
I would like to create an archetype with a property file.
I founded this 
tutorial.
I manage to create my archetype.
But now i would like to know, what can i do to change the resulting achetype
name.
Apparently, the name is defined via the archetype.artifactId, but what if i
want to have an archetype name and a artifact id that are different.

Thanks for your help

Re: Maven in 5 minutes doesn't work

[beta]

Hi Waseem,

Did you get to solve your issue? I'm getting the same errors and I haven't 
found 
a way to solve them,

Thanks in advance,




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

Re: run a bash script after creating war file

[Ryan Connolly]

Try binding to the 'package' phase.
On Nov 8, 2010 4:26 AM, "paladine"  wrote:
>
> Hi everyone.
>
> my purpose is to run a bash script after creating war file.
> i tried using maven-ant plugin. if you run ant script at
'generate-sources'
> phase, it runs but this doesn't live up to my expectations because at that
> phase war file hadn't been created yet. When i specified 'deploy' for this
> script, it doesn't run.
>
> Basically, i want to send my war file to a remote server that doesn't
> contain a maven repo so i think deploy phase is not good method to do this
> job because deploy phase requires a maven repo.
>
> Briefly, # mvn package
> # scp target/.war r...@serverip:
>
> i want to do this in pom.xml
>
> thanks in advance
> --
> View this message in context:
http://maven.40175.n5.nabble.com/run-a-bash-script-after-creating-war-file-tp3254237p3254237.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

Re: adding java sources to classpath with maven-eclipse-plugin

[Martijn Dashorst]

add an include pattern. Default maven filters out java files.

Martijn

On Sun, Nov 7, 2010 at 11:26 AM, James Ring  wrote:
> (Please CC me on replies, I am not subscribed to this list)
>
> Hi there,
>
> I have a GWT project which programatically starts a DevMode shell. The
> problem I have is that GWT needs access to the Java source code in the
> classpath at runtime. I have tried adding my src/main/java directory
> to the resources list (in the following snippet), but this doesn't
> seem to have the desired effect.
>
> 
>  
>    
>      src/main/java
>    
>  
>  ...
> 
>
> Basically the following code should not throw an exception when run as
> an Eclipse JUnit test.
>
> classLoader.getResource("com/mycompany/mypackage/client/MainPage.java")
>
> The test passes when running mvn test, but when running it inside an
> Eclipse project generated with "mvn eclipse:eclipse", it fails
> (resource not found). As a workaround I just add the src/main/java
> directory to the runtime classpath and then GWT is happy and I'm
> happy. :)
>
> $ mvn -version
> Apache Maven 2.2.1 (r801777; 2009-08-07 05:16:01+1000)
> Java version: 1.6.0_22
> Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac"
>
> Using org.apache.maven.plugins:maven-eclipse-plugin:2.7.
>
> Thanks for your help!
>
> Regards,
> James
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

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

Re: adding java sources to classpath with maven-eclipse-plugin

[Jörg Schaible]

James Ring wrote:

> (Please CC me on replies, I am not subscribed to this list)
> 
> Hi there,
> 
> I have a GWT project which programatically starts a DevMode shell. The
> problem I have is that GWT needs access to the Java source code in the
> classpath at runtime. I have tried adding my src/main/java directory
> to the resources list (in the following snippet), but this doesn't
> seem to have the desired effect.

Why not use the sources plugin to generate an attached -sources jar with the 
sources? You can thewn add this artifact as additional dependency in places 
where you need it.

- Jörg



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

adding java sources to classpath with maven-eclipse-plugin

[James Ring]

(Please CC me on replies, I am not subscribed to this list)

Hi there,

I have a GWT project which programatically starts a DevMode shell. The
problem I have is that GWT needs access to the Java source code in the
classpath at runtime. I have tried adding my src/main/java directory
to the resources list (in the following snippet), but this doesn't
seem to have the desired effect.


  

  src/main/java

  
  ...


Basically the following code should not throw an exception when run as
an Eclipse JUnit test.

classLoader.getResource("com/mycompany/mypackage/client/MainPage.java")

The test passes when running mvn test, but when running it inside an
Eclipse project generated with "mvn eclipse:eclipse", it fails
(resource not found). As a workaround I just add the src/main/java
directory to the runtime classpath and then GWT is happy and I'm
happy. :)

$ mvn -version
Apache Maven 2.2.1 (r801777; 2009-08-07 05:16:01+1000)
Java version: 1.6.0_22
Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac"

Using org.apache.maven.plugins:maven-eclipse-plugin:2.7.

Thanks for your help!

Regards,
James

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

RE: Continuous Delivery and Maven

[stug23]

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

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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: Continuous Delivery and Maven

[stug23]

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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

run a bash script after creating war file

[paladine]

Hi everyone.

my purpose is to run a bash script after creating war file. 
i tried using maven-ant plugin. if you run ant script at 'generate-sources'
phase, it runs but this doesn't live up to my expectations because at that
phase war file hadn't been created yet. When i specified 'deploy' for this
script, it doesn't run.

Basically, i want to send my war file to a remote server that doesn't
contain a maven repo so i think deploy phase is not good method to do this
job because deploy phase requires a maven repo.

Briefly, # mvn package 
   # scp target/.war r...@serverip:

i want to do this in pom.xml

thanks in advance
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/run-a-bash-script-after-creating-war-file-tp3254237p3254237.html
Sent from the Maven - Users mailing list archive at Nabble.com.

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

Maven Plug-in How do I get the webapp directory

[Néstor Boscán]

Hi

I'm creating my own mojos and I need to get the webapp directory. What
expression can I apply to a path to get the directory?. Can I have a List of
files and create an expression that will fill it with the source path,
resource path and webapp path?

Regards,

Néstor Boscán