You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Steve Cohen <sc...@javactivity.org> on 2011/01/06 14:36:46 UTC
maven deploy module conditionally
Another dumb newbie question about using maven with a nexus repository.
I have painstakingly developed a build process for a suite of
applications sharing common modules that was based on using local
repositories only. In that setup I blissfully paid zero attention to
version numbers, calling every module SNAPSHOT-0.0.1 and handling all
deployment decisions manually.
The build process is based on calling "mvn install" on "aggregator"
projects against pristine source from version control. This builds each
dependent module in turn and then the final product.
Now I finally have the opportunity to use a real repository and this is
set up with snapshot and release sub-repos, with the release not
allowing reuse of version numbers.
I am fine with this, and it's long overdue. Some of my modules are
ultra-stable and need to be deployed as releases. Others are in
development yet and are quite properly snapshots.
But I would rather not, if possible, redesign my entire build process.
I'd like to be able to modify it to call "mvn deploy" instead of "mvn
install". Of course this won't work with the nexus repository. So my
question is, is there a way to tell maven, when building an assembly of
modules,
a) to only build release modules if their POM version number is not
already in the repository,
or
b) alternatively, to simply not try to deploy release modules that
already are in the repository
or
c) not to fail the whole build when an attempted deployment of a module
fails for this reason?
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven deploy module conditionally
Posted by Steve Cohen <sc...@javactivity.org>.
On 01/06/2011 08:18 AM, Steve Cohen wrote:
> On 01/06/2011 08:05 AM, Wendy Smoak wrote:
,,,
>
>
>> If one of the modules is stable, do a release of it and have the other
>> modules depend on that released version (but you can still build the
>> next snapshot in your aggregator build.)
>>
>
> Is what you are saying, then, that I need to "comment out" the stable
> modules as modules in the aggregator project? That would pull them from
> the repo (they are then just dependencies, like third party jars)? It
> would be nice not to have to mess with the POMs in this way. That's what
> I'm looking for.
>
I don't suppose that's what you were saying - because I tried it and it
doesn't work. Simply commenting them out as modules causes them and
their dependencies to be left out of the final package.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven deploy module conditionally
Posted by Steve Cohen <sc...@javactivity.org>.
On 01/06/2011 09:33 AM, Yanko, Curtis wrote:
> A not working build doesn't sound simpler to me.
>
> We only use aggregation builds for local builds but our CI just builds
> the changed module and then triggers dependent modules up the
> architectural chain.
>
> ________________________________
>
> Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
> Making IT Happen, one build at a time, 600 times a day
>
>
>
> This e-mail, including attachments, may include confidential and/or
> proprietary information, and may be used only by the person or entity
> to which it is addressed. If the reader of this e-mail is not the intended
> recipient or his or her authorized agent, the reader is hereby notified
> that any dissemination, distribution or copying of this e-mail is
> prohibited. If you have received this e-mail in error, please notify the
> sender by replying to this message and delete this e-mail immediately.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
Who says it's non-working? I want to preserve something that's working
for me, while still advancing along the chain to better practices.
We don't use CI. I am trying to advance one step at a time from manual
processes, to repositories, then maybe to CI at some point?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: maven deploy module conditionally
Posted by "Yanko, Curtis" <cu...@uhc.com>.
A not working build doesn't sound simpler to me.
We only use aggregation builds for local builds but our CI just builds
the changed module and then triggers dependent modules up the
architectural chain.
________________________________
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time, 600 times a day
This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven deploy module conditionally
Posted by Steve Cohen <sc...@javactivity.org>.
On 01/06/2011 08:24 AM, Yanko, Curtis wrote:
>
>>
>> Yes, I suppose I could do that (which is pretty much what I
>> did before), but it sort of defeats the whole purpose of what
>> I'm trying to accomplish here, which is, be a little more
>> organized about what is release and what is in development.
>
>
> Then break up your builds so each one build individually and is
> triggered by it's own change.
>
> As it is you want to build stuff that you don't need or even want to use
> or doesn't even need building.
>
Yes, but this is exactly what I'm trying to avoid. In other words, I am
willing to accept a suboptimum build process for one that is simpler,
i.e. same script every time - Just do what needs to be done.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: maven deploy module conditionally
Posted by "Yanko, Curtis" <cu...@uhc.com>.
>
> Yes, I suppose I could do that (which is pretty much what I
> did before), but it sort of defeats the whole purpose of what
> I'm trying to accomplish here, which is, be a little more
> organized about what is release and what is in development.
Then break up your builds so each one build individually and is
triggered by it's own change.
As it is you want to build stuff that you don't need or even want to use
or doesn't even need building.
This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven deploy module conditionally
Posted by Steve Cohen <sc...@javactivity.org>.
On 01/06/2011 12:32 PM, Steve Cohen wrote:
>
> Of course, this requires that the commented-out modules stay as comments
> and not be inadvertently deleted. A better solution might be some sort
> of way of indicating this in the modules tag.
>
> Something like:
> <modules>
> <module>Module1</module>
> <stableModule>
> <groupID>com.whatever</groupID>
> <!-- default to groupID of this POM? -->
> <artifactId>Project2</artifactId>
> <version>2.0.5</version>
> <type>jar</type>
> </stableModule>
> <module>Module3</module>
> <modules>
>
> with the idea being that "stableModules" should be gotten from the
> repository rather than be built. This would enable the user to treat
> stable modules more like third party jars. When Project2 gets further
> development (and a SNAPSHOT version), this should be reflected by being
> made a module again.
>
> Anyway, such a feature would be of use to me. It reflects the social
> fact that reusable modular code that is used by more than one
> application may evolve within an organization over time.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
Actually, that dependency-like syntax is totally unnecessary and confusing.
More like my commenting out approach would be simply:
<modules>
<module>Module1</module>
<stableModule>Module2></stableModule>
<module>Module3</module>
<modules>
where <stableModule> is treated as a no-op, something that is expected
to be picked up as a dependency, and is just there as a place-holder for
some future release where it would become an unstable SNAPSHOT and
revert to a plain <module> when that happens.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven deploy module conditionally
Posted by Steve Cohen <sc...@javactivity.org>.
On 01/06/2011 08:31 AM, Wendy Smoak wrote:
> On Thu, Jan 6, 2011 at 9:18 AM, Steve Cohen<sc...@javactivity.org> wrote:
>>> Set all your versions to end in -SNAPSHOT, that way you can leave them
>>> in the aggregated build without the repository manager complaining on
>>> deploy.
>>>
>>
>> Yes, I suppose I could do that (which is pretty much what I did before), but
>> it sort of defeats the whole purpose of what I'm trying to accomplish here,
>> which is, be a little more organized about what is release and what is in
>> development.
>>
>>> If one of the modules is stable, do a release of it and have the other
>>> modules depend on that released version (but you can still build the
>>> next snapshot in your aggregator build.)
>>
>> Is what you are saying, then, that I need to "comment out" the stable
>> modules as modules in the aggregator project? That would pull them from the
>> repo (they are then just dependencies, like third party jars)? It would be
>> nice not to have to mess with the POMs in this way. That's what I'm looking
>> for.
>
> No commenting out. I was trying to make the fewest changes to your
> current setup as possible, since you said you didn't want to redesign
> the build.
>
> Following the Maven conventions, you never have a non-SNAPSHOT version
> number checked in on a trunk or branch -- only on a tag. (Or briefly
> while a release is happening.)
>
> It sounds like right now you are building an artifact with a
> non-snapshot version number over and over. That goes against the idea
> that 'releases never change' -- releases should be built once, put in
> the repository, and pulled from there when needed.
>
> The version numbers make it clear what's under development and what's
> not. If module A depends on B-1.1-SNAPSHOT (being built in the
> aggregated build,) then B is under development. If A depends on
> B-1.0, then you are using a stable version of B.
>
> Maven does not currently have the concept of 'skip deployment if my
> version number does not end in -SNAPSHOT'. You'd probably have to put
> the deploy plugin configured to with 'skip=true' in a profile, and
> patch the profile activation code to understand that concept.
>
Actually, on further review, "the commenting-out" approach does work. I
don't know what I did wrong the first time.
And actually, it appears to be the most elegant solution available to me
given my preferences. Commented-out modules represent modules for which
a stable released component version should be used rather than built.
Of course, this requires that the commented-out modules stay as comments
and not be inadvertently deleted. A better solution might be some sort
of way of indicating this in the modules tag.
Something like:
<modules>
<module>Module1</module>
<stableModule>
<groupID>com.whatever</groupID>
<!-- default to groupID of this POM? -->
<artifactId>Project2</artifactId>
<version>2.0.5</version>
<type>jar</type>
</stableModule>
<module>Module3</module>
<modules>
with the idea being that "stableModules" should be gotten from the
repository rather than be built. This would enable the user to treat
stable modules more like third party jars. When Project2 gets further
development (and a SNAPSHOT version), this should be reflected by being
made a module again.
Anyway, such a feature would be of use to me. It reflects the social
fact that reusable modular code that is used by more than one
application may evolve within an organization over time.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven deploy module conditionally
Posted by Steve Cohen <sc...@javactivity.org>.
On 01/06/2011 10:29 AM, Ron Wheeler wrote:
> We build a very large project in a very simple way.
> The handling of software sources is handled separately from Maven.
>
> SOURCE POLICY
> All software changes are recorded in the Subversion repository in the
> trunk or branch or tag regardless of the build status.
> Anyone should be able find the sources for any piece of software that a
> programmer has decided is worth keeping.
> It is considered bad form to put a version into the SVN repo that will
> not build but I do it all the time. As the "boss", I often want to
> sketch out a design of a piece of code and let someone else flesh it
> out. I generally do this to new modules since it is annoying to the rest
> of my team. For some reason, they think that I should be able to write
> code as well as they do.
>
> A more professional way to to this is to use branches. Sometimes someone
> will run into a problem that they need some help with so they commit
> their broken version onto a branch and ask someone else to fix it. This
> branch will eventually be abandoned as the working code is merged back
> into the trunk or tag(if we are fixing an older version)
> This works if your modules are small and the team is not too large.
>
> We need to maintain several versions of the released code so we are
> careful with tags and branches
>
> RELEASE
> Each new release starts with SNAPSHOTs of the modules that are changing.
> We originally made new versions of every module in the system that made
> up a new application release.
> We stopped doing this because it was a lot of work for nothing. Now a
> new release of an application will frequently contain only 3 or 4
> components with updated version numbers.
> We use a simple spreadsheet to document this at the start of a new
> release as we determine which modules will require rebuilding and which
> ones are going to be included in the release untouched.
> We release fairly often so this works well for us.
>
> Deploy
> We deploy SNAPSHOTS as soon as they pass the unit tests and are ready
> for someone else to use.
> These SNAPSHOTS may include mock functionality if that is what other
> members of the team require in order to move forward with their tests.
> This involves communication as to what the SNAPSHOT is capable of doing.
> If it always returns account 123456 regardless of the search criteria
> provided, the other programmer needs to know that.
>
> Once we have got through integration testing of the whole application,
> the SNAPSHOTs are converted to releases and deployed.
> At this point the SVN projects are tagged so we can find the released
> version.
>
> No special Maven plug-ins are required.
>
> You might want to visit our technical blog at
> http://blog.artifact-software.com/tech for more information about our
> processes.
>
> Ron
>
> On 06/01/2011 9:51 AM, Steve Cohen wrote:
>> On 01/06/2011 08:31 AM, Wendy Smoak wrote:
>>> On Thu, Jan 6, 2011 at 9:18 AM, Steve Cohen<sc...@javactivity.org>
>>> wrote:
>>>>> Set all your versions to end in -SNAPSHOT, that way you can leave them
>>>>> in the aggregated build without the repository manager complaining on
>>>>> deploy.
>>>>>
>>>>
>>>> Yes, I suppose I could do that (which is pretty much what I did
>>>> before), but
>>>> it sort of defeats the whole purpose of what I'm trying to
>>>> accomplish here,
>>>> which is, be a little more organized about what is release and what
>>>> is in
>>>> development.
>>>>
>>>>> If one of the modules is stable, do a release of it and have the other
>>>>> modules depend on that released version (but you can still build the
>>>>> next snapshot in your aggregator build.)
>>>>
>>>> Is what you are saying, then, that I need to "comment out" the stable
>>>> modules as modules in the aggregator project? That would pull them
>>>> from the
>>>> repo (they are then just dependencies, like third party jars)? It
>>>> would be
>>>> nice not to have to mess with the POMs in this way. That's what I'm
>>>> looking
>>>> for.
>>>
>>> No commenting out. I was trying to make the fewest changes to your
>>> current setup as possible, since you said you didn't want to redesign
>>> the build.
>>>
>>> Following the Maven conventions, you never have a non-SNAPSHOT version
>>> number checked in on a trunk or branch -- only on a tag. (Or briefly
>>> while a release is happening.)
>>
>> <sigh> Convention over configuration again. Another convention I
>> didn't know was a convention and am not following. I have a bunch of
>> projects under one master project heading and I simply branch/tag from
>> the trunk of that master as needed. Very convenient and I'd rather not
>> give it up.
>>
>> What a frustrating beast Maven is. Can't live with it, can't live
>> without it.
>>
>>>
>>> It sounds like right now you are building an artifact with a
>>> non-snapshot version number over and over. That goes against the idea
>>> that 'releases never change' -- releases should be built once, put in
>>> the repository, and pulled from there when needed.
>>>
>>> The version numbers make it clear what's under development and what's
>>> not. If module A depends on B-1.1-SNAPSHOT (being built in the
>>> aggregated build,) then B is under development. If A depends on
>>> B-1.0, then you are using a stable version of B.
>>>
>>> Maven does not currently have the concept of 'skip deployment if my
>>> version number does not end in -SNAPSHOT'. You'd probably have to put
>>> the deploy plugin configured to with 'skip=true' in a profile, and
>>> patch the profile activation code to understand that concept.
>>>
>>
>> Does anyone else think my desires here are not a terrible idea but a
>> valid wish list item?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
Thanks, Ron, this sounds similar to what I'm aiming for, at least in
your conception of how mvn and svn should fit together.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven deploy module conditionally
Posted by Ron Wheeler <rw...@artifact-software.com>.
We build a very large project in a very simple way.
The handling of software sources is handled separately from Maven.
SOURCE POLICY
All software changes are recorded in the Subversion repository in the
trunk or branch or tag regardless of the build status.
Anyone should be able find the sources for any piece of software that a
programmer has decided is worth keeping.
It is considered bad form to put a version into the SVN repo that will
not build but I do it all the time. As the "boss", I often want to
sketch out a design of a piece of code and let someone else flesh it
out. I generally do this to new modules since it is annoying to the
rest of my team. For some reason, they think that I should be able to
write code as well as they do.
A more professional way to to this is to use branches. Sometimes someone
will run into a problem that they need some help with so they commit
their broken version onto a branch and ask someone else to fix it. This
branch will eventually be abandoned as the working code is merged back
into the trunk or tag(if we are fixing an older version)
This works if your modules are small and the team is not too large.
We need to maintain several versions of the released code so we are
careful with tags and branches
RELEASE
Each new release starts with SNAPSHOTs of the modules that are changing.
We originally made new versions of every module in the system that made
up a new application release.
We stopped doing this because it was a lot of work for nothing. Now a
new release of an application will frequently contain only 3 or 4
components with updated version numbers.
We use a simple spreadsheet to document this at the start of a new
release as we determine which modules will require rebuilding and which
ones are going to be included in the release untouched.
We release fairly often so this works well for us.
Deploy
We deploy SNAPSHOTS as soon as they pass the unit tests and are ready
for someone else to use.
These SNAPSHOTS may include mock functionality if that is what other
members of the team require in order to move forward with their tests.
This involves communication as to what the SNAPSHOT is capable of doing.
If it always returns account 123456 regardless of the search criteria
provided, the other programmer needs to know that.
Once we have got through integration testing of the whole application,
the SNAPSHOTs are converted to releases and deployed.
At this point the SVN projects are tagged so we can find the released
version.
No special Maven plug-ins are required.
You might want to visit our technical blog at
http://blog.artifact-software.com/tech for more information about our
processes.
Ron
On 06/01/2011 9:51 AM, Steve Cohen wrote:
> On 01/06/2011 08:31 AM, Wendy Smoak wrote:
>> On Thu, Jan 6, 2011 at 9:18 AM, Steve Cohen<sc...@javactivity.org>
>> wrote:
>>>> Set all your versions to end in -SNAPSHOT, that way you can leave them
>>>> in the aggregated build without the repository manager complaining on
>>>> deploy.
>>>>
>>>
>>> Yes, I suppose I could do that (which is pretty much what I did
>>> before), but
>>> it sort of defeats the whole purpose of what I'm trying to
>>> accomplish here,
>>> which is, be a little more organized about what is release and what
>>> is in
>>> development.
>>>
>>>> If one of the modules is stable, do a release of it and have the other
>>>> modules depend on that released version (but you can still build the
>>>> next snapshot in your aggregator build.)
>>>
>>> Is what you are saying, then, that I need to "comment out" the stable
>>> modules as modules in the aggregator project? That would pull them
>>> from the
>>> repo (they are then just dependencies, like third party jars)? It
>>> would be
>>> nice not to have to mess with the POMs in this way. That's what I'm
>>> looking
>>> for.
>>
>> No commenting out. I was trying to make the fewest changes to your
>> current setup as possible, since you said you didn't want to redesign
>> the build.
>>
>> Following the Maven conventions, you never have a non-SNAPSHOT version
>> number checked in on a trunk or branch -- only on a tag. (Or briefly
>> while a release is happening.)
>
> <sigh> Convention over configuration again. Another convention I
> didn't know was a convention and am not following. I have a bunch of
> projects under one master project heading and I simply branch/tag from
> the trunk of that master as needed. Very convenient and I'd rather
> not give it up.
>
> What a frustrating beast Maven is. Can't live with it, can't live
> without it.
>
>>
>> It sounds like right now you are building an artifact with a
>> non-snapshot version number over and over. That goes against the idea
>> that 'releases never change' -- releases should be built once, put in
>> the repository, and pulled from there when needed.
>>
>> The version numbers make it clear what's under development and what's
>> not. If module A depends on B-1.1-SNAPSHOT (being built in the
>> aggregated build,) then B is under development. If A depends on
>> B-1.0, then you are using a stable version of B.
>>
>> Maven does not currently have the concept of 'skip deployment if my
>> version number does not end in -SNAPSHOT'. You'd probably have to put
>> the deploy plugin configured to with 'skip=true' in a profile, and
>> patch the profile activation code to understand that concept.
>>
>
> Does anyone else think my desires here are not a terrible idea but a
> valid wish list item?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven deploy module conditionally
Posted by Steve Cohen <sc...@javactivity.org>.
On 01/06/2011 08:31 AM, Wendy Smoak wrote:
> On Thu, Jan 6, 2011 at 9:18 AM, Steve Cohen<sc...@javactivity.org> wrote:
>>> Set all your versions to end in -SNAPSHOT, that way you can leave them
>>> in the aggregated build without the repository manager complaining on
>>> deploy.
>>>
>>
>> Yes, I suppose I could do that (which is pretty much what I did before), but
>> it sort of defeats the whole purpose of what I'm trying to accomplish here,
>> which is, be a little more organized about what is release and what is in
>> development.
>>
>>> If one of the modules is stable, do a release of it and have the other
>>> modules depend on that released version (but you can still build the
>>> next snapshot in your aggregator build.)
>>
>> Is what you are saying, then, that I need to "comment out" the stable
>> modules as modules in the aggregator project? That would pull them from the
>> repo (they are then just dependencies, like third party jars)? It would be
>> nice not to have to mess with the POMs in this way. That's what I'm looking
>> for.
>
> No commenting out. I was trying to make the fewest changes to your
> current setup as possible, since you said you didn't want to redesign
> the build.
>
> Following the Maven conventions, you never have a non-SNAPSHOT version
> number checked in on a trunk or branch -- only on a tag. (Or briefly
> while a release is happening.)
<sigh> Convention over configuration again. Another convention I didn't
know was a convention and am not following. I have a bunch of projects
under one master project heading and I simply branch/tag from the trunk
of that master as needed. Very convenient and I'd rather not give it up.
What a frustrating beast Maven is. Can't live with it, can't live
without it.
>
> It sounds like right now you are building an artifact with a
> non-snapshot version number over and over. That goes against the idea
> that 'releases never change' -- releases should be built once, put in
> the repository, and pulled from there when needed.
>
> The version numbers make it clear what's under development and what's
> not. If module A depends on B-1.1-SNAPSHOT (being built in the
> aggregated build,) then B is under development. If A depends on
> B-1.0, then you are using a stable version of B.
>
> Maven does not currently have the concept of 'skip deployment if my
> version number does not end in -SNAPSHOT'. You'd probably have to put
> the deploy plugin configured to with 'skip=true' in a profile, and
> patch the profile activation code to understand that concept.
>
Does anyone else think my desires here are not a terrible idea but a
valid wish list item?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven deploy module conditionally
Posted by Wendy Smoak <ws...@gmail.com>.
On Thu, Jan 6, 2011 at 9:18 AM, Steve Cohen <sc...@javactivity.org> wrote:
>> Set all your versions to end in -SNAPSHOT, that way you can leave them
>> in the aggregated build without the repository manager complaining on
>> deploy.
>>
>
> Yes, I suppose I could do that (which is pretty much what I did before), but
> it sort of defeats the whole purpose of what I'm trying to accomplish here,
> which is, be a little more organized about what is release and what is in
> development.
>
>> If one of the modules is stable, do a release of it and have the other
>> modules depend on that released version (but you can still build the
>> next snapshot in your aggregator build.)
>
> Is what you are saying, then, that I need to "comment out" the stable
> modules as modules in the aggregator project? That would pull them from the
> repo (they are then just dependencies, like third party jars)? It would be
> nice not to have to mess with the POMs in this way. That's what I'm looking
> for.
No commenting out. I was trying to make the fewest changes to your
current setup as possible, since you said you didn't want to redesign
the build.
Following the Maven conventions, you never have a non-SNAPSHOT version
number checked in on a trunk or branch -- only on a tag. (Or briefly
while a release is happening.)
It sounds like right now you are building an artifact with a
non-snapshot version number over and over. That goes against the idea
that 'releases never change' -- releases should be built once, put in
the repository, and pulled from there when needed.
The version numbers make it clear what's under development and what's
not. If module A depends on B-1.1-SNAPSHOT (being built in the
aggregated build,) then B is under development. If A depends on
B-1.0, then you are using a stable version of B.
Maven does not currently have the concept of 'skip deployment if my
version number does not end in -SNAPSHOT'. You'd probably have to put
the deploy plugin configured to with 'skip=true' in a profile, and
patch the profile activation code to understand that concept.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven deploy module conditionally
Posted by Steve Cohen <sc...@javactivity.org>.
On 01/06/2011 08:05 AM, Wendy Smoak wrote:
> On Thu, Jan 6, 2011 at 8:36 AM, Steve Cohen<sc...@javactivity.org> wrote:
>
>> But I would rather not, if possible, redesign my entire build process. I'd
>> like to be able to modify it to call "mvn deploy" instead of "mvn install".
>> Of course this won't work with the nexus repository. So my question is, is
>> there a way to tell maven, when building an assembly of modules,
>>
>> a) to only build release modules if their POM version number is not already
>> in the repository,
>> or
>> b) alternatively, to simply not try to deploy release modules that already
>> are in the repository
>> or
>> c) not to fail the whole build when an attempted deployment of a module
>> fails for this reason?
>
> Set all your versions to end in -SNAPSHOT, that way you can leave them
> in the aggregated build without the repository manager complaining on
> deploy.
>
Yes, I suppose I could do that (which is pretty much what I did before),
but it sort of defeats the whole purpose of what I'm trying to
accomplish here, which is, be a little more organized about what is
release and what is in development.
> If one of the modules is stable, do a release of it and have the other
> modules depend on that released version (but you can still build the
> next snapshot in your aggregator build.)
>
Is what you are saying, then, that I need to "comment out" the stable
modules as modules in the aggregator project? That would pull them from
the repo (they are then just dependencies, like third party jars)? It
would be nice not to have to mess with the POMs in this way. That's
what I'm looking for.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven deploy module conditionally
Posted by Wendy Smoak <ws...@gmail.com>.
On Thu, Jan 6, 2011 at 8:36 AM, Steve Cohen <sc...@javactivity.org> wrote:
> But I would rather not, if possible, redesign my entire build process. I'd
> like to be able to modify it to call "mvn deploy" instead of "mvn install".
> Of course this won't work with the nexus repository. So my question is, is
> there a way to tell maven, when building an assembly of modules,
>
> a) to only build release modules if their POM version number is not already
> in the repository,
> or
> b) alternatively, to simply not try to deploy release modules that already
> are in the repository
> or
> c) not to fail the whole build when an attempted deployment of a module
> fails for this reason?
Set all your versions to end in -SNAPSHOT, that way you can leave them
in the aggregated build without the repository manager complaining on
deploy.
If one of the modules is stable, do a release of it and have the other
modules depend on that released version (but you can still build the
next snapshot in your aggregator build.)
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org