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
|
