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 <[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
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
