On 01/06/2011 08:31 AM, Wendy Smoak wrote:
On Thu, Jan 6, 2011 at 9:18 AM, Steve Cohen<[email protected]> 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: [email protected]
For additional commands, e-mail: [email protected]
