Hi,
haven't tested this myself with 2.0.6, but take a look at
some other plugins that attach artifacts (javadoc, source,
assembly:attached etc) to see what the differences are.
Those plugins use the ProjectHelper to attach an artifact:
/**
* Used for attaching the artifact in the project
Hi,
Just a quick question as to what this is for?
Is it used in 'help:dependencies'?
Is it/will it be used in maven-core?
I see the dependency plugin uses both dependency-tree and dependency-analyzer,
what's the relation?
If maven core eventually uses this, shouldn't it be moved into
Hi,
where's the spec for this?
I'm working on MNG-2651 and similar, and I'm a bit at a loss as how to proceed.
What does the 'env.' prefix do? System props, env props, or project props?
Should 'pom.' be the same as 'project.' or should one use the Model
and the other MavenProject?
If someone
Hi,
Just did some test wrt MNG-2340 (using maven 2.0.7 and 2.0.6), and this is what
I found:
P with dependencyManagement for lucene 1.3
|
+ my-dep with dependency on lucene 1.4.3
+ my-app with dependency on my-dep
(I modified the attached project locally; rename my-app to my-dep and add
Just another pointer to add. I've put together some wildcard
filtering support for the assembly plugin, and factored it into a
separate library so I could share it with the maven-repository-
builder project. These wildcard-enabled filters are by no means
perfect, but if you're interested in
I think you're questioning if you have this:
dependencyManagement
dependencies
dependency
artifactIdfoo/artifactId
groupIdcom/groupId
version1/version
/dependency
/dependencies
/dependencyManagement
dependencies
dependency
artifactIdfoo/artifactId
groupIdcom/groupId
On 16 Jun 07, at 1:18 AM 16 Jun 07, Kenney Westerhof wrote:
Hi,
where's the spec for this?
I'm working on MNG-2651 and similar, and I'm a bit at a loss as how
to proceed.
What does the 'env.' prefix do? System props, env props, or project
props?
Should 'pom.' be the same as
Kenney Westerhof wrote:
Hi,
Just did some test wrt MNG-2340 (using maven 2.0.7 and 2.0.6), and this is
what I found:
P with dependencyManagement for lucene 1.3
|
+ my-dep with dependency on lucene 1.4.3
+ my-app with dependency on my-dep
(I modified the attached project locally;
Hi Kenney,
your solution worked fine (in 2.0.6). The problem also existed
in 2.0.5. I must have created and attached the Artifact wrongly.
bedankt
Mark
On Jun 15, 2007, at 11:19 PM, Kenney Westerhof wrote:
Hi,
haven't tested this myself with 2.0.6, but take a look at
some other plugins that
Kenney Westerhof wrote:
This somewhat describes the situation:
- depMgt for artifact X is used to provide defaults for direct
dependencies of artifact X,
and for overrides of transitive dependencies on X,
unless there's also a direct dependency on X in which case the direct
dependency is
Brian E. Fox wrote:
I think you're questioning if you have this:
dependencyManagement
dependencies
dependency
artifactIdfoo/artifactId
groupIdcom/groupId
version1/version
/dependency
/dependencies
/dependencyManagement
dependencies
dependency
artifactIdfoo/artifactId
Ralph Goers wrote:
Kenney Westerhof wrote:
This somewhat describes the situation:
- depMgt for artifact X is used to provide defaults for direct
dependencies of artifact X,
and for overrides of transitive dependencies on X,
unless there's also a direct dependency on X in which case the
Jason van Zyl wrote:
On 16 Jun 07, at 1:18 AM 16 Jun 07, Kenney Westerhof wrote:
Hi,
where's the spec for this?
I'm working on MNG-2651 and similar, and I'm a bit at a loss as how to
proceed.
What does the 'env.' prefix do? System props, env props, or project
props?
Should 'pom.' be
On 16 Jun 07, at 9:57 AM 16 Jun 07, Kenney Westerhof wrote:
So before I write something down that's more to the point than an
enumeration of
the flaws in the current implementation and the problems it gives
us, I'd like to
get concensus about the proper way to do it..
People won't pay
Jason van Zyl wrote:
On 16 Jun 07, at 9:57 AM 16 Jun 07, Kenney Westerhof wrote:
So before I write something down that's more to the point than an
enumeration of
the flaws in the current implementation and the problems it gives us,
I'd like to
get concensus about the proper way to do
On 16 Jun 07, at 11:37 AM 16 Jun 07, Kenney Westerhof wrote:
Jason van Zyl wrote:
On 16 Jun 07, at 9:57 AM 16 Jun 07, Kenney Westerhof wrote:
So before I write something down that's more to the point than an
enumeration of
the flaws in the current implementation and the problems it
16 matches
Mail list logo