We're working on this on the Cargo dev list. For some reason the metadata
for the Cargo plugin is wrong. It should be "cargo" as a prefix, not
"cargo2". The JIRA ticket to get this fixed at Codehaus (and then synced to
central) is HAUS-2107 [1] if anyone wants to follow the progress.
/Anders
[1]
I don't like to use version ranges and I agree that it is evil.
This is just example that it is possible.
I just want to use the latest version from full dependency tree. This is
absolutely reproducable. Do you agree with that?
Now I set version of A in D each time some middle artifact is changed.
2011/8/6 Ron Wheeler
> On 06/08/2011 12:53 PM, Eric Kolotyluk wrote:
>
>> I love it :-)
>>
>> I keep seeing some of the most clever insightful statements from the
>> people of this list.
>>
>> Less the voice of insight and more of bitter experience.
> We all got the same amount of rope at the st
> mvn carg2:help works. I got some successful maven downloads with this
> command.
>
> [ERROR] No plugin found for prefix 'glassfish' in the current project and in
> the plugin groups [org.codehaus.cargo, org.apache.maven.plugins,
What is the exact command you are trying to run? Copy and paste fro
On 06/08/2011 12:53 PM, Eric Kolotyluk wrote:
I love it :-)
I keep seeing some of the most clever insightful statements from the
people of this list.
Less the voice of insight and more of bitter experience.
We all got the same amount of rope at the start. It just takes a while
to appreciate
I love it :-)
I keep seeing some of the most clever insightful statements from the
people of this list.
I made a killer knot that took months before it manifest, and took me
over a week to finally figure out - but was not related to version stuff.
Cheers, Eric
On 2011-08-06 9:29 AM, Ron Wh
2011/8/6 Ron Wheeler
> On 06/08/2011 11:47 AM, boraldo wrote:
>
>> I am absolutely agree with your opinion that unreproducability of build is
>> a
>> bad feature, but ...
>>
>> 1. Maven has a built-in mechanism of dependency version range
>> (http://docs.codehaus.org/**display/MAVEN/Dependency+**
On 06/08/2011 11:47 AM, boraldo wrote:
I am absolutely agree with your opinion that unreproducability of build is a
bad feature, but ...
1. Maven has a built-in mechanism of dependency version range
(http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMe
I am absolutely agree with your opinion that unreproducability of build is a
bad feature, but ...
1. Maven has a built-in mechanism of dependency version range
(http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVe
And by the way, documentation is cool.
But even better is look for real-life example. And what's cool with
opensource is that it's easy to find a bunch of examples from simple to very
complex.
Cheers
2011/8/6 Baptiste MATHUS
> Well, you were in the right place.
> http://maven.apache.org/guides/
Well, you were in the right place.
http://maven.apache.org/guides/plugin/guide-java-plugin-development.html
What are you missing?
As often today in programming, Maven mojo gets "external" property via
dependency injection.
That is, just declare your attribute with the right @parameter expression
The thing is: Maven can't really know by itself if it's desirable to
aggressively unlock this directory. You might be editing something inside
yourself, ...
So, for the record, what was preventing you from deleting Target directory?
Cheers
Le 5 août 2011 20:24, "javafan2011" a écrit :
> Hmm, Loo
Hi Trent!
Just use the setting in the section for the
specific repository and set it to 'never' or 'daily'.
You can either set this in your own pom.xml or in your ~/.m2/settings.xml [1].
LieGrue,
strub
[1] http://maven.apache.org/ref/2.0.8/maven-settings/settings.html
--- On Fri, 8/5/11, T
13 matches
Mail list logo