I'm certainly sympathetic to you thinking here. Having qualifiers in
import statements is ugly at best. The challenge is that in the dev
cycle the API of something may change many many times. This would lead
to quite visible changes in unreasonable ways. For example, say we
introduce some API
Could you please provide a detailed scenario of where you think the absence
of precise package would cause the provisioning to fail?
|
| From: |
|
Without some sort of increasing version number on the packages, p2
for example, will have a hard time figuring out what to give you
cause everything will look the same to it.
Can anyone think of another way of enabling #2?
Wouldn't p2 _have_ to always pick a bundle with the highest
Mix-and-matching bundles from different builds during a dev cycle seems a
recipe for problems. If p2 will pick the bundle with the highest bundle
version (including the qualifier with the builddate) and the p2 repo is
always properly provisioned with the latest build output, then there
should
But the qualifier is just another component of the version to allow
ordering among versions. Why is change it any different than changing any
other component of the version? (Other than semantic we place on the
version components.)
Changing any part of the version during development is only
Anyone adopting early API (before API freeze) has to be prepared for
breaking changes. We must have the flexibility to develop our new API and
increment our versions properly from one final release to the next.
Imagine the following scenario
foo; version=1.0
The M1 build adds new backwards
We have qualifiers on bundles to support the notion of provisioning
line-ups (aka features) that list precise groups of IUs (one precise
build of a particular bundle). We *don't* have qualifiers on bundles so
that require-bundle statements can precisely choose a particular build of
a bundle to
Hi
I am running some bundles in equinox and one of the bundles routinely polls a
designated directory to check if the bundle-jars there have been updated since
they were last installed into the equinox runtime. On finding updates, it uses
bundle.update() to cause an update. thereafter, it
If the new API is completely pull such that the API is again the same as
the last released version then yes, revert to 1.0. But as long as the API
is different than the last released version, it should remain 1.1. Putting
a qualifier of a build date or tag on the package export is wrong. It
For the most part I agree. But I do think there is value in versioning API
packages that contain not only pure specification but also implementation.
One real example is the OSGi package org.osgi.util.tracker package. This
package contains the ServiceTracker API, but the ServiceTracker class
I have also put a small example on my blog:
http://blog.ianbull.com/2008/09/gwt-and-osgi.html
Cheers,
Ian
Gunnar Wagenknecht wrote:
Hi Ricardo,
Ricardo Giacomin schrieb:
I tried to follow the directions from wiki page
http://wiki.eclipse.org/index.php/Google_Web_Toolkit_and_Equinox with
11 matches
Mail list logo
