Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] [Maven/Tycho] Suggested groupId

From the bug:

At EclipseCon a while back we decided the best thing to do would be to use
"org.eclipse" for the groupId of all artifacts coming from proper.
I recommend following that best practice. You're free to go your own way.

On Wed, Nov 10, 2010 at 11:06, Jesse McConnell <jesse.mcconnell@xxxxxxxxx> wrote:
If there is a compelling reason to change the status quo then people
will slowly but surely align to the mutually beneficial approach.

What I don't see is the compelling reason at this point for jetty...We
have two requirements..

1) artifacts that are unsigned and available in maven central
2) artifacts that are signed and available from a p2 repository

Even if I started pushing internally signed artifacts to maven central
it changes nothing in my requirements to have a p2 repository from an url from which all signed eclipse bytes must come from.
Thankfully tycho is removing vast amounts of pain related to the
second item.

Now...if you said that eclipse were to allow artifacts to come from
maven central and be used in official eclipse builds we are starting
to get into the realm of compelling reasons...If all of Orbit were to
exist in maven central and be usable....we are getting somewhere.  As
it stands now if you want to produce something officially eclipse you
can't touch maven central for dependencies, you have to operate
completely from within eclipse infrastructure.  If its not in Orbit
you have to handle all of that overhead to walk something through
CQ's, either do the magic to get it into orbit or get someone else to
do it...track down what I, S, [W]hatever orbit build your dependency
is within, update some poms to reference those URL's and then tycho
makes life easier again.

Now don't get me wrong, I understand all the reasons we do that from
the eclipse foundation perspective and it makes good sense.  Perhaps
what I question is what sense it makes to push the eclipse signing and
naming conventions into maven repositories if there is little to no
future of eclipse ever consuming from maven central.  I totally
support the idea of eclipse projects pushing their artifacts into
maven central to appeal to that large community but I question if that
large community is concerned about the same things the eclipse
foundation is concerned about with regards to the signing, packing,
etc of bundles/artifacts.  If they are going to consume osgi goodies,
let them consume from eclipse p2 repositories and if they are going to
consume it in standard maven classloader scenarios let them pull from
maven central and if that last is the case...let them address things
as they normally would and are used to with maven.

All that being said, I am completely open to compelling reasons to change.


jesse mcconnell

On Wed, Nov 10, 2010 at 12:28, Stephan Herrmann <stephan@xxxxxxxxxxxxxxx> wrote:
> On Wednesday, November 10, 2010 06:49:13 pm Jesse McConnell wrote:
>> normal people use org.eclipse.<project> as the groupId and an
>> artifactId of something like jetty-server
>> anything other then that is not following normal maven conventions...
> sounds good to me, but ...
>> that being said there has been discussion about using that
>> org.eclipse:org.eclipse.jetty.jetty-server:<version> notation to allow
>> for reverse mappings to bundles...
> The last part seems to refer to statements like Jason's in
> E.g.,
>  "org.eclipse.<project> Would definitely not be better. We've already discussed
>  this at length and having a 1:1 mapping of artifactId to symbolic bundle name
>  is the only way we can deterministically map between the two systems. Take a
>  non-constant groupId and you can't correctly determine the symbolic bundle
>  name."
> Is anybody inclined to resolve this conflict, or will every project just do as it pleases?
> best,
> Stephan
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
cross-project-issues-dev mailing list

Back to the top