+1 option B [ ] Merge the branch into the existing trunk.
Nico.
2007/4/26, Joakim Erdfelt [EMAIL PROTECTED]:
Lots of work has been done in the archiva database branch in the past 2
months.
It has come time to start the merge back into trunk and get the help of
others to finish off the work.
Trygve Laugstøl wrote:
Joakim Erdfelt wrote:
Lots of work has been done in the archiva database branch in the past
2 months.
It has come time to start the merge back into trunk and get the help
of others to finish off the work.
I wanted to point people to the branch and let them take a
I'm testing Nicola's patch on the trunk and I wanted to apply them before
the end of the week.
I'm not sure that it's a good solution if you merge the branch.
Did you have a look if there was a lot of changes in the trunk since you
created the branch ?
Arnaud
On 26/04/07, Maria Odea Ching
Arik Kfir wrote on Wednesday, April 25, 2007 4:15 PM:
Doesn't the jmock2 contains the classes of jmock1 as well?
No. They should be used side-by-side.
And this is a general problem. No project will change their domain/packages and
adjust artifact names, simply because Maven cannot handle the
Hi
Look at hibernate2 and hibernate3 artifacts. They have hibernate and
org.hibernate
groupIds respectively, so they can be used together (java package names
are different too).
This is IMO the proper way to do this.
While writing this mail I found:
Grzegorz Slowikowski wrote on Thursday, April 26, 2007 10:47 AM:
Hi
Look at hibernate2 and hibernate3 artifacts. They have hibernate and
org.hibernate
groupIds respectively, so they can be used together (java package
names are different too).
This is IMO the proper way to do this.
IMO, if the project claims to be backwards-compatible, then it should
include the older classes. If they can exist side-by-side, there should be
no issue.
I see your point, though - I just don't think it is methodology-correct to
use different versions of the same project in one place,
On 26 Apr 07, at 6:05 AM 26 Apr 07, Arik Kfir wrote:
IMO, if the project claims to be backwards-compatible, then it should
include the older classes. If they can exist side-by-side, there
should be
no issue.
I don't think you can force every project to do this, and I think
that users
+1 option B [ ] Merge the branch into the existing trunk.
Btw, great work on the branch!
Count me in for the other issues :)
Thanks,
Deng
Joakim Erdfelt wrote:
Lots of work has been done in the archiva database branch in the past
2 months.
It has come time to start the merge back into trunk
Hi Jason,
Jason van Zyl wrote on Thursday, April 26, 2007 1:52 PM:
On 26 Apr 07, at 6:05 AM 26 Apr 07, Arik Kfir wrote:
IMO, if the project claims to be backwards-compatible, then it should
include the older classes. If they can exist side-by-side, there
should be no issue.
I don't
Couldn't you just use shade and/or uber jar to combine into a new one and
depend on that?
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 26, 2007 7:52 AM
To: Maven Developers List
Subject: Re: Dep to same artifact in different versions
On 26
Hi,
may I nag for someone's attention to MNG-2854? This is an issue which
could improve Maven's speed for larger projects a real lot.
Jochen
--
My cats know that I am a loser who goes out for hunting every day
without ever returning as much as a single mouse. Fortunately, I've
got a wife who's
Good day,
Anybody want to comment on [1]. I think this has already been asked
several times, and it would be interesting what the other developers
would suggest as the best practice :-)
Thanks,
Franz
[1] http://www.nabble.com/forum/ViewPost.jtp?post=9512947framed=yskin=177
On 26 Apr 07, at 8:20 AM 26 Apr 07, Jörg Schaible wrote:
Hi Jason,
Jason van Zyl wrote on Thursday, April 26, 2007 1:52 PM:
On 26 Apr 07, at 6:05 AM 26 Apr 07, Arik Kfir wrote:
IMO, if the project claims to be backwards-compatible, then it
should
include the older classes. If they can
Jason van Zyl wrote on Thursday, April 26, 2007 3:21 PM:
On 26 Apr 07, at 8:20 AM 26 Apr 07, Jörg Schaible wrote:
[snip]
Therefore the slots. The project itself can introduce them, if two
major versions can be used at same time. Think about a hypothetical
commons-logging 2.0 (it is
Franz Allan Valencia See wrote:
Good day,
Anybody want to comment on [1]. I think this has already been asked
several times, and it would be interesting what the other developers
would suggest as the best practice :-)
I wrote [1] on the subject a while back.
[1]
Option C: Tests don't work on windows so I can't test it.
When they'll be fixed, I'll be for Option B.
Emmanuel
Joakim Erdfelt a écrit :
Lots of work has been done in the archiva database branch in the past 2
months.
It has come time to start the merge back into trunk and get the help of
On 26 Apr 07, at 10:12 AM 26 Apr 07, Jörg Schaible wrote:
Jason van Zyl wrote on Thursday, April 26, 2007 3:21 PM:
On 26 Apr 07, at 8:20 AM 26 Apr 07, Jörg Schaible wrote:
[snip]
Therefore the slots. The project itself can introduce them, if two
major versions can be used at same time.
Jason van Zyl wrote on Thursday, April 26, 2007 4:41 PM:
On 26 Apr 07, at 10:12 AM 26 Apr 07, Jörg Schaible wrote:
Jason van Zyl wrote on Thursday, April 26, 2007 3:21 PM:
On 26 Apr 07, at 8:20 AM 26 Apr 07, Jörg Schaible wrote:
[snip]
Therefore the slots. The project itself can
ok, I found why I had Embedded error: duplicate entry:: when I add wagon-ssh
as a dependency, I get plexus:plexus-utils as a transitive dependency, which
conflicts with org.codehaus.plexus:plexus-utils.
Adding excludeplexus:plexus-utils/exclude solved my problem.
Then, here are the figures
Nice, thanks.
I'm doing some Ant (well, a conversion) so I'll take a look as soon
as I can.
Thanks,
Jason.
On 26 Apr 07, at 4:45 PM 26 Apr 07, Hervé BOUTEMY wrote:
ok, I found why I had Embedded error: duplicate entry:: when I
add wagon-ssh
as a dependency, I get plexus:plexus-utils as
Issue Subscription
Filter: Design Best Practices (37 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
Has anyone had experience with Plexus CommandShell on Windows?
I am finding that it is creating a Process like:
[cmd, /C, /X, C:\path\to\maven\mvn.bat goal1 goal2]
(mvn.bat is quoted because it contains spaces)
And that java.lang.Process is throwing an IllegalArgumentException
(without any
On 4/27/07, Barrie Treloar [EMAIL PROTECTED] wrote:
Has anyone had experience with Plexus CommandShell on Windows?
I am finding that it is creating a Process like:
[cmd, /C, /X, C:\path\to\maven\mvn.bat goal1 goal2]
(mvn.bat is quoted because it contains spaces)
And that java.lang.Process is
On 4/27/07, Jerome Lacoste [EMAIL PROTECTED] wrote:
Yes its buggy. See http://jira.codehaus.org/browse/PLXUTILS-31
I want to attach a batch file to the issue to test the problem. Would
you mind help out ?
I will attach it in a few hours. Then we can fix my proposed patch
because it is not
On 4/26/07, Joakim Erdfelt [EMAIL PROTECTED] wrote:
Also, even if we go with option B (which seems to be leading the vote
counts so far) the commit messages will not be lost, the svn log should
still contain that information (if I'm not mistaken).
When I look at 'svn log' for a random part of
26 matches
Mail list logo
