You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by David Savage <da...@paremus.com> on 2009/09/16 16:18:01 UTC
Version management in Sigil
Hi there,
Thought I'd send out this message to a large audience than just the
dev team as it's one of those things that it's good to get wide
feedback on. I'm currently in the process of getting the sigil build
up and running here at apache and one slightly complicated issues in
OSGi development is managing the version number of bundles and I'm
currently trying to figure out the "best" path.
In order to describe the problem I also probably need to give you some
background...I started to do this in email but then figured wiki was a
better place for it.
http://cwiki.apache.org/FELIX/sigil-projects.html
http://cwiki.apache.org/FELIX/sigil-installation.html
Both are quite short if you've the time to read them the rest of this
email will make more sense...
My current problem with the sigil build is wrt to .SNAPSHOT and
eclipse update sites. I've currently set the sigil build to build
bundles with a version of 0.9.0.SNAPSHOT as per the maven build
pattern. But this get's me into hot water when trying to test these
bundles in Eclipse as P2 quite rightly assumes that once you've
installed a version of a bundle with a particular version that's it.
It will only prompt you to install a new bundle from an update-site if
a new version appears that is greater than the old version. Here
.SNAPSHOT falls down...
I think in order to make this process easier sigil should borrow a
pattern from pde which is to use a version of the format:
-version: 1.0.0.${qualifier}
where qualifier is a dynamically calculated value - either from system
properties or some other config source. In snapshot builds where you
don't want multiple versions of your jar piling up on top of each
other the qualifer can be set to .SNAPSHOT but in release builds a
time stamp value can be automatically substituted to ensure
incremental builds. Again this is important for development time work
on sigil as in order to test the plugins we build that are downloaded
from an update site the version number needs to increment and it's a
pain to have to keep doing this manually.
Does this make any sense - are there other options?
Thoughts on a post card etc.
Regards,
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Version management in Sigil
Posted by David Savage <da...@paremus.com>.
Hi,
Yep I'd certainly like Sigil to be able work with Tycho as well, but
at the moment Sigil is an ant/ivy based build system. Just trying to
close off one problem area before I move onto the next...
I think the fundamental problem is how to handle osgi versions in an
agile way so you can role new versions out quickly but still ensure
that they're unique? With snapshot you end up with lot's of potential
builds which are all labeled the same which makes it difficult for
resolution tools like p2, obr or nimble to figure out that something
has actually changed and hence update their runtime environment.
In larger projects manually bumping the version number every time you
do an integration build is a real pain as you need to go into every
project and increment the micro version number. Using a .qualifier
approach the X.Y.Z stays constant which reflects the "outward" view of
the version number but still the artifacts that are created are
uniquely identified...
Regards,
Dave
On Wed, Sep 16, 2009 at 4:34 PM, Chris Custine <ch...@gmail.com> wrote:
> Hi David,
> I haven't used it myself, but have you looked at Tycho?
> http://docs.codehaus.org/display/M2ECLIPSE/Tycho+user+docs#Tychouserdocs-InstallingandrunningTycho
>
> IIUC, this is specifically for building Eclipse Plugins and update sites
> with Maven. It almost certainly has a solution for the issues you mention.
> The page above is a bit old, but I think there has been a lot more
> development and progress on Tycho than is apparent on that page. This is
> being built by the Sonatype guys, so I think it might be worth looking at if
> you haven't already.
>
> Chris
>
> --
> Chris Custine
> FUSESource :: http://fusesource.com
> My Blog :: http://blog.organicelement.com
> Apache ServiceMix :: http://servicemix.apache.org
> Apache Directory Server :: http://directory.apache.org
>
>
> On Wed, Sep 16, 2009 at 8:18 AM, David Savage <da...@paremus.com>wrote:
>
>> Hi there,
>>
>> Thought I'd send out this message to a large audience than just the
>> dev team as it's one of those things that it's good to get wide
>> feedback on. I'm currently in the process of getting the sigil build
>> up and running here at apache and one slightly complicated issues in
>> OSGi development is managing the version number of bundles and I'm
>> currently trying to figure out the "best" path.
>>
>> In order to describe the problem I also probably need to give you some
>> background...I started to do this in email but then figured wiki was a
>> better place for it.
>>
>> http://cwiki.apache.org/FELIX/sigil-projects.html
>> http://cwiki.apache.org/FELIX/sigil-installation.html
>>
>> Both are quite short if you've the time to read them the rest of this
>> email will make more sense...
>>
>> My current problem with the sigil build is wrt to .SNAPSHOT and
>> eclipse update sites. I've currently set the sigil build to build
>> bundles with a version of 0.9.0.SNAPSHOT as per the maven build
>> pattern. But this get's me into hot water when trying to test these
>> bundles in Eclipse as P2 quite rightly assumes that once you've
>> installed a version of a bundle with a particular version that's it.
>> It will only prompt you to install a new bundle from an update-site if
>> a new version appears that is greater than the old version. Here
>> .SNAPSHOT falls down...
>>
>> I think in order to make this process easier sigil should borrow a
>> pattern from pde which is to use a version of the format:
>>
>> -version: 1.0.0.${qualifier}
>>
>> where qualifier is a dynamically calculated value - either from system
>> properties or some other config source. In snapshot builds where you
>> don't want multiple versions of your jar piling up on top of each
>> other the qualifer can be set to .SNAPSHOT but in release builds a
>> time stamp value can be automatically substituted to ensure
>> incremental builds. Again this is important for development time work
>> on sigil as in order to test the plugins we build that are downloaded
>> from an update site the version number needs to increment and it's a
>> pain to have to keep doing this manually.
>>
>> Does this make any sense - are there other options?
>>
>> Thoughts on a post card etc.
>>
>> Regards,
>>
>> Dave
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Version management in Sigil
Posted by Chris Custine <ch...@gmail.com>.
Hi David,
I haven't used it myself, but have you looked at Tycho?
http://docs.codehaus.org/display/M2ECLIPSE/Tycho+user+docs#Tychouserdocs-InstallingandrunningTycho
IIUC, this is specifically for building Eclipse Plugins and update sites
with Maven. It almost certainly has a solution for the issues you mention.
The page above is a bit old, but I think there has been a lot more
development and progress on Tycho than is apparent on that page. This is
being built by the Sonatype guys, so I think it might be worth looking at if
you haven't already.
Chris
--
Chris Custine
FUSESource :: http://fusesource.com
My Blog :: http://blog.organicelement.com
Apache ServiceMix :: http://servicemix.apache.org
Apache Directory Server :: http://directory.apache.org
On Wed, Sep 16, 2009 at 8:18 AM, David Savage <da...@paremus.com>wrote:
> Hi there,
>
> Thought I'd send out this message to a large audience than just the
> dev team as it's one of those things that it's good to get wide
> feedback on. I'm currently in the process of getting the sigil build
> up and running here at apache and one slightly complicated issues in
> OSGi development is managing the version number of bundles and I'm
> currently trying to figure out the "best" path.
>
> In order to describe the problem I also probably need to give you some
> background...I started to do this in email but then figured wiki was a
> better place for it.
>
> http://cwiki.apache.org/FELIX/sigil-projects.html
> http://cwiki.apache.org/FELIX/sigil-installation.html
>
> Both are quite short if you've the time to read them the rest of this
> email will make more sense...
>
> My current problem with the sigil build is wrt to .SNAPSHOT and
> eclipse update sites. I've currently set the sigil build to build
> bundles with a version of 0.9.0.SNAPSHOT as per the maven build
> pattern. But this get's me into hot water when trying to test these
> bundles in Eclipse as P2 quite rightly assumes that once you've
> installed a version of a bundle with a particular version that's it.
> It will only prompt you to install a new bundle from an update-site if
> a new version appears that is greater than the old version. Here
> .SNAPSHOT falls down...
>
> I think in order to make this process easier sigil should borrow a
> pattern from pde which is to use a version of the format:
>
> -version: 1.0.0.${qualifier}
>
> where qualifier is a dynamically calculated value - either from system
> properties or some other config source. In snapshot builds where you
> don't want multiple versions of your jar piling up on top of each
> other the qualifer can be set to .SNAPSHOT but in release builds a
> time stamp value can be automatically substituted to ensure
> incremental builds. Again this is important for development time work
> on sigil as in order to test the plugins we build that are downloaded
> from an update site the version number needs to increment and it's a
> pain to have to keep doing this manually.
>
> Does this make any sense - are there other options?
>
> Thoughts on a post card etc.
>
> Regards,
>
> Dave
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>