Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)

> From: "Barrie Treloar" <[EMAIL PROTECTED]> > > On the users lists I asked about seeding the repo with 3.2.2 eclipse jars. > > There is some talk about doing so and the naming convention that would be > used. > > Jason knows who he has been talking to in the Eclipse world. >From the user maili

Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)

On Wed, Apr 2, 2008 at 5:46 AM, Micah Hainline <[EMAIL PROTECTED]> wrote: > > So can we find a way to suit both sides? > > - keep the tools we have running > > and > > - move to a unique id > > Not having a standard way to reference Eclipse artifacts is a continuing > source of pain. > > It s

Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)

> So can we find a way to suit both sides? > - keep the tools we have running > and > - move to a unique id Not having a standard way to reference Eclipse artifacts is a continuing source of pain. It seems to me that the groupId serves quite well as an identifier for the source of an artifact

Re: in repo1 it is available

There are discrepancies with version ranges between Maven and OSGi. Not much to do as i don't think anybody will go through all Eclipse plugins and update the poms manually. At least for now you can use exclusions, or force the versions you want in dependencyManagement On Dec 29, 2007 9:48 AM, Fel

Re: in repo1 it is available

Carlos Sanchez schrieb: > that's right, I still have to polish the eclipse plugin to generate > the Eclipse repo using some "conventions" > I tried to build 'my' repo for the eclipse-3.3.1.1 version using maven-eclipse-plugin build from trunk with mvn eclipse:to-maven. All worked well and the ar

Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)

ok, just changed my mind. after reading all comments and looking into my needs now. I can work with with the mapping, specially because i need only one at the moment. It is MUCH more important there is a consistent mapping! Than it is that somebody like me likes it or not. Just see a lot of work

Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)

> > > > 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

Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)

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

Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)

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

Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)

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

Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)

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

Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)

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

Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)

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

Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)

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

Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)

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

Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)

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

Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)

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 >

Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)

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

Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)

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.

Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)

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

Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)

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

Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)

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,

Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)

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

Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)

I think it is important that {artifactId}-{version}.jar results in a name as similar as possible the the name as they are in the plugin directory of eclipse. And the eclipse project name should represent the group id of the plugin as on http://www.eclipse.org/projects/ , whereas i do not care if o

groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)

Carlos Sanchez wrote: > I'm uploading right now a good number of jars to > http://repo1.maven.org/eclipse-staging/ > If it looks good I will sync to central > > Note that the location for the one you want should be > http://repo1.maven.org/eclipse-staging/org/eclipse/core/resources/3.2.1/ I wonde

Re: in repo1 it is available

Thanks Carlos, We'll wait that those jars are available to apply richard's patch. Thanks a lot. Arnaud On Nov 27, 2007 9:41 AM, Carlos Sanchez <[EMAIL PROTECTED]> wrote: > I'm uploading right now a good number of jars to > http://repo1.maven.org/eclipse-staging/ > If it looks good I will sy

Re: in repo1 it is available

I'm uploading right now a good number of jars to http://repo1.maven.org/eclipse-staging/ If it looks good I will sync to central Note that the location for the one you want should be http://repo1.maven.org/eclipse-staging/org/eclipse/core/resources/3.2.1/ On Nov 27, 2007 1:13 AM, Arnaud HERITIER

Re: in repo1 it is available

I don't want to mix all problems. I'm not aware about problems of eclipse jars deployments on the central repository. Actually I just want one jar and I would like to know if it's possible to do it Arnaud On Nov 26, 2007 5:23 PM, Felix Knecht <[EMAIL PROTECTED]> wrote: > Do you think there's a c

Re: in repo1 it is available

Do you think there's a chance to get also the eclipse 3.3.1 binary jars into this repository? Thanks Felix > Can we upload some jars in the central repo and more precisely this one : > http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/ > ?? > Arnaud > > On Nov 26, 2

Re: in repo1 it is available

Hi, but it would be better to start with version 3.3.x even if the source we need "now" is unchanged. I checked some other workspace reading stuff and there was a rather good backward compatibility's stuff. Ritchie Arnaud HERITIER wrote: > Can we upload some jars in the central repo and more pr

Re: in repo1 it is available

Can we upload some jars in the central repo and more precisely this one : http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/ ?? Arnaud On Nov 26, 2007 4:15 PM, Carlos Sanchez <[EMAIL PROTECTED]> wrote: > that's right, I still have to polish the eclipse plugin to gen

Re: in repo1 it is available

ah, so we are back in the maven-eclipse-plugin to generate repository from which a dependency we need in the maven-eclipse-plugin. What are the open issues in the repository generation? Ritchie Carlos Sanchez wrote: > that's right, I still have to polish the eclipse plugin to generate > the Ecli

Re: in repo1 it is available

that's right, I still have to polish the eclipse plugin to generate the Eclipse repo using some "conventions" On Nov 26, 2007 10:04 PM, nicolas de loof <[EMAIL PROTECTED]> wrote: > AFAIK this one is an experimental repository created by carlos. > > (http://marc.info/?l=turbine-maven-dev&m=11739368

Re: in repo1 it is available

AFAIK this one is an experimental repository created by carlos. (http://marc.info/?l=turbine-maven-dev&m=117393683323837&w=2) 2007/11/26, Arnaud HERITIER <[EMAIL PROTECTED]>: > > ouch, I didn't notice. > It's a maven 2 repository but not the central one. > Carlos, Jason, do you know why the conte

Re: in repo1 it is available

ouch, I didn't notice. It's a maven 2 repository but not the central one. Carlos, Jason, do you know why the content of http://repo1.maven.org/eclipse/ isn't available in http://repo1.maven.org/maven2 ??