On Wed, Oct 5, 2011 at 7:50 PM, John Arthorne
<John_Arthorne@xxxxxxxxxx> wrote:
I'm not a Tycho user and I don't claim
to fully understand the issues here, but there seems to be confusion on
what this Tycho change means. It is still possible to keep your feature
and bundle ids the same when using this new version of Tycho. For a description
of how to handle it, please see this comment:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=353384#c7
I don't know if this is easier or more
difficult than changing feature ids from your perspective, but changed
feature ids would certainly be a breaking change for anyone who has a feature
or product that is including your current features. Just wanted to pass
along this pointer and clarify the possible misconception that features
had to be renamed to accommodate this Tycho change...
Hi John,
I'm fully aware of the possibility to change the groupId instead of the artifactId(responding to Jeff proposal too). But it was not part of my proposal on purpose - having one project ship artifacts in different groups looks plain wrong to me. From Maven POV groupId is supposed to be unique amongst an organization or a project (organization=org.eclipse, project=linuxtools => groupId=org.eclipse.linuxtools). Using consistent groupId eases the way dependencies are declared, cleaning local maven repos and etc.
Additionally Linux Tools project is too fragmented even now and I see this as a possibility to standardize not to create even more inconsistencies between the subprojects. I know this will be a pain for downstreams(though not that much) but I prefer this to happen before we declare 1.0 i.e. I see this as part of the work for declaring a stable API. If most people insist on changing the groupId instead of using a consistent one I will obey the majority (though with reluctance) but I would also expect most people to do the releng part on their subprojects as most of the groupIds in the project are inherited and simple change of groupId in some pom can change things for releng as changing the bundle id/feature id for downstreams.
Alex
John
Everyone,
Please pay attention to this mail.
Tycho 0.13 requires that the feature ids and bundle symbolic name match
maven
artifactId. Also note that one can't have the same groupId:artifactId for
two
modules and this is the main problem because a number of our modules are
having the same feature id and symbolic name for the main bundle.
Almost all subprojects have this problem - autotools, changelog, gcov,
gprof,
lttng and etc. (I didn't cared to check the rest).
Please take care of your modules so the feature id/bundle symbolic name
match
the artifactId. If nothing happens on given module I'll start modifying
modules on October 10th to fix the build with tycho 0.13 using the following
rules:
* if feature and bundle have the same id - I'll rename the feature making
it
$currentName.feature . The reason behind is that it's way easier to handle
feature renames than bundle renames (Require-Bundle in downstream projects
and
etc.)
* if pom.xml and feature.xml/manifest.mf files use different ids - use
whichever
of the two ids that's closer to the directory it is in the checkout
As we are getting close to our 1.0 I would ask subproject maintainers to
consider doing some moves, merges and so on to make our codebase look more
consistent. What I'm proposing now is RFC so feel free to improve it and
we
will add it to the wiki:
1. Do we need test features? I don't see any benefit having them but I'm
open
to hear the subprojects that use them what are the benefits. Personally
I think
they are polluting the scm only - we run tests using bundles not features.
2. Agressive usage of features - There are cases (e.g libhover) where there
is
almost a feature for every bundle. Is it really needed? Can we simplify
it
and use features for some bigger grouping?
3. Bundle/Feature naming - that's what provoked this mail, I appreciate
the
fact that tycho devs showed the problem. It's confusing (at least) especially
in feature.xml files (include vs. import). My suggestion is to make the
feature
have the module name (e.g. org.eclipse.linuxtools.changelog) and if there
is a
module with the same name rename it to smth that describes it better e.g.
org.eclipse.linuxtools.changelog.core. Changelog is used intentionally
because
it's already this way.
Any comments?
P.S. Don't forget that on October 10th switch to Tycho 0.13 will happen
so
consider commenting sooner than later.
Alexander Kurtakov
_______________________________________________
linuxtools-dev mailing list
linuxtools-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
_______________________________________________
linuxtools-dev mailing list
linuxtools-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
