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 site
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 the
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
On Fri, Jul 10, 2009 at 6:19 AM, J. den Boer 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
> don't understand
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
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
sour
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 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 w
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
> de
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
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 Lundberg wrote:
> Hi
>
> For a *single* module project, like one of our Maven plugins, do I
> really have to create an a
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 pred
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
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"
de
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 "targe
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, e-mai
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 t
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 wrote:
> The only thing preventing changing the groupId/ArtifactId is that if you
> do, it breaks dependency resolution and
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 coordi
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
p
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
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
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 wrote:
>
> I've long thought that the entry in the poms (or wherever it
> moves to) and mirrors in sett
I've long thought that the entry in the poms (or wherever it
moves to) and mirrors in settings.xml should have some sort of "filters" on
it. Like:
java.net
http://download.java.net/maven/1/
com.sun.*:*
javax.xml.*:*
That would allow limiting sear
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
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 tr
26 matches
Mail list logo
