>
> > > Eclipse is the first project that introduces this artifactId conflict
> issue,
> >
> > not really, if i create an artifact with a very commons artifactId
> > like "util" i'm in the same trouble
You're right : "IF" you create... but nobody did AFAIK. Only eclipse
artifacts like "*.*.resour
It includes bugfixes in the osgi-maven version conversion
Staged in http://people.apache.org/~carlos/staging-repo
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---
I need this puppy applied and released for the upcoming GShell 1.0-
alpha-1 release, which is a dependency of the upcoming G 2.1 release...
So if we can get this guy patched and published sooner rather than
later it would really help.
I know you are busy, but can you please take a look?
Tha
I need this puppy applied and released for the upcoming GShell 1.0-
alpha-1 release, which is a dependency of the upcoming G 2.1 release...
So if we can get this guy patched and published sooner rather than
later it would really help.
I know you are busy, but can you please take a look?
Tha
It has many improvements related to resolution event handling, using
the latest fixes in Maven 2.0.8
Release is staged in
http://people.apache.org/~carlos/staging-repo/
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess
Hi,
I've just been re-building my project with the new mvn 2.0.8 binary.
Here's my experience so far.
mvn clean install (jars) -> works as 2.0.7
mvn clean package -P (war) -> broken (re-tested on 2.0.7 and works)
So something has changed in 2.0.8 that has affected surefire.
Here is a snippet
By default, Clover instruments tests to determine whether they succeed
or fail, but Clover has an option to use the XML results of the tests
instead.
I'm adding this capability to the maven-clover-plugin, and so I need
to be able to determine where the surefire plugin has been configured
oh, and btw the war plugin already uses the groupId when in conflict :)
http://jira.codehaus.org/browse/MWAR-19
On Nov 29, 2007 10:44 AM, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
> answering several mails here:
>
> > id=org.eclipse.core.eclipse-core-resources
>
> how can I programatically map th
answering several mails here:
> id=org.eclipse.core.eclipse-core-resources
how can I programatically map this back to the OSGi id ?
you must be able to map osgi<->maven
> I totally agree that tools which rely on artifactId-uniqueness are
> technically broken, but is it right to choose a progra
Hi!
I used a few days in bed to write a scm provider for git.
I basically looked at a few of the standard maven scm-providers (cvs, svn, vss)
and decided to
take the maven-scm-providers-svn to act as the basis of the git implementation.
So there are most probably still a few svn-ish commands in t
This vote passed with the following votes:
+1: Lukas, Stéphane, Brian, Fabrizio, Vincent
I will move the artifacts over to the ASF repository.
Cheers,
Vincent
2007/11/25, Vincent Siveton <[EMAIL PROTECTED]>:
> Hi,
>
> Always in the preparation of the Maven Clean Plugin release, I would like to
Can someone on these dl's remove me from these lists. You site does not
show how to do this.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Brian Fox
Sent: Tuesday, November 27, 2007 5:27 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; de
This vote passed with the following votes:
+1 (binding): Dennis Lundberg, Lukas Theussl, Vincent Siveton
+1 (non-binding): Raphaël Piéroni, Olivier Lamy, Marat Radchenko, Dan
Tran, William Ferguson
-0 (non-binding): Hervé Boutemy
No other votes.
I will move the artifacts over to the ASF rep
+1
fabrizio
On Nov 23, 2007 12:52 PM, Brett Porter <[EMAIL PROTECTED]> wrote:
> Alex did the work to make TestNG support pretty much fully functional
> on Surefire trunk some months back and he and Dan Fabulich are now
> discussing this on the surefire-dev list and looking to complete the
> work
+1
fabrizio
On Nov 25, 2007 2:15 PM, Vincent Siveton <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Always in the preparation of the Maven Clean Plugin release, I would like to
> release the file-management:1.2
> The last release was done around one year ago.
>
> Staging repo:
> http://people.apache.org/~v
Any news or concerns about releasing the existing wagon as 1.0?
Jeff
John Casey wrote:
>
> Hi,
>
> I just committed some changes to trunk that should restore backward
> compatibility for using older wagons (at least in the vast majority of
> cases). It may still break if there is an older ver
+1
-Original Message-
From: Vincent Siveton [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 28, 2007 4:39 AM
To: Maven Developers List
Subject: Re: [Vote] Release Maven Shared File Management 1.2
Anyone?
Vincent
2007/11/25, Vincent Siveton <[EMAIL PROTECTED]>:
> Hi,
>
> Always in t
Thanks, I'll fix it.
-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Geoffrey De Smet
Sent: Wednesday, November 28, 2007 4:04 AM
To: dev@maven.apache.org
Subject: Re: Maven 2.0.8 Release
Thanks,
One issue though:
http://maven.apache.org/
notes:
Get Maven 2.0.8
Rel
Dependency tree should be soon, this required 2.0.8 to be released
first.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stuart
McCulloch
Sent: Wednesday, November 28, 2007 12:06 AM
To: Maven Developers List
Subject: release plans for maven-dependency-tre
+1
Stéphane
On Nov 25, 2007 2:15 PM, Vincent Siveton <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Always in the preparation of the Maven Clean Plugin release, I would like to
> release the file-management:1.2
> The last release was done around one year ago.
>
> Staging repo:
> http://people.apache.org/~v
So that means that before evicting a revision you have to read its pom to make
sure it has not been relocated to an
other revision that would not be evicted.
Does maven always read the pom before evicting a revision?
Gilles
> -Original Message-
> From: Max Bowsher [mailto:[EMAIL PROTEC
Gilles Scokart wrote:
> Yes, I understand that someone decided to rename the version number.
>
> My problem is that I don't know how to consider the version number in the
> conflict resolution. If I consider the
> version number of the relocated module or the version number of the 'target
> of
Your right : the packaging plugins may provide a optional workaround to
conflicting artifacts names.
I've created MWAR-132 for this.
Eclipse is the first project that introduces this artifactId conflict issue,
but many other could appear in future, so the plugins must be upgraded asap
to provide a
+1
Vincent
2007/11/24, Dennis Lundberg <[EMAIL PROTECTED]>:
> Hi,
>
> I'd like to release maven-site-plugin 2.0-beta-6.
>
> We have resolved 36 issues since the last release, 18 months ago.
>
> Release Notes:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146&styleName=Html&versio
Herve,
Thanks for fixing this! Just two questions:
Why do we need a separate method in AbstractXmlSink, can't we just
remove the EOL from writeEndTag()?
And what's the reason for selecting only special tags to write no
newline? Just because they are inline elements? This doesn't solve the
i
+1
-Lukas
Vincent Siveton wrote:
Hi,
Always in the preparation of the Maven Clean Plugin release, I would like to
release the file-management:1.2
The last release was done around one year ago.
Staging repo:
http://people.apache.org/~vsiveton/staging-repo/
Vote open for 72 hours.
Here is my
+1
-Lukas
Dennis Lundberg wrote:
Hi,
I'd like to release maven-site-plugin 2.0-beta-6.
We have resolved 36 issues since the last release, 18 months ago.
Release Notes:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146&styleName=Html&version=12151
Tag:
https://svn.apache.or
Hi Hervé,
2007/11/27, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> Author: hboutemy
> Date: Tue Nov 27 15:02:47 2007
> New Revision: 598803
>
> URL: http://svn.apache.org/viewvc?rev=598803&view=rev
> Log:
> [DOXIA-189] removed newline added after anchor, link, bold, italic and
> monospaced tags
>
> M
Carlos Sanchez wrote:
> On Nov 28, 2007 8:07 PM, Max Bowsher <[EMAIL PROTECTED]> wrote:
>> Carlos Sanchez wrote:
>>> As I said before it's easier to add the new bundles using
>>> id=groupId+artifactId than to change the whole repo so artifactId can
>>> be used as id
>>>
>>> You have to consider tha
Anyone?
Vincent
2007/11/25, Vincent Siveton <[EMAIL PROTECTED]>:
> Hi,
>
> Always in the preparation of the Maven Clean Plugin release, I would like to
> release the file-management:1.2
> The last release was done around one year ago.
>
> Staging repo:
> http://people.apache.org/~vsiveton/staging
i do not think anybody want to change the repository:
id=groupId+artifactId
Just that the artifactId may include a part of the groupId
id=org.eclipse.core.org-eclipse-core-resources
I know now that that me have the osgi-id problem, but we have also the
grown average use factor to consider. I
2.0.2 is relocated to 1.0.b2 means 2.0.2=1.0.b2
after you do the replacement you can resolve that 1.3.03 evicts 1.0.b2
(2.0.2 is like never existed)
my 0.02
On Nov 28, 2007 8:13 PM, Gilles Scokart <[EMAIL PROTECTED]> wrote:
> Yes, I understand that someone decided to rename the version number.
>
On Nov 28, 2007 8:07 PM, Max Bowsher <[EMAIL PROTECTED]> wrote:
> Carlos Sanchez wrote:
> > As I said before it's easier to add the new bundles using
> > id=groupId+artifactId than to change the whole repo so artifactId can
> > be used as id
> >
> > You have to consider that the repository is not o
Yes, I understand that someone decided to rename the version number.
My problem is that I don't know how to consider the version number in the
conflict resolution. If I consider the
version number of the relocated module or the version number of the 'target of
the relocation', the result will b
Carlos Sanchez wrote:
> As I said before it's easier to add the new bundles using
> id=groupId+artifactId than to change the whole repo so artifactId can
> be used as id
>
> You have to consider that the repository is not only for Maven users
My point is that the repository is currently in a stat
Thanks,
One issue though:
http://maven.apache.org/
notes:
Get Maven 2.0.8
Released: 20 June 2007
That release date might be a bit off :)
With kind regards,
Geoffrey De Smet
Brian Fox schreef:
The Apache Maven team would like to announce the availability of Maven
2.0.8. We closed out 32 issu
As I said before it's easier to add the new bundles using
id=groupId+artifactId than to change the whole repo so artifactId can
be used as id
You have to consider that the repository is not only for Maven users
On Nov 28, 2007 7:51 PM, Max Bowsher <[EMAIL PROTECTED]> wrote:
> Carlos Sanchez wrot
On Nov 28, 2007 7:09 PM, nicolas de loof <[EMAIL PROTECTED]> wrote:
> 2007/11/28, Carlos Sanchez <[EMAIL PROTECTED]>:
> > plugins (war, ear,...) should support and even make it the default, to
> > package the jars using the full group+arifact id, because using just
> > the artifactId has limitation
Carlos Sanchez wrote:
> On Nov 28, 2007 6:40 PM, Richard van Nieuwenhoven <[EMAIL PROTECTED]> wrote:
>> The reason for me is that eclipse is the source of the jars and eclipse
>> does repeat the group name in the jar name.
>>
>> It looks very strange to have 10 different jars in the classpath all
>
2007/11/28, Carlos Sanchez <[EMAIL PROTECTED]>:
>
> On Nov 28, 2007 6:40 PM, Richard van Nieuwenhoven <[EMAIL PROTECTED]> wrote:
> > The reason for me is that eclipse is the source of the jars and eclipse
> > does repeat the group name in the jar name.
> >
> > It looks very strange to have 10 diffe
Hi,
Such changes will not happen easy! think about the consequences in all
existing MANIFEST.MF files with classpaths .
Most users will use the group id as a organizational help but still use
"almost" unique artifactId's as identifications. -> When i see the name
of the jar i know what it is.
On Nov 28, 2007 6:40 PM, Richard van Nieuwenhoven <[EMAIL PROTECTED]> wrote:
> The reason for me is that eclipse is the source of the jars and eclipse
> does repeat the group name in the jar name.
>
> It looks very strange to have 10 different jars in the classpath all
> called "resource.jar". And
AFAIK we could argue for the same about maven-side artifacts :
why is plexus-utils not simply "utils.jar", as it allready has groupId
"plexus" ?
Nico.
2007/11/28, Richard van Nieuwenhoven <[EMAIL PROTECTED]>:
>
> The reason for me is that eclipse is the source of the jars and eclipse
> does rep
The reason for me is that eclipse is the source of the jars and eclipse
does repeat the group name in the jar name.
It looks very strange to have 10 different jars in the classpath all
called "resource.jar". And what would happen when you need to package
the jars together in a directory (ear, war,
that was because it was published under two different versions, so one
was relocated to the correct one. Not common though
On Nov 28, 2007 6:38 PM, Gilles Scokart <[EMAIL PROTECTED]> wrote:
> As there is no answer in the repository list, maybe I will have more chance
> on the maven list. Sorry f
As there is no answer in the repository list, maybe I will have more chance on
the maven list. Sorry for the
cross-post.
Is there anyone who can explain why it is allowed to relocate a module to an
other revision number? And how it is
supposed to work with conflict resolution?
Thanks,
Gilles
why would we use groupIds and artifactIds if we were going to repeat
the same information in both fields?
this was already brought before and the way the jars are stored
doesn't imply the way they are used
On Nov 27, 2007 8:12 PM, Richard van Nieuwenhoven <[EMAIL PROTECTED]> wrote:
> I think it i
On 28/11/2007, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
>
> I was actually working on it right now ;)
thanks Carlos - I'll let you get back to work!
On Nov 28, 2007 4:06 PM, Stuart McCulloch <[EMAIL PROTECTED]>
> wrote:
> > Hi,
> >
> > are there any plans to release the following shared compone
I was actually working on it right now ;)
On Nov 28, 2007 4:06 PM, Stuart McCulloch <[EMAIL PROTECTED]> wrote:
> Hi,
>
> are there any plans to release the following shared components before the
> end of this year?
>
>org.apache.maven.shared
>maven-dependency-tree
>1.1-SNAPSHOT
>
>
Hi,
are there any plans to release the following shared components before the
end of this year?
org.apache.maven.shared
maven-dependency-tree
1.1-SNAPSHOT
org.apache.maven.shared
maven-osgi
0.2.0-SNAPSHOT
it would be good to know either way, so I can schedule the release of th
50 matches
Mail list logo
