My question first. :) Your tool works live, right in the IDE? Sounds very cool. Or do you mean something that computes and "fills it in" at build time? Will be interesting to see if it handles deeply nested features (which would imply user might have to have a lot loaded in workspace) but even if it did not handle all nested case would still be very cool.
[The rest of this basically repeats what John and Markus said (I've learned to refresh my mail before hitting send :) but does point to some other "real life" use cases.] To answer your question 2. The only reason I know of to "hard code" an included feature bundle is if there is more than one to choose from, and you do not always want "the highest" one. We need to do this in Orbit, routinely, (no surprise, but the features there are "build time only" anyway) but occasionally I've seen used elsewhere, such as in WTP: for the longest time (not sure about right now) there was some code that used one version of WSDL and some other code that used another version of WSDL (and, there really were good reasons for it :) so the feature that wanted to use the lower version had to include the specific version it wanted (such as "1.4.0.qualifier" with qualifier being figured out at build time, which I guess is clear). A slight twist on the above use case, in WTP we used the whole Orbit map file that Orbit produces during its build, so I encouraged people to specify the version they wanted to use, even if currently only one, or if currently did want the highest one, since something could be added in future, and I think it is better to deliberately move up to some other version rather than "suddenly" be surprised. Though, I've seen another large, popular Eclipse project :) deliberately use a "reduced" version of the Orbit map, containing only what they wanted to be picked up, to accomplish the same thing. So, there, would only need to use version if there was a need for the same global collection of features to use more than one of some bundle (which is pretty rare). My guess is that some would say the license might best be (semi) hard coded to avoid "blindly" getting some other license that maybe a project would not want. That would be extremely rare in the case where you were building your own features and know what license you want your projects to have .... but, ... I'd have to think though not sure implication for if someone else is rebuilding your stuff with their own license? Guess there's really not much difference. (That it, they could leave the name and version the same and just change the "license bundle" content or they could change the name and version to make it more obvious it was some different license? Either way, out of your control). Hope that data helps a little. From: Ed Merks <[email protected]> To: Cross project issues <[email protected]>, Date: 08/17/2012 08:50 AM Subject: [cross-project-issues-dev] Bundle Version Management Sent by: [email protected] Hi, Eike and I have been working on a tool for helping manage plugin and feature versions (as well as other types of consistency checks). API Tooling is very useful for keeping track of when you should increment a plugin's major or minor version, but nothing currently helps you manage your micro versions. It's very easy to forget to increment the minor version after making a content change (body of some method, for example) and it's hard to remember whether you've already incremented the micro version for the current stream. Our idea is to create a base line, i.e., to keep track of all bundles and features as well as their versions at the start of a stream along with digests so we know when the contents of bundles and features change. A content change requires an increment to the micro version and we create markers (with quick fixes) to flag these. Feature inclusions are taken into account, so if you change the version of a bundle, you're prompted to appropriately increment the features that directly or indirectly include that bundle. We can detect redundancies in the includes, i.e., include a plugin that's already included by a feature as well as breaking changes, e.g., removing a plugin. The new "version builder" tool is mostly working now and is part of CDO. We'll make it's feature available via CDO's p2 update site... As part of some final touch-ups, we were looking at license feature support. E.g., EMF's org.eclipse.emf feature specifies its license feature like this: <feature id="org.eclipse.emf" label="%featureName" version="2.8.0.qualifier" provider-name="%providerName" image="eclipse_update_120.jpg" license-feature="org.eclipse.emf.license" license-feature-version="2.7.0.qualifier"> Note in particular that we "hard code" the version of the license feature. We noticed that specifying license-feature-version="0.0.0" also works, much like it does for includes and plugins. By works, I mean exporting the feature resolves the license correctly and produces the correct resulting binaries that contain the copied license files. We're not sure if Buckminster works the same way; we hope so. (Maybe Thomas will comment.) Note that if you specify an incorrect version, e.g., license-feature-version="200.7.0.qualifier" PDE doesn't produce errors, but the exporter fails and complains that the license feature doesn't resolve. Our version tool could produce an error for this at development time. In any case, it seems that 0.0.0 ought to work in general, and that this would be an improvement over hard coding the number... So, now for the questions: 1. Can anyone comment on why we've pretty much all ended up hard coding the license feature version rather than using 0.0.0 like we do for include and plugin declarations? 2. And the more general question, is there any value in hard coding the number even for include and plugin declarations? I.e., does anyone hard code the version in of their feature.xml's plugin and include declarations rather than use 0.0.0? If so, what's the value of a hard code number in that context, given it's more work to maintain it properly? Regards, Ed _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
