Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orbit-dev] Discussion on coordinates for uploading of approved artifacts

> From: "Gunnar Wagenknecht" <gunnar@xxxxxxxxxxxxxxx>
> The only argument I've seen so far for same GAV is people not willing to
> touch there POMs for IP approved libraries. But then I'm wondering ... do we
> actually have to manually mirror artifacts from Maven Central in this IP
> blessed repo? If it's for the sake of independence, i.e. not relying on
> external sources during build, then a full central mirror already
> accomplishes that.
> Thus, I think we shouldn't have a problem with libraries of same GAV. They
> would simply be consumed from the central mirror as they are today.

Yes, I agree here. We don't want to be mirroring artifacts yet again into
this new repository.


> So this leaves us with these two variants:
> - modified Maven libraries (eg., subset or patched)
> - non Maven hosted libraries
> 
> I think in both cases we want different GAVs. In the first case to identify
> modified content, and in the second to express that we provide Maven
> artifacts but not the originator.
> 
> For Orbit bundles the policy mandates that every modified bundle must use the
> org.eclipse.orbit namespace.
> https://wiki.eclipse.org/Bundle_Naming
> 
> Option 2 is the preferred one: org.eclipse.orbit + originator simple name.
> Option 3 was found too excessive.
> 
> I propose that we apply option 2 from bundle naming policy to the Maven group
> ids. Where applicable, the originator simple name can be used to provide
> further grouping (eg., httpcomponents).

That sounds reasonable, and addresses Erwin's concern about it being rather
confusing to find artifacts if everything is grouped as "org.eclipse.orbit".


> From: "erwindl0" <erwindl0@xxxxxxxxx>
> About your questions, my 2 cents :
> - I think it would make sense to "specialize" the group name, in the
> case of modified artifacts.
> Besides the argument in the bug comments I see another benefit for this :
> A single "org.eclipse.orbit" group to contain everything could lead to a
> very large set of artifacts in there, which may difficult to use/navigate.
> Consider e.g. a case similar to httpcomponents, which groups a number of
> related binary artifacts.
> I think it would be best not to lose the org.apache.httpcomponents
> (sub)grouping when migrating these artifacts in the orbit repo.
> Whether or not "org.eclipse.orbit" must be part of every group name, I'm
> not sure.

I think Gunnar's suggestion (Option 2) will satisfy what you suggest.
Basically "org.eclipse.orbit.httpcomponents" for the groupId.


> The repo seems to be already orbit-reserved, so I guess the group names
> don't need an extra reference to orbit.
> And if the only/main user of that repo is Orbit itself and our bundle
> recipes, that should be OK I guess?
> If the intention is to also allow others to use that repo, mixed in with
> maybe other repos (like maven central?) to find their dependencies, it
> may be good to have globally unique group names (e.g. by including
> org.eclipse.orbit)?

The maven artifacts will inevitably have to co-exist in the larger maven
ecosystem simply because as a contributor to the project, one's local
reactor cache (eg. $HOME/.m2/repository) could contain artifacts from
maven central and the approves artifacts from repo.eclipse.org. So I guess
whether we intend to have consumers outside of Orbit for this repository
or not, we had better have a unique groupId.


> - In the cases where the original artifact names are not sufficiently
> "scoped", again only for modified artifacts, it may be good that someone
> selects a better name.
> And that someone being the committer seems like a sufficient/good
> option, to avoid long-running discussions on naming.
> "core" is a typical case, but there are many more (e.g. the artifacts in
> httpcomponents suffer from this as well with names like fluent-hc etc).
> My personal preference is that artifact names follow the rules used for
> bundle symbolic naming, e.g the above could become
> org.apache.httpcomponents.fluent or something similar.

I was citing this example mainly in the case that we go with
'org.eclipse.orbit' as the groupId, but if we go with something like
'org.eclipse.orbit.httpcomponents', then artifactsIds that are the same
across different groupIds should no longer be an issue.


So to conclude, I think we're in agreement that :

- Our artifact groupIds need to be unique from the original to emphasize
that the content may be different, that we are not the upstream distributor
- Our artifact groupIds need to still contain some reference to the original
part of the groupId to reference their origin, make them easier to browse,
and to prevent ambiguity with (poorly named) artifactIds

As a result, we can borrow from Option 2 in 
https://wiki.eclipse.org/Bundle_Naming and go with the 'org.eclipse.orbit' +
the originator simple name for the groupId of the artifact, keeping all other
aspects (artifactId, version, classifier) unchanged.

I'll make the necessary changes to the HIPP I've been testing with, but
committers will have the freedom to choose whichever
groupId:artifactId:version they want. It'll be very clear though what the
convention is.


Cheers,
-- 
Roland Grunberg


Back to the top