BRIAN FOX-5 wrote:
Take a look at the maven-dependency-plugin copy-dependencies code,
this is pretty much exactly what you're trying to do. There are
filters that are in a common jar you can reuse to filter out
transitivity etc.
Thanks for the replies guys. I need to download the
Here is some feedback on
http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repositor
y+discovery
Of the 4 requirements listed:
1. ability to checkout and build with no prior setup (extremely
important)
3. separate plugin dependency resolution from project dependency
I've long thought that the repository entry in the poms (or wherever it
moves to) and mirrors in settings.xml should have some sort of filters on
it. Like:
repository
idjava.net/id
urlhttp://download.java.net/maven/1//url
includes
includecom.sun.*:*/include
/includes
We could have this also for mirrors.Another thing we could have in mirror
definition is to say if this is for releases, snapshots or both.
Arnaud
On Thu, Jul 9, 2009 at 4:13 PM, Daniel Kulp dk...@apache.org wrote:
I've long thought that the repository entry in the poms (or wherever it
moves
Arnaud HERITIER schrieb:
For the repository constraint I agree.But what can we recommend to jboss and
others company which have this need to be a good maven citizen ?
I'll have the same issue soon with my company exoplatform.
We are interested to deploy nexus and push some of our artifacts in
Jason van Zyl wrote:
On 8-Jul-09, at 6:57 PM, Stan Devitt wrote:
The only thing that halfway works for rebuilt / modified artifacts is
to modify the version number (e.g. 3.5-mod-by-NameOModifier).
I agree.
As once the patches reach the OSS project it is much easier to make the
change to
I think for most changes the intent is to get the patch back into the upstream
OSS project. But it's kind of dependent on who made the patch and whether the
upstream project would accept it.
Jason van Zyl wrote:
Paul,
Does JBoss never intend to get the patches back to the respective OSS
The only thing preventing changing the groupId/ArtifactId is that if you
do, it breaks dependency resolution and hence the maven model. That is
pretty serious.
Now, ... perhaps if there were some sort of alias facility so that
dependency resolution could be told that two different
Artifact
If in the new pom with another groupId we add the relocation info with old
group, doesn't it solve the problem ? I didn't test.
On Thu, Jul 9, 2009 at 6:04 PM, Stan Devitt sdev...@rim.com wrote:
The only thing preventing changing the groupId/ArtifactId is that if you
do, it breaks dependency
On 08/07/2009, at 3:31 AM, John Casey wrote:
I think that the codebases are diverging enough that it makes sense
to separate them. I'd only say we should do this if we move both,
though...and I guess we'd need to move the maven 2.x branches over
with maven/* as well.
So here's what I'm
Hi
For a *single* module project, like one of our Maven plugins, do I
really have to create an assembly descriptor?
Wouldn't it work if I just use the predefined project descriptor?
--
Dennis Lundberg
-
To unsubscribe,
On 10/07/2009, at 6:22 AM, Dennis Lundberg wrote:
Hi
For a *single* module project, like one of our Maven plugins, do I
really have to create an assembly descriptor?
Wouldn't it work if I just use the predefined project descriptor?
Yes, if you do not have any source packages called target.
Brett Porter wrote:
Wouldn't it work if I just use the predefined project descriptor?
Yes, if you do not have any source packages called target.
Really, what about the LICENSE/NOTICE files that get generated under
target? As far as I grok the project descriptor (and also the src
On Jul 9, 2009, at 1:34 PM, Benjamin Bentmann wrote:
Brett Porter wrote:
Wouldn't it work if I just use the predefined project descriptor?
Yes, if you do not have any source packages called target.
Really, what about the LICENSE/NOTICE files that get generated under
target? As far as I
Sorry I thought Dennis meant the src descriptor. And yes, I forgot
about the LICENSE/NOTICE, since I usually have them in SVN when using
the src descriptor. Good catch.
- Brett
On 10/07/2009, at 6:34 AM, Benjamin Bentmann wrote:
Brett Porter wrote:
Wouldn't it work if I just use the
no...this is what i've been working on just slowly. It's almost done
though, and the idea is that it should just work in almost all cases.
On Thu, Jul 9, 2009 at 4:22 PM, Dennis Lundbergdenn...@apache.org wrote:
Hi
For a *single* module project, like one of our Maven plugins, do I
really have
Based on the recent thread (and after confirming with John and
Benjamin on IRC), I've moved the maven-2.2.x branch to /maven/maven-2/
branches/maven-2.2.x. It was timely to do now before starting a sprint
of work on 2.2.1.
I haven't yet created a maven-2/trunk - I figure that can be copied
OK, thanks everyone for your feedback.
I'll use the source assembly descriptor from the assembly plugin as a
template then.
Brett Porter wrote:
Sorry I thought Dennis meant the src descriptor. And yes, I forgot about
the LICENSE/NOTICE, since I usually have them in SVN when using the src
I know you've put a lot of time and effort into this Brian. Thanks for
that. I thought that most of the work was to fix potential problems in
multi module builds.
Brian Fox wrote:
no...this is what i've been working on just slowly. It's almost done
though, and the idea is that it should just
Hmm, I thought I fixed the project descriptor in 2.2-beta-4? Maybe not...
Brett Porter wrote:
On 10/07/2009, at 6:22 AM, Dennis Lundberg wrote:
Hi
For a *single* module project, like one of our Maven plugins, do I
really have to create an assembly descriptor?
Wouldn't it work if I just use
I'm trying to find the problem why no Eclipse project files can be
generated of an Ear project without installing the required dependencies
first.
I've seen that it's caused by the ear:generate-application-xml goal, but
I don't understand why, how and where it's starten. I checkout out the
J. den Boer wrote:
The test project, just a generated simple j2ee project, used this custom
ear plugin. When running eclipse:eclipse still the
ear:generate-application-xml goal is sought but this goal does not exist
anymore.
I assume your custom plugin has the same groupId and artifactId as
On Fri, Jul 10, 2009 at 6:19 AM, J. den Boerjdb...@diversit.eu wrote:
I'm trying to find the problem why no Eclipse project files can be generated
of an Ear project without installing the required dependencies first.
I've seen that it's caused by the ear:generate-application-xml goal, but I
Issue Subscription
Filter: Design Best Practices (28 issues)
Subscriber: mavendevlist
Key Summary
MNG-2184Possible problem with @aggregator and forked lifecycles
http://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
Hi John,
Some thoughts on this...
On 10/07/2009, at 2:01 PM, jdca...@apache.org wrote:
+
+private String getWagonHint( String protocol, String
repositoryId )
+{
+// TODO: Implement a better way to get the hint, via
settings.xml or something.
While this effectively is
Hi,
I've committed some changes that I'd like reviewed to go forward with
which makes Maven releases easier.
1) see http://maven.apache.org/docs/2.0.11-RC1-SNAPSHOT/release-notes.html
(may not be present yet due to proxying), and relevant commits in
that RC branch
2) see commits in
26 matches
Mail list logo
