You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Mark Lundquist <lu...@gmail.com> on 2007/01/29 04:50:38 UTC
Feature request: per-module local version in profile
Hi, I think I've identified a need for a new (hopefully minor) Maven
feature that I'd like to discuss. I've failed to find any solution with
the current feature set (but please let me know if I'm wrong about that!
:-), and although I'm new to the internals of Maven I'd be happy to
contribute the coding effort.
I got involved with Maven through the Cocoon project, which has
something like 250 poms. I'm not a committer, but I'm sort of a "power
user" and occasional contributor. (I mention that because it's possible
that the use case for my feature may not be as compelling from a project
committer standpoint as it is in my non-committer-contributor role,
although ultimately I think the feature would be useful for lots of people).
Basically, I want to be able to have multiple builds of a project (for
example, Cocoon) on my system.
Suppose I have a few separate working areas checked out on my machine,
for the same project. Currently, the two builds "clash" or interfere
with each other, because they are building the same versions of the same
artifacts and installing them into my local repository.
What I would like to achieve is to have a "reference build" of the
project trunk that's untouched by any of my local changes. Then, I can
always debug the reference build to learn how the thing is supposed to
work normally. Or, I might run into some bug in my development, and I
don't know if it's the fault of one of my own changes, or if it was
already broken in trunk. If I had a reference build, I could go try it
there and see. Then, I want to have one or more separate working areas,
for working on unrelated development efforts on the same project.
To pull this off, I need to be able to say "in this working area, module
M builds version V (some local custom version name), *and* all other
modules that depend on P must resolve that dependency to version V", and
I want to accomplish this without touching any poms. Today I would have
to change the poms for this, which means that before submitting my patch
to the committers I would have to go through and manually strip out my
local version changes form the poms -- which could be a pain because I
could also have changes in the poms that *are* part of my patch. And
then afterward, if I want continue development in this working area, I
have to put my local pom version changes back in! Then out (before
preparing the next patch)... then back in again, et unmaintainable
cetera :-/. So this new pom-sparing mechanism ideally would be
configured in an external profile resource (e.g., profiles.xml).
It's been suggested that I could do this by invoking "maven -s ..." to
use another settings file specifying a different <localRepository>. But
that's no good, it's way to error-prone. (And besides that, having
completely separate local repositories for this feels really kludgy and
un-Maveny).
So... questions:
1) WDYT, would this be a useful feature?
2) Do you agree that it's safe, i.e. it does not affect the outcome of a
build and therefore preserves build repeatability/portability?
3) How straightforward would it be to implement? Would it be a good
project for a first-time Maven contributor? :-)
4) Suggestions for syntax to express this in profile.xml?
I'll be out of town away from email for a couple of days, but I look
forward to any discussion! :-)
cheers,
—ml—
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature request: per-module local version in profile
Posted by Mark Lundquist <lu...@gmail.com>.
Mark Lundquist wrote:
>
> <buildVersion>
> <suffix>-JIRA-1234</suffix>
> <artifacts>
> <artifactId>foo</artifactId>
> <artifactId>bar</artifactId>
> <artifactId>biff</artifactId>
> </artifact>
> </buildVersion>
OK, having already dispensed w/ the "prefix" idea in favor of an
across-the-board build-specific private version ID, we can simplify this
some more... there's not reason not to just apply it to every project
that gets built within this build area (see the <activation/directory>
idea). So I think it just collapses to something like:
<buildVersion>JIRA-1234</buildVersion>
WDYT?
—ml—
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature request: per-module local version in profile
Posted by Mark Lundquist <lu...@gmail.com>.
late last night I, Mark Lundquist wrote:
> thinking about it some more, maybe the version to use should be
> specified as a suffix to be applied to whatever the model-determined
> artifact ID would otherwise be. That's the only reasonable way to be
> able to apply this to an aggregate of modules instead of having to
> specify a version separately for each module (because, e.g. in Cocoon,
> there is no longer a single project-wide version "wavefront", we have a
> core+plugins organization now and different things may be on different
> release schedules... and it is maybe still desirable from a local repo
> mgmt POV to have the normal artifact version recognizable within the
> local build-specific version).
nah... on second thought, the prefix idea is too fiddly. I really don't
give a crap about the normal version ID or having the private version ID
being related to it. So, my private, build-local version ID should just
be "foobar" or "JIRA-1234" or whatever.
So, any thoughts about this idea?
cheers,
—ml—
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature request: per-module local version in profile
Posted by Mark Lundquist <lu...@gmail.com>.
Ralph Goers wrote:
> export MAVEN_OPTS=-Dmaven.repo.local=$PWD/.mvn
> Mark Lundquist wrote:
>
>>
>> So my argument is that my expectation that builds would be
>> self-contained was reasonable. And in fact, separate builds on
>> separate machines *are* (by default) self-contained! I am arguing
>> that it *should* make no difference if two or more builds are on the
>> same machine; they should be self-contained by default just as they
>> would be if each build was on its own machine. It appears that Maven
>> doesn't work that way. My question really is, if Maven could be made
>> to work that way, wouldn't that be a good and useful thing?
>
> But it does. I just told you how.
Well... finally! :-)
Thanks a lot for the help, Ralph!
cheers,
—ml—
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature request: per-module local version in profile
Posted by Ralph Goers <Ra...@dslextreme.com>.
Mark Lundquist wrote:
>
> no, of course not... nevertheless, SNAPSHOT is only meaningful in
> relation to a remote repository, right?
I don't really understand why you'd say that. It indicates that this is
an unreleased version. Whether it is in your local repository or a
remote repository doesn't change that. It only changes whether the
artifact is shared with others.
>
>> If you have a local repository for each subproject this should get
>> you what you need.
>
> Really, a local repository for each subproject? I'm not seeing how
> that would work, sorry... can you elaborate?
In maven 1 I often export MAVEN_HOME_LOCAL to a .maven subdirectory at
the root of my project. It then contains only the artifacts (and their
versions) for this specific project. Our CM folks use this technique
when building a project to insure it doesn't try to use anything it
isn't supposed to.
>
>
> Suppose we are working on a big project P, which aggregates a whole
> bunch of subprojects. I check this all out from Subversion trunk, and
> suppose that all the poms already specify SNAPSHOT, because we are
> working on the next release in trunk. Let's say all the poms have
> version 1.0-SNAPSHOT. Okay, then...
>
> Situation 1: Now, I want to build the project, right out of the box
> from my clean trunk checkout. I don't have to tell Maven anything
> special, that this is "my build", or anything else. I just say "mvn
> install" and Maven does what it's supposed to do.
>
> Situation 2: Now suppose I go on to make some code changes. Forget
> SNAPSHOT, OK! :-) They are *already* SNAPSHOT versions. If they
> weren't already, I would make them so as you pointed out, because I
> intend for my changes to be committed — but that would be for the sake
> of the project, it would not be necessary just for my local build to
> work! So once again, I just type "mvn install".
>
> For the purposes of the rest of this example, the two salient aspects
> of this situation are:
>
> (a) Just like in Situtation 1, there is still no special "-s ..." or
> any other voodoo that I have to get right each time I want to build.
> It's just "mvn install";
>
> (b) all of my local changes are committable! There is no change
> (e.g. to a pom) that I would have to revert before I can commit.
> Moving along...
>
> Situtation 3: I decide to work in parallel on some unrelated changes
> to project P. So, I check out trunk again into directory P2. I go
> into P2 and start making my changes, and all is still as it should
> be... or so it seems. I type "mvn install" to build, and everything
> works. No special invocation voodoo, and no uncommittable changes!
> But then...
Bad idea. you should have used settings to have a local repository just
for this sandbox so that it would not intermingle with your pristine
(i.e. already committed) stuff.
>
> Situation 4: I go back to directory P to resume my work there, and I
> find that all is no longer right with the world, because working area
> P1 has installed its own artifacts with the same name+version into my
> local repository "out from under" the build encapsulated by "P". I
> might now make some changes in one subproject and install it, and then
> do something in another subproject that depends on it (e.g. "mvn
> package" or running the program), but this will not take the artfacts
> from P's build, instead it will take the current artifacts from the
> local repo, which are the ones from P2's build!
See above. You screwed yourself.
>
> ---
>
> This Situtation 1-4 scenario happened to me, and it was a surprise.
> At first I didn't know what was going on, and then I figured it out.
> I realize now that to somebody who understands Maven, it's expected
> behavior... not surprising at all. But that's really not the point!
> I wouldn't mind at all if there were some reasonable way to solve the
> problem. But every suggestion I have heard violates properties (a)
> and/or (b) above; they either depend on invocation details, e.g. "mvn
> -s ...", which is error-prone; and/or they require me to make
> uncommittable changes, so that I am left with an admixture of
> commit-bound and uncommittable changes in my working area.
I admit, I prefer Maven 1's way of exporting MAVEN_HOME_LOCAL over
having to use a settings file. It is easy to do echo $MAVEN_HOME_LOCAL
before I type maven .... to verify what I am about to do. However, in
looking through the Maven 2 code it seems that
DefaultMavenSettingsBuilder will look at the system property named
maven.repo.local, if it is defined, to determine where the local
repository is - which is exactly what Maven 1 does. So the main
difference is that the Maven 2 script does not set the -D for
maven.repo.local as the Maven 1 script does. This is easily
accomplished by just doing
export MAVEN_OPTS=-Dmaven.repo.local=$PWD/.mvn
>
> So my argument is that my expectation that builds would be
> self-contained was reasonable. And in fact, separate builds on
> separate machines *are* (by default) self-contained! I am arguing
> that it *should* make no difference if two or more builds are on the
> same machine; they should be self-contained by default just as they
> would be if each build was on its own machine. It appears that Maven
> doesn't work that way. My question really is, if Maven could be made
> to work that way, wouldn't that be a good and useful thing?
But it does. I just told you how.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature request: per-module local version in profile
Posted by Mark Lundquist <lu...@gmail.com>.
Hi Ralph,
Ralph Goers wrote:
> Mark Lundquist wrote:
>
>>
>> IIUC, SNAPSHOT is concerned w/ the relationship btwn. remote and local
>> repositories. That's not in view here.
>
> Huh? SNAPSHOT identifies an artifact as not-released. There is no
> requirement that it ever be published to a remote repository.
no, of course not... nevertheless, SNAPSHOT is only meaningful in
relation to a remote repository, right?
> In our
> environment we have our own private remote repository and after a change
> has been made we do deploy the snapshot to that repository just so
> others can use it.
Yes, and it has to be a SNAPSHOT so that it will get updated to the rest
of the team.
> Of course, the snapshot is never deployed until the
> corresponding source is committed.
Right.
>
> I think what you are referring to is that maven "knows" that snapshots
> change and it determines whether it needs to update the copy in your
> local repository.
Yes, that's what I'm referring to.
> If you have a local repository for each subproject
> this should get you what you need.
Really, a local repository for each subproject? I'm not seeing how that
would work, sorry... can you elaborate?
>
>> [..snip]
>
> I don't understand "If those changes in and of themselves entail a
> change to the pom". You don't change the pom version only when data in
> the pom itself changes. If you changed a project or subproject in any
> way and the pom is not already a snapshot then you need to submit a
> snapshot pom with your change. This is because the next formal release
> MUST have a new version number, no matter how small the change.
Yes, I understand and agree. Please let me try again with another
example :-)...
Suppose we are working on a big project P, which aggregates a whole
bunch of subprojects. I check this all out from Subversion trunk, and
suppose that all the poms already specify SNAPSHOT, because we are
working on the next release in trunk. Let's say all the poms have
version 1.0-SNAPSHOT. Okay, then...
Situation 1: Now, I want to build the project, right out of the box from
my clean trunk checkout. I don't have to tell Maven anything special,
that this is "my build", or anything else. I just say "mvn install" and
Maven does what it's supposed to do.
Situation 2: Now suppose I go on to make some code changes. Forget
SNAPSHOT, OK! :-) They are *already* SNAPSHOT versions. If they
weren't already, I would make them so as you pointed out, because I
intend for my changes to be committed — but that would be for the sake
of the project, it would not be necessary just for my local build to
work! So once again, I just type "mvn install".
For the purposes of the rest of this example, the two salient aspects of
this situation are:
(a) Just like in Situtation 1, there is still no special "-s ..." or
any other voodoo that I have to get right each time I want to build.
It's just "mvn install";
(b) all of my local changes are committable! There is no change
(e.g. to a pom) that I would have to revert before I can commit. Moving
along...
Situtation 3: I decide to work in parallel on some unrelated changes to
project P. So, I check out trunk again into directory P2. I go into P2
and start making my changes, and all is still as it should be... or so
it seems. I type "mvn install" to build, and everything works. No
special invocation voodoo, and no uncommittable changes! But then...
Situation 4: I go back to directory P to resume my work there, and I
find that all is no longer right with the world, because working area P1
has installed its own artifacts with the same name+version into my local
repository "out from under" the build encapsulated by "P". I might now
make some changes in one subproject and install it, and then do
something in another subproject that depends on it (e.g. "mvn package"
or running the program), but this will not take the artfacts from P's
build, instead it will take the current artifacts from the local repo,
which are the ones from P2's build!
---
This Situtation 1-4 scenario happened to me, and it was a surprise. At
first I didn't know what was going on, and then I figured it out. I
realize now that to somebody who understands Maven, it's expected
behavior... not surprising at all. But that's really not the point! I
wouldn't mind at all if there were some reasonable way to solve the
problem. But every suggestion I have heard violates properties (a)
and/or (b) above; they either depend on invocation details, e.g. "mvn -s
...", which is error-prone; and/or they require me to make uncommittable
changes, so that I am left with an admixture of commit-bound and
uncommittable changes in my working area.
So my argument is that my expectation that builds would be
self-contained was reasonable. And in fact, separate builds on separate
machines *are* (by default) self-contained! I am arguing that it
*should* make no difference if two or more builds are on the same
machine; they should be self-contained by default just as they would be
if each build was on its own machine. It appears that Maven doesn't
work that way. My question really is, if Maven could be made to work
that way, wouldn't that be a good and useful thing?
cheers,
—ml–
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature request: per-module local version in profile
Posted by Ralph Goers <Ra...@dslextreme.com>.
Mark Lundquist wrote:
>
> IIUC, SNAPSHOT is concerned w/ the relationship btwn. remote and local
> repositories. That's not in view here.
Huh? SNAPSHOT identifies an artifact as not-released. There is no
requirement that it ever be published to a remote repository. In our
environment we have our own private remote repository and after a change
has been made we do deploy the snapshot to that repository just so
others can use it. Of course, the snapshot is never deployed until the
corresponding source is committed.
I think what you are referring to is that maven "knows" that snapshots
change and it determines whether it needs to update the copy in your
local repository. If you have a local repository for each subproject
this should get you what you need.
>
> I'm not at all convinced :-). You will have to spell it out for me
> blow-by-blow and explain mechanistically just how my problem is solved
> "using SNAPSHOT in conjunction with the -s option".
>
>
> And even if it could be... it still doesn't satisfy my requirement
> that the solution be location-based, i.e. "set-and-forget" vs.
> invocation-dependent. "-s" isn't going to cut it, it has to be plain
> old "mvn" everywhere.
>
>> Yes, you have to modify the POM, but you are supposed to modify the
>> pom when you are making changes to a project.
>
> No, no, no! :-) Let's say I'm starting work on some change set that I
> plan to submit as a patch. If those changes in and of themselves
> entail a change to the pom (e.g., a new module, or a new dependency,
> or a different version of a dependency) then I will change the pom as
> part of my patch. If my changes don't require that, then I absolutely
> *should not* have to make any local tweaks to the pom just for the
> sake of having this build not interfere with other builds of the
> project on my local machine. To say it a different way: the changes I
> make to the pom should be exactly the changes (if any) that I would
> submit as part of my patch, and no more! Didn't you read the
> paragraph in my original post that ends with "et unmaintanable
> cetera"? :-)
I don't understand "If those changes in and of themselves entail a
change to the pom". You don't change the pom version only when data in
the pom itself changes. If you changed a project or subproject in any
way and the pom is not already a snapshot then you need to submit a
snapshot pom with your change. This is because the next formal release
MUST have a new version number, no matter how small the change.
>
> It's like we're talking past each other... I've said "I need feature F
> because there's no way to do X except in this fiddly, error-prone
> way", and you are saying "well, you don't need feature F because there
> is already a way to do it, albeit fiddly and error-prone". That's the
> whole point, that is why I need the feature :-)
Maybe we're talking past each other because I don't believe that is how
maven is designed to work. At least, not from how I've used it for the
last 3 years. And I don't think the paradigm changed all that much with
Maven 2.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature request: per-module local version in profile
Posted by Mark Lundquist <lu...@gmail.com>.
Ralph Goers wrote:
>
>
> Mark Lundquist wrote:
>
>> It's not. Did you read the scenario from my original post? I don't
>> think SNAPSHOT is even in view here.
>
> Yes, I read it.
IIUC, SNAPSHOT is concerned w/ the relationship btwn. remote and local
repositories. That's not in view here.
>
>> Do you think it's currently possible to build two different instances
>> of a project (e.g. one w/ local modifications and one without) on the
>> same machine without them stomping on each other in the repository,
>> (a) without touching any other controlled resource (such as a pom :-)
>> not directly related to the modification in question (i.e., that I
>> would not include in a patch file), and (b) in a location-based way
>> (i.e. that doesn't require me to remember to say some kind of "maven
>> -Dblah.blah"? If so, please tell me how! :-)
>
> I would think that using SNAPSHOT in conjunction with the -s option
> would do what you want.
I'm not at all convinced :-). You will have to spell it out for me
blow-by-blow and explain mechanistically just how my problem is solved
"using SNAPSHOT in conjunction with the -s option".
And even if it could be... it still doesn't satisfy my requirement that
the solution be location-based, i.e. "set-and-forget" vs.
invocation-dependent. "-s" isn't going to cut it, it has to be plain
old "mvn" everywhere.
> Yes, you have to modify the POM, but you are
> supposed to modify the pom when you are making changes to a project.
No, no, no! :-) Let's say I'm starting work on some change set that I
plan to submit as a patch. If those changes in and of themselves entail
a change to the pom (e.g., a new module, or a new dependency, or a
different version of a dependency) then I will change the pom as part of
my patch. If my changes don't require that, then I absolutely *should
not* have to make any local tweaks to the pom just for the sake of
having this build not interfere with other builds of the project on my
local machine. To say it a different way: the changes I make to the pom
should be exactly the changes (if any) that I would submit as part of my
patch, and no more! Didn't you read the paragraph in my original post
that ends with "et unmaintanable cetera"? :-)
It's like we're talking past each other... I've said "I need feature F
because there's no way to do X except in this fiddly, error-prone way",
and you are saying "well, you don't need feature F because there is
already a way to do it, albeit fiddly and error-prone". That's the
whole point, that is why I need the feature :-)
best regards,
—ml—
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature request: per-module local version in profile
Posted by Ralph Goers <Ra...@dslextreme.com>.
Mark Lundquist wrote:
> It's not. Did you read the scenario from my original post? I don't
> think SNAPSHOT is even in view here.
Yes, I read it.
>
> Do you think it's currently possible to build two different instances
> of a project (e.g. one w/ local modifications and one without) on the
> same machine without them stomping on each other in the repository,
> (a) without touching any other controlled resource (such as a pom :-)
> not directly related to the modification in question (i.e., that I
> would not include in a patch file), and (b) in a location-based way
> (i.e. that doesn't require me to remember to say some kind of "maven
> -Dblah.blah"? If so, please tell me how! :-)
I would think that using SNAPSHOT in conjunction with the -s option
would do what you want. Yes, you have to modify the POM, but you are
supposed to modify the pom when you are making changes to a project.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature request: per-module local version in profile
Posted by Andrew Williams <an...@handyande.co.uk>.
So you want to alter the versions that you rely on without altering the pom?
surely that breaks the idea of repeatable builds?
Andy
Mark Lundquist wrote:
> Andrew Williams wrote:
>
>> have you tried referring to a snapshot build using it's full build
>> identifier (date etc)?
>> that has worked for me in some situations in the past.
>
> "Referring to"?
>
> No touching the pom, that's my requirement :-)
>
> I'm looking for a solution, not a kludge that might help in some
> situations. I already know how to kludge it by swapping pom changes
> in and out (see my OP), the point here is to make that unnecessary.
>
> cheers,
> —ml—
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature request: per-module local version in profile
Posted by Mark Lundquist <lu...@gmail.com>.
Andrew Williams wrote:
> have you tried referring to a snapshot build using it's full build
> identifier (date etc)?
> that has worked for me in some situations in the past.
"Referring to"?
No touching the pom, that's my requirement :-)
I'm looking for a solution, not a kludge that might help in some
situations. I already know how to kludge it by swapping pom changes in
and out (see my OP), the point here is to make that unnecessary.
cheers,
—ml—
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature request: per-module local version in profile
Posted by Andrew Williams <an...@handyande.co.uk>.
have you tried referring to a snapshot build using it's full build
identifier (date etc)?
that has worked for me in some situations in the past.
Andy
Mark Lundquist wrote:
> Hi Ralph, fancy meeting you here :-)...
>
> Ralph Goers wrote:
>
>> I have one issue with this.
>> Typically, at least in the environment I work in (which uses Maven
>> 1), the version would be something like 1.0.1 only when that version
>> had been released. When doing any modifications the version should
>> become 1.0.2-SNAPSHOT until the next release is performed.
>
> No -- you're talking about versions in the poms, which are controlled
> resources. I am talking about modifications that are *strictly local*
> to a user's personal build. Indeed the mechanism that I'm proposing
> would apply to artifacts that already have a SNAPSHOT version from the
> repository, e.g. the local artifact version for my "foobar" build
> would become "1.0.2-SNAPSHOT-foobar" or whatever.
>
>> You aren't supposed to tack on things like a Jira number.
>
> No, not in a published artifact... but that's not what I'm talking
> about. I'm trying to uniquify the artifacts within my own local repo
> so that I can have multiple builds sharing a local repo and not
> interfering with each other.
>
>> SNAPSHOT should be sufficient to tell maven how to behave.
>
> It's not. Did you read the scenario from my original post? I don't
> think SNAPSHOT is even in view here.
>
> Do you think it's currently possible to build two different instances
> of a project (e.g. one w/ local modifications and one without) on the
> same machine without them stomping on each other in the repository,
> (a) without touching any other controlled resource (such as a pom :-)
> not directly related to the modification in question (i.e., that I
> would not include in a patch file), and (b) in a location-based way
> (i.e. that doesn't require me to remember to say some kind of "maven
> -Dblah.blah"? If so, please tell me how! :-)
>
> cheers,
> —ml—
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature request: per-module local version in profile
Posted by Mark Lundquist <lu...@gmail.com>.
Hi Ralph, fancy meeting you here :-)...
Ralph Goers wrote:
> I have one issue with this.
> Typically, at least in the environment I work in (which uses Maven 1),
> the version would be something like 1.0.1 only when that version had
> been released. When doing any modifications the version should become
> 1.0.2-SNAPSHOT until the next release is performed.
No -- you're talking about versions in the poms, which are controlled
resources. I am talking about modifications that are *strictly local*
to a user's personal build. Indeed the mechanism that I'm proposing
would apply to artifacts that already have a SNAPSHOT version from the
repository, e.g. the local artifact version for my "foobar" build would
become "1.0.2-SNAPSHOT-foobar" or whatever.
> You aren't supposed
> to tack on things like a Jira number.
No, not in a published artifact... but that's not what I'm talking
about. I'm trying to uniquify the artifacts within my own local repo so
that I can have multiple builds sharing a local repo and not interfering
with each other.
> SNAPSHOT should be sufficient to tell maven how to behave.
It's not. Did you read the scenario from my original post? I don't
think SNAPSHOT is even in view here.
Do you think it's currently possible to build two different instances of
a project (e.g. one w/ local modifications and one without) on the same
machine without them stomping on each other in the repository, (a)
without touching any other controlled resource (such as a pom :-) not
directly related to the modification in question (i.e., that I would not
include in a patch file), and (b) in a location-based way (i.e. that
doesn't require me to remember to say some kind of "maven -Dblah.blah"?
If so, please tell me how! :-)
cheers,
—ml—
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature request: per-module local version in profile
Posted by Ralph Goers <Ra...@dslextreme.com>.
I have one issue with this.
Typically, at least in the environment I work in (which uses Maven 1),
the version would be something like 1.0.1 only when that version had
been released. When doing any modifications the version should become
1.0.2-SNAPSHOT until the next release is performed. You aren't supposed
to tack on things like a Jira number. SNAPSHOT should be sufficient to
tell maven how to behave.
I'm pretty sure that is how Maven 2 works as well.
Ralph
Mark Lundquist wrote:
> Patrick Schneider wrote:
>
>>
>> On 1/28/07, Mark Lundquist <lu...@gmail.com> wrote:
>>
>>>
>>> [..snip]
>>> To pull this off, I need to be able to say "in this working area,
>>> module
>>> M builds version V (some local custom version name), *and* all other
>>> modules that depend on P must resolve that dependency to version V"
>>
>> Forgive me if this is obvious, but in your description here...
>>
>> "in this working area, module M builds version V (some local custom
>> version
>> name), *and* all other modules that depend on P must resolve that
>> dependency to version V"
>>
>> ...what is P?
>
> D'oh... bother, it looks like I changed horses in mid-stream there. I
> meant "M", the module in question.
>
> Just to clarify, the idea is to do this for a number of modules. And
> thinking about it some more, maybe the version to use should be
> specified as a suffix to be applied to whatever the model-determined
> artifact ID would otherwise be. That's the only reasonable way to be
> able to apply this to an aggregate of modules instead of having to
> specify a version separately for each module (because, e.g. in Cocoon,
> there is no longer a single project-wide version "wavefront", we have
> a core+plugins organization now and different things may be on
> different release schedules... and it is maybe still desirable from a
> local repo mgmt POV to have the normal artifact version recognizable
> within the local build-specific version).
>
> So just for an example... let's say that I have JIRA'd up a bug or
> feature request, and it has issue ID 1234. I check out a new working
> area to work on that issue (probably a partial checkout w/ just the
> module(s) I need to work on), and I decide to use that issue ID to
> uniquify the artifacts for this build. So, maybe something like this
> in profiles.xml:
>
> <buildVersion>
> <suffix>-JIRA-1234</suffix>
> <artifacts>
> <artifactId>foo</artifactId>
> <artifactId>bar</artifactId>
> <artifactId>biff</artifactId>
> </artifact>
> </buildVersion>
>
> If these artifacts would normally build versions "1.0", "1.3", and
> "1.4-M1" respectively, then with this profile they would build with
> versions "1.0-JIRA-1234", "1.3-JIRA-1234", and "1.5-M1-JIRA-1234", and
> if one of these modules declares a dependency, say, on artifact "foo"
> then that will get resolved (in this build) to version "1.0-JIRA-1234"
> (the version of that module built in this build). Does that make sense?
>
> Also, one thing I haven't figured out yet is how to make it so that
> this profile is seen by all of the modules (remember, this has to be
> totally location-based, not dependent on environment or invocation).
> Do I also need a new type of activation trigger to make this work, e.g.
>
> <activation>
> <directory>/Users/ml/killer-app/new-feature</directory>
> </activation>
>
> to activate the profile anywhere within the directory hierarchy rooted
> at the given path? Or is that not necessary? Sorry, I'm still pretty
> new to Maven and have never actually used build profiles, so I may not
> have a good enough feel for it yet...
>
> Cheers,
> —ml—
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature request: per-module local version in profile
Posted by Mark Lundquist <lu...@gmail.com>.
Patrick Schneider wrote:
>
> On 1/28/07, Mark Lundquist <lu...@gmail.com> wrote:
>
>>
>> [..snip]
>> To pull this off, I need to be able to say "in this working area, module
>> M builds version V (some local custom version name), *and* all other
>> modules that depend on P must resolve that dependency to version V"
>
> Forgive me if this is obvious, but in your description here...
>
> "in this working area, module M builds version V (some local custom version
> name), *and* all other modules that depend on P must resolve that
> dependency to version V"
>
> ...what is P?
D'oh... bother, it looks like I changed horses in mid-stream there. I
meant "M", the module in question.
Just to clarify, the idea is to do this for a number of modules. And
thinking about it some more, maybe the version to use should be
specified as a suffix to be applied to whatever the model-determined
artifact ID would otherwise be. That's the only reasonable way to be
able to apply this to an aggregate of modules instead of having to
specify a version separately for each module (because, e.g. in Cocoon,
there is no longer a single project-wide version "wavefront", we have a
core+plugins organization now and different things may be on different
release schedules... and it is maybe still desirable from a local repo
mgmt POV to have the normal artifact version recognizable within the
local build-specific version).
So just for an example... let's say that I have JIRA'd up a bug or
feature request, and it has issue ID 1234. I check out a new working
area to work on that issue (probably a partial checkout w/ just the
module(s) I need to work on), and I decide to use that issue ID to
uniquify the artifacts for this build. So, maybe something like this in
profiles.xml:
<buildVersion>
<suffix>-JIRA-1234</suffix>
<artifacts>
<artifactId>foo</artifactId>
<artifactId>bar</artifactId>
<artifactId>biff</artifactId>
</artifact>
</buildVersion>
If these artifacts would normally build versions "1.0", "1.3", and
"1.4-M1" respectively, then with this profile they would build with
versions "1.0-JIRA-1234", "1.3-JIRA-1234", and "1.5-M1-JIRA-1234", and
if one of these modules declares a dependency, say, on artifact "foo"
then that will get resolved (in this build) to version "1.0-JIRA-1234"
(the version of that module built in this build). Does that make sense?
Also, one thing I haven't figured out yet is how to make it so that this
profile is seen by all of the modules (remember, this has to be totally
location-based, not dependent on environment or invocation). Do I also
need a new type of activation trigger to make this work, e.g.
<activation>
<directory>/Users/ml/killer-app/new-feature</directory>
</activation>
to activate the profile anywhere within the directory hierarchy rooted
at the given path? Or is that not necessary? Sorry, I'm still pretty
new to Maven and have never actually used build profiles, so I may not
have a good enough feel for it yet...
Cheers,
—ml—
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Feature request: per-module local version in profile
Posted by Patrick Schneider <ps...@gmail.com>.
Forgive me if this is obvious, but in your description here...
"in this working area, module M builds version V (some local custom version
name), *and* all other modules that depend on P must resolve that dependency
to version V"
...what is P?
On 1/28/07, Mark Lundquist <lu...@gmail.com> wrote:
>
>
> Hi, I think I've identified a need for a new (hopefully minor) Maven
> feature that I'd like to discuss. I've failed to find any solution with
> the current feature set (but please let me know if I'm wrong about that!
> :-), and although I'm new to the internals of Maven I'd be happy to
> contribute the coding effort.
>
> I got involved with Maven through the Cocoon project, which has
> something like 250 poms. I'm not a committer, but I'm sort of a "power
> user" and occasional contributor. (I mention that because it's possible
> that the use case for my feature may not be as compelling from a project
> committer standpoint as it is in my non-committer-contributor role,
> although ultimately I think the feature would be useful for lots of
> people).
>
> Basically, I want to be able to have multiple builds of a project (for
> example, Cocoon) on my system.
>
> Suppose I have a few separate working areas checked out on my machine,
> for the same project. Currently, the two builds "clash" or interfere
> with each other, because they are building the same versions of the same
> artifacts and installing them into my local repository.
>
> What I would like to achieve is to have a "reference build" of the
> project trunk that's untouched by any of my local changes. Then, I can
> always debug the reference build to learn how the thing is supposed to
> work normally. Or, I might run into some bug in my development, and I
> don't know if it's the fault of one of my own changes, or if it was
> already broken in trunk. If I had a reference build, I could go try it
> there and see. Then, I want to have one or more separate working areas,
> for working on unrelated development efforts on the same project.
>
> To pull this off, I need to be able to say "in this working area, module
> M builds version V (some local custom version name), *and* all other
> modules that depend on P must resolve that dependency to version V", and
> I want to accomplish this without touching any poms. Today I would have
> to change the poms for this, which means that before submitting my patch
> to the committers I would have to go through and manually strip out my
> local version changes form the poms -- which could be a pain because I
> could also have changes in the poms that *are* part of my patch. And
> then afterward, if I want continue development in this working area, I
> have to put my local pom version changes back in! Then out (before
> preparing the next patch)... then back in again, et unmaintainable
> cetera :-/. So this new pom-sparing mechanism ideally would be
> configured in an external profile resource (e.g., profiles.xml).
>
> It's been suggested that I could do this by invoking "maven -s ..." to
> use another settings file specifying a different <localRepository>. But
> that's no good, it's way to error-prone. (And besides that, having
> completely separate local repositories for this feels really kludgy and
> un-Maveny).
>
> So... questions:
>
> 1) WDYT, would this be a useful feature?
>
> 2) Do you agree that it's safe, i.e. it does not affect the outcome of a
> build and therefore preserves build repeatability/portability?
>
> 3) How straightforward would it be to implement? Would it be a good
> project for a first-time Maven contributor? :-)
>
> 4) Suggestions for syntax to express this in profile.xml?
>
> I'll be out of town away from email for a couple of days, but I look
> forward to any discussion! :-)
>
> cheers,
> —ml—
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>