-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Brian,
> First question, wouldn't ${project.version} solve the use case of
> updating same versioned dependencies?
Nope. It would help in some of my business projects where
all artifacts get the same version when released, but
I already have a sim
On Thu, Jul 30, 2009 at 9:51 AM, Ralph Goers wrote:
>
> On Jul 30, 2009, at 5:03 AM, Brian Fox wrote:
>
>> We also have to be careful of the problems introduced in 2.1.0 because
>> of transforming the pom...gpg can't sign etc.
>
> Are those itemized anywhere? Eventually these problems need to be so
During the month of August many more ITs are going to be written and
the POM and resolution specifications will be cleaned up. Until that's
done nothing radical is going to change on trunk. With all the work
that's happening it's still all refactoring, preparation for the
future and restora
On Jul 30, 2009, at 5:03 AM, Brian Fox wrote:
We also have to be careful of the problems introduced in 2.1.0 because
of transforming the pom...gpg can't sign etc.
Are those itemized anywhere? Eventually these problems need to be
solved.
Ralph
2009/7/29 Ralph Goers :
Well, darn. I fina
>
>
> ${project.groupId}
> other-artifactId
> ${project.version}
>
>
> would become:
>
>
> other-artifactId
>
Besides saving a few keystrokes I don't see how that helps much? It's
definitely less obvious. Looking at that, I now have to go search the
parent hierarchy to determine if the ver
We also have to be careful of the problems introduced in 2.1.0 because
of transforming the pom...gpg can't sign etc.
2009/7/29 Ralph Goers :
> Well, darn. I finally read the proposal. From what I can tell this is
> largely what I implemented in
> https://svn.apache.org/repos/asf/maven/componen
Well, darn. I finally read the proposal. From what I can tell this
is largely what I implemented in https://svn.apache.org/repos/asf/maven/components/branches/maven-2.1.x-MNG-624/
. However I was never able to finish that because I ran into one
small little problem.
The proposal says the
I think I skimmed over the modules bit. As my comment suggested, I
only thought it was to replace them where they matched.
ie:
${project.groupId}
other-artifactId
${project.version}
would become:
other-artifactId
Which I think we've seen suggested before.
Anything more than tha
First question, wouldn't ${project.version} solve the use case of
updating same versioned dependencies?
Also: "A that was omitted in a section can only
be resolved if the referenced modules are resolved. So if it is NOT
part of the sub-tree where the build was invoked we have a problem to
solve.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Brett,
Thanks for taking care. I already thought that this will gonna be ignored.
> So the summary is that if omitted on a dependency, the group ID and
> version should match that of the current project, and on deployment it
> needs to be populate
So the summary is that if omitted on a dependency, the group ID and
version should match that of the current project, and on deployment it
needs to be populated?
- Brett
On 24/07/2009, at 5:47 AM, Joerg Hohwiller wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everybody,
I update
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everybody,
I updated my proposal and now think it is consistent and understandable.
However the examples traces still require some thoughts but
you should get the idea easily.
And finally here it is:
http://docs.codehaus.org/display/MAVENUSER/Eas
12 matches
Mail list logo
