Re: [linuxtools-dev] Attention: Major changes for Tycho 0.13 compatibili

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

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

John

Alexander Kurtakov <akurtako@xxxxxxxxxx>
Sent by: linuxtools-dev-bounces@xxxxxxxxxxx

09/27/2011 11:57 AM

Please respond to
Linux Tools developer discussions <linuxtools-dev@xxxxxxxxxxx>

To	Linux Tools developer discussions <linuxtools-dev@xxxxxxxxxxx>
cc
Subject	[linuxtools-dev] Attention: Major changes for Tycho 0.13        compatibility

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