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 n
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 als
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 will
Vinayak, I suggest entering a bug report for this (under RT > Equinox >
Components).
Vinayak Joshi <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
09/05/2008 12:09 PM
Please respond to
[EMAIL PROTECTED]; Please respond to
Equinox development mailing list
To
equinox-dev@eclipse.org
cc
Subj
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 inv
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 t
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 comp
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 int
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 b
> 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 quali
If we decided to back out an API then we revert the version back and have
to make the necessary announcements to the community to prepare them for
the version decrease in mid development cycle. From release to release our
version have to follow our version rules at
http://wiki.eclipse.org/index.p
Could you please provide a detailed scenario of where you think the absence
of precise package would cause the provisioning to fail?
|>
| From: |
|>
>--
If I understand #2 correctly, then you want a controlled version practice
during the development cycle. This is challenging since you may want to
change your mind and break from a previous API change made during the same
dev cycle.
For example:
1.2 is the last shipped version of a package (let
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 A
14 matches
Mail list logo
