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

[Micah Hainline <mi...@asolutions.com>]

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

<groupId>org.eclipse.core</groupId>
<artifactId>org.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>
  <groupId>org.eclipse</groupId>
  <artifactId>ui</artifactId>
  <version>3.3.1</version>
</dependency>

<dependency>
  <groupId>org.eclipse.core</groupId>
  <artifactId>runtime</artifactId>
  <version>3.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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

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

[Micah Hainline <mi...@asolutions.com>]

> From: "Barrie Treloar" <ba...@gmail.com>
> 
> 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 

 <artifactId>org-eclipse-core-runtime</artifactId>

instead of 

 <artifactId>org.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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

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

[Barrie Treloar <ba...@gmail.com>]

On Wed, Apr 2, 2008 at 5:46 AM, Micah Hainline
<mi...@asolutions.com> 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:
>
>  <groupId>org.eclipse.core</groupId>
>  <artifactId>org.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>
>   <groupId>org.eclipse</groupId>
>   <artifactId>ui</artifactId>
>   <version>3.3.1</version>
>  </dependency>
>
>  <dependency>
>   <groupId>org.eclipse.core</groupId>
>   <artifactId>runtime</artifactId>
>   <version>3.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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org