On Wed, Oct 5, 2011 at 7:50 PM, John Arthorne <john_artho...@ca.ibm.com>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 > > > > > *Alexander Kurtakov <akurt...@redhat.com>* > Sent by: linuxtools-dev-boun...@eclipse.org > > 09/27/2011 11:57 AM > Please respond to > Linux Tools developer discussions <linuxtools-dev@eclipse.org> > > To > Linux Tools developer discussions <linuxtools-dev@eclipse.org> > 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@eclipse.org > https://dev.eclipse.org/mailman/listinfo/linuxtools-dev > > > _______________________________________________ > linuxtools-dev mailing list > linuxtools-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/linuxtools-dev > >
_______________________________________________ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
