Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Bundle Version Management

David,

Comments below.

On 17/08/2012 4:22 PM, David M Williams wrote:
My question first. :) Your tool works live, right in the IDE?
Yes, like the API tooling.  We've made it as incremental as possible so it won't hurt to have it all the time.
Sounds very cool. Or do you mean something that computes and "fills it in" at build time?
No.
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.
We do follow the closure of the includes.   If included features are missing, we can't diagnose problems for those...

[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.
Yes, I'm glad to understand that, most importantly because it justifies duplicates which we assumed were something best avoided..

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.
Yes, that seems particularly important for external dependencies.
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.
John mentioned that too. It makes me thing maybe others are doing something different from what we've done.  As you could see in the example, I have an org.eclipse.emf.license feature.  I know when I change it.  It can't come from anywhere else.  When I change it I want all the other features to pick it up. It can't accidentally come from somewhere else.  I imagine that's the case for most projects.
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.
Yes, it definitely helps.  If I'm sure that Buckminster handles 0.0.0, I'd rather change EMF to use that.  But with the version tool, we'll produce errors for cases that PDE fails to diagnose.  E.g., you specify the license feature's version, but the license feature that's resolved has a different version.  PDE properly checks that for plugin and include version matching, but not for the feature license version matching.  We'll also update our duplication checking to not warn for duplicate IDs when their versions are different.

In any case, when we're done and we have documentation, I'll post another note and will appreciate more feedback at that time.
 





From:        Ed Merks <ed.merks@xxxxxxxxx>
To:        Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>,
Date:        08/17/2012 08:50 AM
Subject:        [cross-project-issues-dev] Bundle Version Management
Sent by:        cross-project-issues-dev-bounces@xxxxxxxxxxx




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
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


Back to the top