[eclipse.org-architecture-council] [Bug 288644] Decide of group ids for

[bugzilla-daemon@xxxxxxxxxxx]

https://bugs.eclipse.org/bugs/show_bug.cgi?id=288644 
Product/Component: Community / Architecture Council

Martin Oberhuber <martin.oberhuber@xxxxxxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |

--- Comment #21 from Martin Oberhuber <martin.oberhuber@xxxxxxxxxxxxx> 2010-11-18 11:28:13 EST ---
Antoine, Jason:

Looking at many comments here, it looks like the adopter community is not happy
with the "flat org.eclipse" group ID decision, and moreover the decision might
be ruled out by what people just do themselves.

Alex' suggestion of simply using the first 3 segments of any bundle name as the
group ID seems to make sense to me, and seems to satisfy Jason's requirement
from comment 3. In most cases it will be equivalent to "org.eclipse.projectid"
but it will be more deterministic. Moreover, according to bug 283745 comment
153, it seems to be what the b3 aggregator currently does so we're at risk of
just inheriting this de-facto nonstandard unless we speak up now..

I haven't been part of the original discussions at EclipseCon, so if there are
good arguments in favor of a flat "org.eclipse" groupID and against the 3-level
"org.eclipse.<thirdpart>" groupID please bring them up now.

My only note is that "org.eclipse.<thirdpart>" will break up the Eclipse
Platform project's deliveries into multiple groups, and some bundles will show
up in places where they might not be expected (org.eclipse.jem produced by
Webtools for instance). I personally don't see any problem with this, but then
I'm not a Maven expert.

-- 
Configure bugmail: https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.