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 mailing list Jason wrote: I've been busy but before anyone publishes anything I'll try to summarize the meeting we had at EclipseCon. In a nutshell the OSGi experts around the table like Peter Krien's, and Jeff McAffer agreed aligning the artifact id in Maven with the symbolic id is the way to go in the future. I'll do the summary some time this week. Nothing should be published until this agreed upon method is embodied in the tooling. That sounds like they've got that worked out then. Whether the groupId is org.eclipse or org.eclipse.xxx doesn't really matter as long as we're all using the same one, and the artifactId is correct. Thanks for the pointer Barrie. (p.s the Dash vs Dot is worse because as per the conflict resolution the name without the dash is newer, thus 3.2.2 is considered newer than 3.2.2-M2_20080803 and your build fails since it can't find a matching version in the range [3.2.2,4.0.0) Using the dashes in the version wasn't really what I was concerned about, I'd just be bummed if we ended up with artifactIdorg-eclipse-core-runtime/artifactId instead of artifactIdorg.eclipse.core.runtime/artifactId but it sounds like that isn't a concern any more. I'll wait patiently for Jason to write up the summary. Micah Hainline - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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, and it is a nice way to provide a sandbox in the repository in which to play. The artifactId is a nice way for the provider of the artifacts to identify their artifacts. I think that these two goals are still nicely fulfilled when we have something like the following: groupIdorg.eclipse.core/groupId artifactIdorg.eclipse.core.runtime/artifactId The artifact comes from the Eclipse Core project, and they happen to have have called it org.eclipse.core.runtime. Within maven we can use both of these pieces of information together in order to ensure a unique match, even though we could probably get away with just using the artifactId. I don't see how it hurts us to use both though. It will be a serious source of confusion to Eclipse plugin developers if we start telling them that in order to include the plugins org.eclipse.ui and org.eclipse.core.runtime in a pom.xml they need to write the following: dependency groupIdorg.eclipse/groupId artifactIdui/artifactId version3.3.1/version /dependency dependency groupIdorg.eclipse.core/groupId artifactIdruntime/artifactId version3.3.1/version /dependency And giving them artifactIds with dashes instead of periods just seems... spiteful. I mean, we have trouble enough just remembering which plugins we're trying to get, don't make us guess what to call them, or pull out a Maven Naming Conventions for Eclipse manual to figure it out. It seems like what we've got with eclipse:make-artifacts works pretty good, if we could all just agree on it. A two-segment id would work fine too, if folks have a preference for that. All that really matters is that we get some consistency. Micah Hainline 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 think we can live with long names. In this case i see no problem stripping the org from the artifactId so the id is: id=org.eclipse.core.eclipse-core-resources This way we can survive till the moment where there is only an id left and no more groupId or artifactId. Relocations can then be used for a smooth transition. So can we find a way to suit both sides? - keep the tools we have running and - move to a unique id Ritchie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 seems to me that the groupId serves quite well as an identifier for the source of an artifact, and it is a nice way to provide a sandbox in the repository in which to play. The artifactId is a nice way for the provider of the artifacts to identify their artifacts. I think that these two goals are still nicely fulfilled when we have something like the following: groupIdorg.eclipse.core/groupId artifactIdorg.eclipse.core.runtime/artifactId The artifact comes from the Eclipse Core project, and they happen to have have called it org.eclipse.core.runtime. Within maven we can use both of these pieces of information together in order to ensure a unique match, even though we could probably get away with just using the artifactId. I don't see how it hurts us to use both though. It will be a serious source of confusion to Eclipse plugin developers if we start telling them that in order to include the plugins org.eclipse.ui and org.eclipse.core.runtime in a pom.xml they need to write the following: dependency groupIdorg.eclipse/groupId artifactIdui/artifactId version3.3.1/version /dependency dependency groupIdorg.eclipse.core/groupId artifactIdruntime/artifactId version3.3.1/version /dependency And giving them artifactIds with dashes instead of periods just seems... spiteful. I mean, we have trouble enough just remembering which plugins we're trying to get, don't make us guess what to call them, or pull out a Maven Naming Conventions for Eclipse manual to figure it out. It seems like what we've got with eclipse:make-artifacts works pretty good, if we could all just agree on it. A two-segment id would work fine too, if folks have a preference for that. All that really matters is that we get some consistency. 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. (p.s the Dash vs Dot is worse because as per the conflict resolution the name without the dash is newer, thus 3.2.2 is considered newer than 3.2.2-M2_20080803 and your build fails since it can't find a matching version in the range [3.2.2,4.0.0) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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, Felix Knecht [EMAIL PROTECTED] wrote: 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 artifacts were deployed to were expected. Trying to use them later on I run into the following problem: Couldn't find a version in [3.3.0-v20070606-0010, 3.2.0-v20060605-1400, 3.3.0-v20070531-1300] to match range [3.3.0,4.0.0) org.eclipse:text:jar:null Doing some search about this I found a thread [1] saying that 3.3.0-xxx is less than 3.3.0 (what would explain my problems). Is this an issue of the match range checker or an issue of the pom.xml creation of the eclipse:to-maven goal? Thanks and regards Felix [1] http://www.nabble.com/OverConstrainedVersionException-td14289478s177.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 artifacts were deployed to were expected. Trying to use them later on I run into the following problem: Couldn't find a version in [3.3.0-v20070606-0010, 3.2.0-v20060605-1400, 3.3.0-v20070531-1300] to match range [3.3.0,4.0.0) org.eclipse:text:jar:null Doing some search about this I found a thread [1] saying that 3.3.0-xxx is less than 3.3.0 (what would explain my problems). Is this an issue of the match range checker or an issue of the pom.xml creation of the eclipse:to-maven goal? Thanks and regards Felix [1] http://www.nabble.com/OverConstrainedVersionException-td14289478s177.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 coming and hole bunches of backward compatibility stuff. One of the troubles i see coming for example in the maven-eclipse-plugin is convincing eclipse that a file reference to a jar in the local repository called resources.jar should be handled as if it is called org.eclipse.core.resources.jar. In some cases i know it is possible in others Could somebody (hint- Carlos Sanchez) write a page on the maven site about this discussion: about the naming of artifact's and the proper handling in bundling plugin's. So next time somebody (like me) asks a question that breaks lose a discussion, we can point the page for the arguments. It can also be used as a reference for jira tasks in the various bundling plugins so that all have the same handling, share the same (activation) parameter names and share the same backward compatibility handling. Then with version 2.x.x of maven the default can be switched to the correct handling. Ritchie Carlos Sanchez wrote: 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 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 programmatic mapping which increases the severity of this breakage? it doesnt increase anything, you were not using eclipse artifacts before, because they were not in the repo it's most likely that you will use the eclipse bundles for osgi development than for webapp, so it's worse to accommodate the broken war plugin than break the osgi plugins 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 On Nov 28, 2007 9:14 PM, nicolas de loof [EMAIL PROTECTED] wrote: 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 workaround. Nico. 2007/11/28, Carlos Sanchez [EMAIL PROTECTED]: 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 limitations. What happens now if you have 2 jars with same artifactId and version in a war? they overwrite each other This would be great in an ideal world. Lets consider the required changes : - war plugin to create required WEB-INF/lib - jar/ear/ejb plugin to create the correct MANIFEST entries - assembly plugin to bundle dependencies Adn now, consider how many builds could be broken by such changes... for those plugins it can be an option, doesnt need to be the default right away. What i'm saying is that it's the path forward and new stuff like the eclipse bundles need to be aware of it. The OSGi tools, like felix bundle plugin already compose the bundle symbolic name with group+artifact. in any case those plugins are already broken if there are two artifacts with same artifactid and version (eg util-1.0.jar) Now imagine that the eclipse plugins get the name from the artifactId only, what about the thousands of artifacts that are already in the repo? org.apache.commons-logging/commons-logging should be commons-logging in an osgi bundle or org.apache.commons-logging??? -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 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 only
top-level-projects are used as group-id's. Or (to keep it simple) just
use the first three words as a groupId
this way the jar should be:
groupIdorg.eclipse.platform/groupId
artefactIdorg-eclipse-core-resources/artefactId
version3.2.1/version
or
groupIdorg.eclipse.platform.core/groupId
artefactIdorg-eclipse-core-resources/artefactId
version3.2.1/version
or
groupIdorg.eclipse.core/groupId
artefactIdorg-eclipse-core-resources/artefactId
version3.2.1/version
any other idea's...
Ritchie
Max Bowsher wrote:
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 wonder if this groupId:artifactId mapping is a bad idea?
Most jars in the repository have an artifactId which is, whilst not
necessarily globally unique, good enough to give you a pretty good idea
what they are. This is a good thing, since there are several use cases
where a collection of jars is bundled into a single directory, and those
jars are named {artifactId}-{version}.jar (e.g, war file WEB-INF/lib/,
common usage of assembly plugin).
The suggested mapping of just taking the last component of the name as
the artifactId will lead to many artifacts with non-descriptive and
clashing names like common, core, ui, etc. At best case, this
will merely be horrendously confusing for humans attempting to
understand and debug these generated collections of jars. At worst case,
some of the artifacts will not only have the same artifactId, but same
version too, and will overwrite each other.
So, I think the current mapping fits poorly with existing Maven
use-cases and plugin design, and needs further consideration.
Max.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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, standalone tool). What would
the resulting MANIFEST.MF look like.
Sorry to reopen this discussion, but i think a jar's name should be as
near as possible to the original jar name.
It is done all the time, example:
maven-eclipse-plugin is not called eclipse because the groupId
contains maven and plugin.
Ritchie
Carlos Sanchez wrote:
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 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 only
top-level-projects are used as group-id's. Or (to keep it simple) just
use the first three words as a groupId
this way the jar should be:
groupIdorg.eclipse.platform/groupId
artefactIdorg-eclipse-core-resources/artefactId
version3.2.1/version
or
groupIdorg.eclipse.platform.core/groupId
artefactIdorg-eclipse-core-resources/artefactId
version3.2.1/version
or
groupIdorg.eclipse.core/groupId
artefactIdorg-eclipse-core-resources/artefactId
version3.2.1/version
any other idea's...
Ritchie
Max Bowsher wrote:
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 wonder if this groupId:artifactId mapping is a bad idea?
Most jars in the repository have an artifactId which is, whilst not
necessarily globally unique, good enough to give you a pretty good idea
what they are. This is a good thing, since there are several use cases
where a collection of jars is bundled into a single directory, and those
jars are named {artifactId}-{version}.jar (e.g, war file WEB-INF/lib/,
common usage of assembly plugin).
The suggested mapping of just taking the last component of the name as
the artifactId will lead to many artifacts with non-descriptive and
clashing names like common, core, ui, etc. At best case, this
will merely be horrendously confusing for humans attempting to
understand and debug these generated collections of jars. At worst case,
some of the artifacts will not only have the same artifactId, but same
version too, and will overwrite each other.
So, I think the current mapping fits poorly with existing Maven
use-cases and plugin design, and needs further consideration.
Max.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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 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, standalone tool). What would
the resulting MANIFEST.MF look like.
Sorry to reopen this discussion, but i think a jar's name should be as
near as possible to the original jar name.
It is done all the time, example:
maven-eclipse-plugin is not called eclipse because the groupId
contains maven and plugin.
Ritchie
Carlos Sanchez wrote:
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 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 only
top-level-projects are used as group-id's. Or (to keep it simple) just
use the first three words as a groupId
this way the jar should be:
groupIdorg.eclipse.platform/groupId
artefactIdorg-eclipse-core-resources/artefactId
version3.2.1/version
or
groupIdorg.eclipse.platform.core/groupId
artefactIdorg-eclipse-core-resources/artefactId
version3.2.1/version
or
groupIdorg.eclipse.core/groupId
artefactIdorg-eclipse-core-resources/artefactId
version3.2.1/version
any other idea's...
Ritchie
Max Bowsher wrote:
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 wonder if this groupId:artifactId mapping is a bad idea?
Most jars in the repository have an artifactId which is, whilst not
necessarily globally unique, good enough to give you a pretty good
idea
what they are. This is a good thing, since there are several use cases
where a collection of jars is bundled into a single directory, and
those
jars are named {artifactId}-{version}.jar (e.g, war file WEB-INF/lib/,
common usage of assembly plugin).
The suggested mapping of just taking the last component of the name as
the artifactId will lead to many artifacts with non-descriptive and
clashing names like common, core, ui, etc. At best case, this
will merely be horrendously confusing for humans attempting to
understand and debug these generated collections of jars. At worst
case,
some of the artifacts will not only have the same artifactId, but
same
version too, and will overwrite each other.
So, I think the current mapping fits poorly with existing Maven
use-cases and plugin design, and needs further consideration.
Max.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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 what would happen when you need to package
the jars together in a directory (ear, war, standalone tool). What would
the resulting MANIFEST.MF look like.
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 limitations. What happens now if you have 2 jars
with same artifactId and version in a war? they overwrite each other
Sorry to reopen this discussion, but i think a jar's name should be as
near as possible to the original jar name.
It is done all the time, example:
maven-eclipse-plugin is not called eclipse because the groupId
contains maven and plugin.
but i think if groupid is org.apache.maven.plugins then the artifact
should be just eclipse. Doesnt happen now, but it probably should
Ritchie
Carlos Sanchez wrote:
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 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 only
top-level-projects are used as group-id's. Or (to keep it simple) just
use the first three words as a groupId
this way the jar should be:
groupIdorg.eclipse.platform/groupId
artefactIdorg-eclipse-core-resources/artefactId
version3.2.1/version
or
groupIdorg.eclipse.platform.core/groupId
artefactIdorg-eclipse-core-resources/artefactId
version3.2.1/version
or
groupIdorg.eclipse.core/groupId
artefactIdorg-eclipse-core-resources/artefactId
version3.2.1/version
any other idea's...
Ritchie
Max Bowsher wrote:
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 wonder if this groupId:artifactId mapping is a bad idea?
Most jars in the repository have an artifactId which is, whilst not
necessarily globally unique, good enough to give you a pretty good idea
what they are. This is a good thing, since there are several use cases
where a collection of jars is bundled into a single directory, and those
jars are named {artifactId}-{version}.jar (e.g, war file WEB-INF/lib/,
common usage of assembly plugin).
The suggested mapping of just taking the last component of the name as
the artifactId will lead to many artifacts with non-descriptive and
clashing names like common, core, ui, etc. At best case, this
will merely be horrendously confusing for humans attempting to
understand and debug these generated collections of jars. At worst case,
some of the artifacts will not only have the same artifactId, but same
version too, and will overwrite each other.
So, I think the current mapping fits poorly with existing Maven
use-cases and plugin design, and needs further consideration.
Max.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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.
Ritchie
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
called resource.jar. And what would happen when you need to package
the jars together in a directory (ear, war, standalone tool). What would
the resulting MANIFEST.MF look like.
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 limitations. What happens now if you have 2 jars
with same artifactId and version in a war? they overwrite each other
Sorry to reopen this discussion, but i think a jar's name should be as
near as possible to the original jar name.
It is done all the time, example:
maven-eclipse-plugin is not called eclipse because the groupId
contains maven and plugin.
but i think if groupid is org.apache.maven.plugins then the artifact
should be just eclipse. Doesnt happen now, but it probably should
Ritchie
Carlos Sanchez wrote:
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 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 only
top-level-projects are used as group-id's. Or (to keep it simple) just
use the first three words as a groupId
this way the jar should be:
groupIdorg.eclipse.platform/groupId
artefactIdorg-eclipse-core-resources/artefactId
version3.2.1/version
or
groupIdorg.eclipse.platform.core/groupId
artefactIdorg-eclipse-core-resources/artefactId
version3.2.1/version
or
groupIdorg.eclipse.core/groupId
artefactIdorg-eclipse-core-resources/artefactId
version3.2.1/version
any other idea's...
Ritchie
Max Bowsher wrote:
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 wonder if this groupId:artifactId mapping is a bad idea?
Most jars in the repository have an artifactId which is, whilst not
necessarily globally unique, good enough to give you a pretty good idea
what they are. This is a good thing, since there are several use cases
where a collection of jars is bundled into a single directory, and those
jars are named {artifactId}-{version}.jar (e.g, war file WEB-INF/lib/,
common usage of assembly plugin).
The suggested mapping of just taking the last component of the name as
the artifactId will lead to many artifacts with non-descriptive and
clashing names like common, core, ui, etc. At best case, this
will merely be horrendously confusing for humans attempting to
understand and debug these generated collections of jars. At worst case,
some of the artifacts will not only have the same artifactId, but same
version too, and will overwrite each other.
So, I think the current mapping fits poorly with existing Maven
use-cases and plugin design, and needs further consideration.
Max.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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 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, standalone tool). What would the resulting MANIFEST.MF look like. 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 limitations. What happens now if you have 2 jars with same artifactId and version in a war? they overwrite each other This would be great in an ideal world. Lets consider the required changes : - war plugin to create required WEB-INF/lib - jar/ear/ejb plugin to create the correct MANIFEST entries - assembly plugin to bundle dependencies Adn now, consider how many builds could be broken by such changes...
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 called resource.jar. And what would happen when you need to package the jars together in a directory (ear, war, standalone tool). What would the resulting MANIFEST.MF look like. 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 limitations. What happens now if you have 2 jars with same artifactId and version in a war? they overwrite each other That might make a lot of sense for the future, but it really isn't the current state of plugins and people's general expectations. For that reason, I submit that it would be a mistake to add a large collection of jars to the central repository in a way highly likely to cause confusion and name clashes. I have to say that there's a certain pleasant simplicity to using plain artifactId names - it's certainly vastly easier to look at a lib directory and quickly understand what's in there. In the vast majority of projects there will be no clash at all, given the current tendencies of choosing artifactIds. I'd even go so far to suggest that a sort of ad-hoc standard has grown up of choosing an artifactId of what the originating project would reasonably call the jar in the absence of Maven (subject to conventionally allowed characters), and then prepending a suitable groupId to ensure global uniqueness. If those rules are followed then org.eclipse.core.resources_3.3.0.whatever.jar does quite reasonably map to artifactId=org-eclipse-core-resources, groupId=org.eclipse.core. Max. signature.asc Description: OpenPGP digital signature
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 limitations. What happens now if you have 2 jars with same artifactId and version in a war? they overwrite each other This would be great in an ideal world. Lets consider the required changes : - war plugin to create required WEB-INF/lib - jar/ear/ejb plugin to create the correct MANIFEST entries - assembly plugin to bundle dependencies Adn now, consider how many builds could be broken by such changes... for those plugins it can be an option, doesnt need to be the default right away. What i'm saying is that it's the path forward and new stuff like the eclipse bundles need to be aware of it. The OSGi tools, like felix bundle plugin already compose the bundle symbolic name with group+artifact. in any case those plugins are already broken if there are two artifacts with same artifactid and version (eg util-1.0.jar) Now imagine that the eclipse plugins get the name from the artifactId only, what about the thousands of artifacts that are already in the repo? org.apache.commons-logging/commons-logging should be commons-logging in an osgi bundle or org.apache.commons-logging??? -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 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 called resource.jar. And what would happen when you need to package the jars together in a directory (ear, war, standalone tool). What would the resulting MANIFEST.MF look like. 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 limitations. What happens now if you have 2 jars with same artifactId and version in a war? they overwrite each other That might make a lot of sense for the future, but it really isn't the current state of plugins and people's general expectations. For that reason, I submit that it would be a mistake to add a large collection of jars to the central repository in a way highly likely to cause confusion and name clashes. I have to say that there's a certain pleasant simplicity to using plain artifactId names - it's certainly vastly easier to look at a lib directory and quickly understand what's in there. In the vast majority of projects there will be no clash at all, given the current tendencies of choosing artifactIds. I'd even go so far to suggest that a sort of ad-hoc standard has grown up of choosing an artifactId of what the originating project would reasonably call the jar in the absence of Maven (subject to conventionally allowed characters), and then prepending a suitable groupId to ensure global uniqueness. If those rules are followed then org.eclipse.core.resources_3.3.0.whatever.jar does quite reasonably map to artifactId=org-eclipse-core-resources, groupId=org.eclipse.core. Max. -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 state where artifactId *can* be used as a unique id in _most_ circumstances, and tools have grown to rely on that (war, assembly plugins etc.), so it's perhaps not such a good idea to change the repository so that is no longer true. A somewhat tangential idea just occurred to me: If the desired future direction _does_ turn out to be that groupId and artifactId be considered irrelevant apart from each other, would it make sense for a future version of maven to simply have a POM syntax like this:? dependency idorg.eclipse.core.resources/id version3.2.1/version /dependency Or, to put the question another way, is there any conceptual difference between groupId and artifactId that suggests org.eclipse.core.resources should map as groupId=org.eclipse.core artifactId=resources, rather than groupId=org.eclipse artifactId=core.resources ? Max. signature.asc Description: OpenPGP digital signature
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 only for Maven users My point is that the repository is currently in a state where artifactId *can* be used as a unique id in _most_ circumstances, and tools have grown to rely on that (war, assembly plugins etc.), so it's perhaps not such a good idea to change the repository so that is no longer true. we are NOT changing the repository. We are adding stuff to the repository, and if everybody lived until now without it, I don't anticipate a big problem on having it using the *same* layout as the rest, which is, to compose an id you need both groupId+artifactId Tools dont rely on just artifactId, maven doesn't, it just happens that most of the people don't hit that bug, coincidence A somewhat tangential idea just occurred to me: If the desired future direction _does_ turn out to be that groupId and artifactId be considered irrelevant apart from each other, would it make sense for a future version of maven to simply have a POM syntax like this:? dependency idorg.eclipse.core.resources/id version3.2.1/version /dependency Or, to put the question another way, is there any conceptual difference between groupId and artifactId that suggests org.eclipse.core.resources should map as groupId=org.eclipse.core artifactId=resources, rather than groupId=org.eclipse artifactId=core.resources ? Maven resolution takes into account groupId+artifactId, whether you call it id or anything else it's an historical reason I guess. Groups are supposed to split the repo in the same way as domain names do. If you own org.eclipse I don't care if you put it in org.eclipse.x or org.eclipse.y, it's your problem. What we are talking here is about a way to automatically map osgi bundle ids to group/artifact ids, and I'm not going to be the one manually choosing what should be the group and artifact as then we'd never have the eclipse plugins in the repo Max. -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 think we can live with long names. In this case i see no problem stripping the org from the artifactId so the id is: id=org.eclipse.core.eclipse-core-resources This way we can survive till the moment where there is only an id left and no more groupId or artifactId. Relocations can then be used for a smooth transition. So can we find a way to suit both sides? - keep the tools we have running and - move to a unique id Ritchie 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 On Nov 28, 2007 7:51 PM, Max Bowsher [EMAIL PROTECTED] wrote: 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 called resource.jar. And what would happen when you need to package the jars together in a directory (ear, war, standalone tool). What would the resulting MANIFEST.MF look like. 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 limitations. What happens now if you have 2 jars with same artifactId and version in a war? they overwrite each other That might make a lot of sense for the future, but it really isn't the current state of plugins and people's general expectations. For that reason, I submit that it would be a mistake to add a large collection of jars to the central repository in a way highly likely to cause confusion and name clashes. I have to say that there's a certain pleasant simplicity to using plain artifactId names - it's certainly vastly easier to look at a lib directory and quickly understand what's in there. In the vast majority of projects there will be no clash at all, given the current tendencies of choosing artifactIds. I'd even go so far to suggest that a sort of ad-hoc standard has grown up of choosing an artifactId of what the originating project would reasonably call the jar in the absence of Maven (subject to conventionally allowed characters), and then prepending a suitable groupId to ensure global uniqueness. If those rules are followed then org.eclipse.core.resources_3.3.0.whatever.jar does quite reasonably map to artifactId=org-eclipse-core-resources, groupId=org.eclipse.core. Max. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 that the repository is not only for Maven users My point is that the repository is currently in a state where artifactId *can* be used as a unique id in _most_ circumstances, and tools have grown to rely on that (war, assembly plugins etc.), so it's perhaps not such a good idea to change the repository so that is no longer true. we are NOT changing the repository. We are adding stuff to the repository, and if everybody lived until now without it, I don't anticipate a big problem on having it using the *same* layout as the rest, which is, to compose an id you need both groupId+artifactId Tools dont rely on just artifactId, maven doesn't, it just happens that most of the people don't hit that bug, coincidence How can you say tools don't rely on just artifactId (being unique)? That's exactly what the default functioning of the war-plugin's lib directory creation, the jar-plugin's manifest Class-Path generation, the assembly-plugin's dependencySet function, and presumably others rely on. I agree that we're not suggesting changing anything existing in the repository, but we are discussing adding a large number of artifacts which would weaken the principle of artifactId is almost always unique to artifactId can't really be considered unique at all, changing a concept of the repository as a whole. A somewhat tangential idea just occurred to me: If the desired future direction _does_ turn out to be that groupId and artifactId be considered irrelevant apart from each other, would it make sense for a future version of maven to simply have a POM syntax like this:? dependency idorg.eclipse.core.resources/id version3.2.1/version /dependency Or, to put the question another way, is there any conceptual difference between groupId and artifactId that suggests org.eclipse.core.resources should map as groupId=org.eclipse.core artifactId=resources, rather than groupId=org.eclipse artifactId=core.resources ? Maven resolution takes into account groupId+artifactId, whether you call it id or anything else it's an historical reason I guess. Groups are supposed to split the repo in the same way as domain names do. If you own org.eclipse I don't care if you put it in org.eclipse.x or org.eclipse.y, it's your problem. What we are talking here is about a way to automatically map osgi bundle ids to group/artifact ids, and I'm not going to be the one manually choosing what should be the group and artifact as then we'd never have the eclipse plugins in the repo I understand: OSGi bundle ids *must* be programmatically mappable to groupId/artifactId. I totally agree that tools which rely on artifactId-uniqueness are technically broken, but is it right to choose a programmatic mapping which increases the severity of this breakage? Max. signature.asc Description: OpenPGP digital signature
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 workaround. Nico. 2007/11/28, Carlos Sanchez [EMAIL PROTECTED]: 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 limitations. What happens now if you have 2 jars with same artifactId and version in a war? they overwrite each other This would be great in an ideal world. Lets consider the required changes : - war plugin to create required WEB-INF/lib - jar/ear/ejb plugin to create the correct MANIFEST entries - assembly plugin to bundle dependencies Adn now, consider how many builds could be broken by such changes... for those plugins it can be an option, doesnt need to be the default right away. What i'm saying is that it's the path forward and new stuff like the eclipse bundles need to be aware of it. The OSGi tools, like felix bundle plugin already compose the bundle symbolic name with group+artifact. in any case those plugins are already broken if there are two artifacts with same artifactid and version (eg util-1.0.jar) Now imagine that the eclipse plugins get the name from the artifactId only, what about the thousands of artifacts that are already in the repo? org.apache.commons-logging/commons-logging should be commons-logging in an osgi bundle or org.apache.commons-logging??? -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 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 programmatic mapping which increases the severity of this breakage? it doesnt increase anything, you were not using eclipse artifacts before, because they were not in the repo it's most likely that you will use the eclipse bundles for osgi development than for webapp, so it's worse to accommodate the broken war plugin than break the osgi plugins 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 On Nov 28, 2007 9:14 PM, nicolas de loof [EMAIL PROTECTED] wrote: 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 workaround. Nico. 2007/11/28, Carlos Sanchez [EMAIL PROTECTED]: 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 limitations. What happens now if you have 2 jars with same artifactId and version in a war? they overwrite each other This would be great in an ideal world. Lets consider the required changes : - war plugin to create required WEB-INF/lib - jar/ear/ejb plugin to create the correct MANIFEST entries - assembly plugin to bundle dependencies Adn now, consider how many builds could be broken by such changes... for those plugins it can be an option, doesnt need to be the default right away. What i'm saying is that it's the path forward and new stuff like the eclipse bundles need to be aware of it. The OSGi tools, like felix bundle plugin already compose the bundle symbolic name with group+artifact. in any case those plugins are already broken if there are two artifacts with same artifactid and version (eg util-1.0.jar) Now imagine that the eclipse plugins get the name from the artifactId only, what about the thousands of artifacts that are already in the repo? org.apache.commons-logging/commons-logging should be commons-logging in an osgi bundle or org.apache.commons-logging??? -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 programmatic mapping which increases the severity of this breakage? it doesnt increase anything, you were not using eclipse artifacts before, because they were not in the repo it's most likely that you will use the eclipse bundles for osgi development than for webapp, so it's worse to accommodate the broken war plugin than break the osgi plugins 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 On Nov 28, 2007 9:14 PM, nicolas de loof [EMAIL PROTECTED] wrote: 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 workaround. Nico. 2007/11/28, Carlos Sanchez [EMAIL PROTECTED]: 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 limitations. What happens now if you have 2 jars with same artifactId and version in a war? they overwrite each other This would be great in an ideal world. Lets consider the required changes : - war plugin to create required WEB-INF/lib - jar/ear/ejb plugin to create the correct MANIFEST entries - assembly plugin to bundle dependencies Adn now, consider how many builds could be broken by such changes... for those plugins it can be an option, doesnt need to be the default right away. What i'm saying is that it's the path forward and new stuff like the eclipse bundles need to be aware of it. The OSGi tools, like felix bundle plugin already compose the bundle symbolic name with group+artifact. in any case those plugins are already broken if there are two artifacts with same artifactid and version (eg util-1.0.jar) Now imagine that the eclipse plugins get the name from the artifactId only, what about the thousands of artifacts that are already in the repo? org.apache.commons-logging/commons-logging should be commons-logging in an osgi bundle or org.apache.commons-logging??? -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 *.*.resources.jar does oh, and btw the war plugin already uses the groupId when in conflict :) http://jira.codehaus.org/browse/MWAR-19http://jira.codehaus.org/browse/MWAR-19 I was not aware of this feature.
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 [EMAIL PROTECTED] wrote: 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 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, 2007 4:15 PM, Carlos Sanchez [EMAIL PROTECTED] wrote: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 wonder if this groupId:artifactId mapping is a bad idea?
Most jars in the repository have an artifactId which is, whilst not
necessarily globally unique, good enough to give you a pretty good idea
what they are. This is a good thing, since there are several use cases
where a collection of jars is bundled into a single directory, and those
jars are named {artifactId}-{version}.jar (e.g, war file WEB-INF/lib/,
common usage of assembly plugin).
The suggested mapping of just taking the last component of the name as
the artifactId will lead to many artifacts with non-descriptive and
clashing names like common, core, ui, etc. At best case, this
will merely be horrendously confusing for humans attempting to
understand and debug these generated collections of jars. At worst case,
some of the artifacts will not only have the same artifactId, but same
version too, and will overwrite each other.
So, I think the current mapping fits poorly with existing Maven
use-cases and plugin design, and needs further consideration.
Max.
signature.asc
Description: OpenPGP digital signature
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 only
top-level-projects are used as group-id's. Or (to keep it simple) just
use the first three words as a groupId
this way the jar should be:
groupIdorg.eclipse.platform/groupId
artefactIdorg-eclipse-core-resources/artefactId
version3.2.1/version
or
groupIdorg.eclipse.platform.core/groupId
artefactIdorg-eclipse-core-resources/artefactId
version3.2.1/version
or
groupIdorg.eclipse.core/groupId
artefactIdorg-eclipse-core-resources/artefactId
version3.2.1/version
any other idea's...
Ritchie
Max Bowsher wrote:
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 wonder if this groupId:artifactId mapping is a bad idea?
Most jars in the repository have an artifactId which is, whilst not
necessarily globally unique, good enough to give you a pretty good idea
what they are. This is a good thing, since there are several use cases
where a collection of jars is bundled into a single directory, and those
jars are named {artifactId}-{version}.jar (e.g, war file WEB-INF/lib/,
common usage of assembly plugin).
The suggested mapping of just taking the last component of the name as
the artifactId will lead to many artifacts with non-descriptive and
clashing names like common, core, ui, etc. At best case, this
will merely be horrendously confusing for humans attempting to
understand and debug these generated collections of jars. At worst case,
some of the artifacts will not only have the same artifactId, but same
version too, and will overwrite each other.
So, I think the current mapping fits poorly with existing Maven
use-cases and plugin design, and needs further consideration.
Max.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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/ http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/isn't available in http://repo1.maven.org/maven2 ??http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/ Arnaud On Nov 26, 2007 1:57 PM, Richard van Nieuwenhoven [EMAIL PROTECTED] wrote: just that it is not the maven2 central repository. It is the maven1 repository or is that wrong / or a problem? Ritchie Arnaud HERITIER wrote: Ok, it's cool. Thus we just have to add the dependency (with all excludes ...) The jar is here, thus we don't need to request an upload. http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/ Arnaud On Nov 26, 2007 1:51 PM, Richard van Nieuwenhoven [EMAIL PROTECTED] wrote: Hi, in the repo1 repository it is available! http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/org.eclipse.core.resources-3.2.1.pom (the needed code did not change in 3.3) just be sure to exclude all deeper dependencies! anyway, now you have the data needed for the upload request. regards, Ritchie -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ...
Re: in repo1 it is available
AFAIK this one is an experimental repository created by carlos. (http://marc.info/?l=turbine-maven-devm=117393683323837w=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 content of http://repo1.maven.org/eclipse/ http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/ isn't available in http://repo1.maven.org/maven2 ?? http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/ Arnaud On Nov 26, 2007 1:57 PM, Richard van Nieuwenhoven [EMAIL PROTECTED] wrote: just that it is not the maven2 central repository. It is the maven1 repository or is that wrong / or a problem? Ritchie Arnaud HERITIER wrote: Ok, it's cool. Thus we just have to add the dependency (with all excludes ...) The jar is here, thus we don't need to request an upload. http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/ Arnaud On Nov 26, 2007 1:51 PM, Richard van Nieuwenhoven [EMAIL PROTECTED] wrote: Hi, in the repo1 repository it is available! http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/org.eclipse.core.resources-3.2.1.pom (the needed code did not change in 3.3) just be sure to exclude all deeper dependencies! anyway, now you have the data needed for the upload request. regards, Ritchie -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ...
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-devm=117393683323837w=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 content of http://repo1.maven.org/eclipse/ http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/ isn't available in http://repo1.maven.org/maven2 ?? http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/ Arnaud On Nov 26, 2007 1:57 PM, Richard van Nieuwenhoven [EMAIL PROTECTED] wrote: just that it is not the maven2 central repository. It is the maven1 repository or is that wrong / or a problem? Ritchie Arnaud HERITIER wrote: Ok, it's cool. Thus we just have to add the dependency (with all excludes ...) The jar is here, thus we don't need to request an upload. http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/ Arnaud On Nov 26, 2007 1:51 PM, Richard van Nieuwenhoven [EMAIL PROTECTED] wrote: Hi, in the repo1 repository it is available! http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/org.eclipse.core.resources-3.2.1.pom (the needed code did not change in 3.3) just be sure to exclude all deeper dependencies! anyway, now you have the data needed for the upload request. regards, Ritchie -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 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-devm=117393683323837w=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 content of http://repo1.maven.org/eclipse/ http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/ isn't available in http://repo1.maven.org/maven2 ?? http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/ Arnaud On Nov 26, 2007 1:57 PM, Richard van Nieuwenhoven [EMAIL PROTECTED] wrote: just that it is not the maven2 central repository. It is the maven1 repository or is that wrong / or a problem? Ritchie Arnaud HERITIER wrote: Ok, it's cool. Thus we just have to add the dependency (with all excludes ...) The jar is here, thus we don't need to request an upload. http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/ Arnaud On Nov 26, 2007 1:51 PM, Richard van Nieuwenhoven [EMAIL PROTECTED] wrote: Hi, in the repo1 repository it is available! http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/org.eclipse.core.resources-3.2.1.pom (the needed code did not change in 3.3) just be sure to exclude all deeper dependencies! anyway, now you have the data needed for the upload request. regards, Ritchie -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 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-devm=117393683323837w=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 content of http://repo1.maven.org/eclipse/ http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/ isn't available in http://repo1.maven.org/maven2 ?? http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/ Arnaud On Nov 26, 2007 1:57 PM, Richard van Nieuwenhoven [EMAIL PROTECTED] wrote: just that it is not the maven2 central repository. It is the maven1 repository or is that wrong / or a problem? Ritchie Arnaud HERITIER wrote: Ok, it's cool. Thus we just have to add the dependency (with all excludes ...) The jar is here, thus we don't need to request an upload. http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/ Arnaud On Nov 26, 2007 1:51 PM, Richard van Nieuwenhoven [EMAIL PROTECTED] wrote: Hi, in the repo1 repository it is available! http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/org.eclipse.core.resources-3.2.1.pom (the needed code did not change in 3.3) just be sure to exclude all deeper dependencies! anyway, now you have the data needed for the upload request. regards, Ritchie -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ...
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 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 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-devm=117393683323837w=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 content of http://repo1.maven.org/eclipse/ http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/ isn't available in http://repo1.maven.org/maven2 ?? http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/ Arnaud On Nov 26, 2007 1:57 PM, Richard van Nieuwenhoven [EMAIL PROTECTED] wrote: just that it is not the maven2 central repository. It is the maven1 repository or is that wrong / or a problem? Ritchie Arnaud HERITIER wrote: Ok, it's cool. Thus we just have to add the dependency (with all excludes ...) The jar is here, thus we don't need to request an upload. http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/ Arnaud On Nov 26, 2007 1:51 PM, Richard van Nieuwenhoven [EMAIL PROTECTED] wrote: Hi, in the repo1 repository it is available! http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/org.eclipse.core.resources-3.2.1.pom (the needed code did not change in 3.3) just be sure to exclude all deeper dependencies! anyway, now you have the data needed for the upload request. regards, Ritchie -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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, 2007 4:15 PM, Carlos Sanchez [EMAIL PROTECTED] wrote: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 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, 2007 4:15 PM, Carlos Sanchez [EMAIL PROTECTED] wrote: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ...
