You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by David Jencks <da...@yahoo.com> on 2011/12/02 04:49:01 UTC
Re: svn commit: r1203307 - in /aries/trunk/blueprint: blueprint-bundle/ blueprint-itests/ blueprint-testbundlea/src/main/java/org/apache/aries/blueprint/testbundlea/ blueprint-testbundlea/src/main/resources/OSGI-INF/blueprint/ blueprint-testbundlea/s
I think there are two valid goals here with conflicting requirements:
- make sure that individual artifacts continue to work against at least one already-released version
- make sure that all the individual artifacts continue to work together as they are developed.
I think these are both really worthwhile goals.
I suggest we solve this conflict using profiles and have jenkins run two builds using the profiles. We can discuss whether one of the profiles should be default, I think the "released version" profile would be a better default but I don't think this is very important.
Anyway each bundle project would have two profiles perhaps
released - contains version properties for dependencies at the oldest released version we expect the project bundle to work against
dev - contains version properties for dependencies at the current snapshot version
thoughts?
thanks
david jencks
On Nov 25, 2011, at 4:08 AM, Alasdair Nottingham wrote:
> On 22 November 2011 21:10, Daniel Kulp <dk...@apache.org> wrote:
>
>> On Tuesday, November 22, 2011 6:32:57 PM Jeremy Hughes wrote:
>>> Hi Dan, I'm just catching up with what you're doing here. Back in
>>> March we spent some time figuring out how to implement the OSGi
>>> Semantic Versioning policy in our Maven build and release process. Zoe
>>> documented it here:
>>>
>>> http://aries.apache.org/development/versionpolicy.html
>>>
>>> based discussions on the list, with the last one being here:
>>>
>>>
>> http://mail-archives.apache.org/mod_mbox/aries-dev/201103.mbox/%3C1300364661
>>> .27234.33.camel%40meschbix%3E
>>>
>>> There are some disparities with what you've change w.r.t what was
>>> decided back then. I've made a comment in-line to this commit.
>>
>> ...........snip ..............
>>
>>>> - <version>0.3</version>
>>>> + <version>0.3.2-SNAPSHOT</version>
>>>
>>> This should stay at 0.3 as there is no difference between trunk and
>>> 0.3. blueprint 0.3.1 was released before we moved to the 'release by
>>> bundle' process so it ended up releasing blueprint-api 0.3.1 even
>>> there were no changes in it over 0.3. Can you describe how you have
>>> decided what versions to use here and below? They really should be
>>> depending on the released artifact. Thanks.
>>
>> Well, I would consider that a responsibility of the release manager (or on
>> release branches) now to figure that out. On trunk, things really need
>> to
>> be geared toward the day to day work of the developers doing the work and
>> making changes and fixing bugs. For that, they need to be pointing at the
>> snapshots for a variety of reasons:
>>
>> 1) Things like eclipse:eclipse will wire the projects together correctly so
>> debugging and developing in the IDE works properly.
>>
>> 2) The tests (particularly the itests) actually test the code that is being
>> developed on trunk. If a developer makes a change in a SNAPSHOT and runs
>> the
>> tests, it should test the changes, not some release made 3 months ago.
>> This
>> is very important to me. I want to be able to run "mvn test" before I
>> commit
>> and make sure everything works.
>>
>> 3) Related to (2), if a developer does make a change someplace, I really
>> don't
>> feel he should need to go off and find all the various places that need to
>> be
>> updated to make sure that change is fully tested.
>>
>> Remember, one of the goals of an Apache project is to expand the developer
>> community. That is best done by making sure the a new developer can jump
>> in
>> easily and start contributing without jumping through major learning curves
>> and wacky and non-standard policies to get there.
>>
>
> This "wacky and non-standard" policy is there to ensure we can do the
> "standard" OSGi practice of developing
> independently releasable artefacts which are versioned using the standard
> OSGi semantic versioning practice.
> The goal here is different from yours. If we move everything up all the
> time we may "know" that it works against
> the latest, but it probably (in some cases certainly) no longer works
> against the prior release of dependencies. So
> we want to ensure we only up the dependency when we need a new capability
> from it.
>
> I guess the downside is testing against the latest, so we need a solution
> to that, but it isn't to break our ability to work
> with compatible prior releases of dependencies.
>
>
>>
>>
>>
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
Re: svn commit: r1203307 - in /aries/trunk/blueprint: blueprint-bundle/ blueprint-itests/ blueprint-testbundlea/src/main/java/org/apache/aries/blueprint/testbundlea/ blueprint-testbundlea/src/main/resources/OSGI-INF/blueprint/ blueprint-testbundlea/s
Posted by David Jencks <da...@yahoo.com>.
I went ahead and opened ARIES-798 and committed some changes to blueprint that implement the profile idea.
By default the build is against released versions.
If you want to build against snapshots run
mvn clean install -Pdev
For some reason it doesn't seem to be possible to put the stable versions in a profile (each project seems to work but a project that is a dependency doesn't seem to have defined version properties). Therefore in the dev profile any transitive dependencies will be the stable versions, not snapshots. We could make all the dependencies provided so you have to specify the versions in each project, but I don't think that would gain us much.
This is in rev 1210363 so we can revert it pretty easily if there are problems I didn't see.
Does anyone know how to set up jenkins to build twice, once plain and once with -Pdev?
thanks
david jencks
On Dec 2, 2011, at 2:59 PM, David Jencks wrote:
>
> On Dec 2, 2011, at 2:26 PM, Daniel Kulp wrote:
>
>> On Friday, December 02, 2011 10:15:22 AM David Jencks wrote:
>>> On Dec 2, 2011, at 2:39 AM, Jeremy Hughes wrote:
>>>> On 2 December 2011 03:49, David Jencks <da...@yahoo.com> wrote:
>>>>> released - contains version properties for dependencies at the oldest
>>>>> released version we expect the project bundle to work against>
>>>> would we have to do this using a set of maintained properties files?
>>>> Where would this go - in the parent pom, the top level module pom or
>>>> the bundle pom. There's a file her
>>>> http://svn.apache.org/repos/asf/aries/trunk/aries_release_versions.txt
>>>> which is supposed to reflect the latest versions - although I think a
>>>> maven plugin could be written and teased into figuring out the latest.
>>>
>>> I think the versions need to be maintained in each (leaf) pom for artifacts
>>> we release. Otherwise there's no good way to release single artifacts.
>>>
>>> There's the versions-maven-plugin
>>> http://mojo.codehaus.org/versions-maven-plugin/ that helps with updating
>>> versions but I don't know if it is smart enough to work with version
>>> properties in a profile. If the plugin doesn't work, if we use a
>>> consistent version naming scheme its easy enough to use an IDE's
>>> search-and-replace to update properties.
>>
>> We could also try an import scoped dependency of some sort.
>>
>> Basically, have a pom someplace that defines an dependencyManagement thing
>> that lists ALL the Aries jars and their current SNAPSHOT version and another
>> one that lists ALL of the latest releases (which means it would need to be
>> part of each release). A profile could selectively depend on the one that
>> is needed. Pretty much would remove all the version numbers from everywhere.
>>
> I don't think something like that would work here. The idea is to make each bundle independently releasable. Furthermore we don't really know what the next snapshot version is going to be for a while, I think the current idea is to on release update from e.g. 0.4.1-SNAPSHOT to 0.4.1-next-SNAPSHOT until we know what digit should get incremented. And we may not be sure that all users of a bundle want to use the same released version as "earliest compatibility". So the "last release" might not be what we want and would have to be released for every bundle release. While it's a pain I think keeping the versions in each leaf pom is the way to go for aries.
>
> thanks
> david jencks
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>
Re: svn commit: r1203307 - in /aries/trunk/blueprint: blueprint-bundle/ blueprint-itests/ blueprint-testbundlea/src/main/java/org/apache/aries/blueprint/testbundlea/ blueprint-testbundlea/src/main/resources/OSGI-INF/blueprint/ blueprint-testbundlea/s
Posted by David Jencks <da...@yahoo.com>.
On Dec 2, 2011, at 2:26 PM, Daniel Kulp wrote:
> On Friday, December 02, 2011 10:15:22 AM David Jencks wrote:
>> On Dec 2, 2011, at 2:39 AM, Jeremy Hughes wrote:
>>> On 2 December 2011 03:49, David Jencks <da...@yahoo.com> wrote:
>>>> released - contains version properties for dependencies at the oldest
>>>> released version we expect the project bundle to work against>
>>> would we have to do this using a set of maintained properties files?
>>> Where would this go - in the parent pom, the top level module pom or
>>> the bundle pom. There's a file her
>>> http://svn.apache.org/repos/asf/aries/trunk/aries_release_versions.txt
>>> which is supposed to reflect the latest versions - although I think a
>>> maven plugin could be written and teased into figuring out the latest.
>>
>> I think the versions need to be maintained in each (leaf) pom for artifacts
>> we release. Otherwise there's no good way to release single artifacts.
>>
>> There's the versions-maven-plugin
>> http://mojo.codehaus.org/versions-maven-plugin/ that helps with updating
>> versions but I don't know if it is smart enough to work with version
>> properties in a profile. If the plugin doesn't work, if we use a
>> consistent version naming scheme its easy enough to use an IDE's
>> search-and-replace to update properties.
>
> We could also try an import scoped dependency of some sort.
>
> Basically, have a pom someplace that defines an dependencyManagement thing
> that lists ALL the Aries jars and their current SNAPSHOT version and another
> one that lists ALL of the latest releases (which means it would need to be
> part of each release). A profile could selectively depend on the one that
> is needed. Pretty much would remove all the version numbers from everywhere.
>
I don't think something like that would work here. The idea is to make each bundle independently releasable. Furthermore we don't really know what the next snapshot version is going to be for a while, I think the current idea is to on release update from e.g. 0.4.1-SNAPSHOT to 0.4.1-next-SNAPSHOT until we know what digit should get incremented. And we may not be sure that all users of a bundle want to use the same released version as "earliest compatibility". So the "last release" might not be what we want and would have to be released for every bundle release. While it's a pain I think keeping the versions in each leaf pom is the way to go for aries.
thanks
david jencks
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
Re: svn commit: r1203307 - in /aries/trunk/blueprint: blueprint-bundle/ blueprint-itests/ blueprint-testbundlea/src/main/java/org/apache/aries/blueprint/testbundlea/ blueprint-testbundlea/src/main/resources/OSGI-INF/blueprint/ blueprint-testbundlea/s
Posted by Daniel Kulp <dk...@apache.org>.
On Friday, December 02, 2011 10:15:22 AM David Jencks wrote:
> On Dec 2, 2011, at 2:39 AM, Jeremy Hughes wrote:
> > On 2 December 2011 03:49, David Jencks <da...@yahoo.com> wrote:
> >> released - contains version properties for dependencies at the oldest
> >> released version we expect the project bundle to work against>
> > would we have to do this using a set of maintained properties files?
> > Where would this go - in the parent pom, the top level module pom or
> > the bundle pom. There's a file her
> > http://svn.apache.org/repos/asf/aries/trunk/aries_release_versions.txt
> > which is supposed to reflect the latest versions - although I think a
> > maven plugin could be written and teased into figuring out the latest.
>
> I think the versions need to be maintained in each (leaf) pom for artifacts
> we release. Otherwise there's no good way to release single artifacts.
>
> There's the versions-maven-plugin
> http://mojo.codehaus.org/versions-maven-plugin/ that helps with updating
> versions but I don't know if it is smart enough to work with version
> properties in a profile. If the plugin doesn't work, if we use a
> consistent version naming scheme its easy enough to use an IDE's
> search-and-replace to update properties.
We could also try an import scoped dependency of some sort.
Basically, have a pom someplace that defines an dependencyManagement thing
that lists ALL the Aries jars and their current SNAPSHOT version and another
one that lists ALL of the latest releases (which means it would need to be
part of each release). A profile could selectively depend on the one that
is needed. Pretty much would remove all the version numbers from everywhere.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: svn commit: r1203307 - in /aries/trunk/blueprint: blueprint-bundle/ blueprint-itests/ blueprint-testbundlea/src/main/java/org/apache/aries/blueprint/testbundlea/ blueprint-testbundlea/src/main/resources/OSGI-INF/blueprint/ blueprint-testbundlea/s
Posted by David Jencks <da...@yahoo.com>.
On Dec 2, 2011, at 2:39 AM, Jeremy Hughes wrote:
> On 2 December 2011 03:49, David Jencks <da...@yahoo.com> wrote:
>> I think there are two valid goals here with conflicting requirements:
>>
>> - make sure that individual artifacts continue to work against at least one already-released version
>>
>> - make sure that all the individual artifacts continue to work together as they are developed.
>>
>> I think these are both really worthwhile goals.
>
> +1 I agree. This has been percolating through the back of my mind the
> last few days too.
>
>>
>> I suggest we solve this conflict using profiles and have jenkins run two builds using the profiles. We can discuss whether one of the profiles should be default, I think the "released version" profile would be a better default but I don't think this is very important.
>>
>> Anyway each bundle project would have two profiles perhaps
>>
>> released - contains version properties for dependencies at the oldest released version we expect the project bundle to work against
>
> would we have to do this using a set of maintained properties files?
> Where would this go - in the parent pom, the top level module pom or
> the bundle pom. There's a file her
> http://svn.apache.org/repos/asf/aries/trunk/aries_release_versions.txt
> which is supposed to reflect the latest versions - although I think a
> maven plugin could be written and teased into figuring out the latest.
I think the versions need to be maintained in each (leaf) pom for artifacts we release. Otherwise there's no good way to release single artifacts.
There's the versions-maven-plugin http://mojo.codehaus.org/versions-maven-plugin/ that helps with updating versions but I don't know if it is smart enough to work with version properties in a profile. If the plugin doesn't work, if we use a consistent version naming scheme its easy enough to use an IDE's search-and-replace to update properties.
thanks
david jencks
>
>>
>> dev - contains version properties for dependencies at the current snapshot version
>>
>> thoughts?
>>
>> thanks
>> david jencks
>>
>>
>> On Nov 25, 2011, at 4:08 AM, Alasdair Nottingham wrote:
>>
>>> On 22 November 2011 21:10, Daniel Kulp <dk...@apache.org> wrote:
>>>
>>>> On Tuesday, November 22, 2011 6:32:57 PM Jeremy Hughes wrote:
>>>>> Hi Dan, I'm just catching up with what you're doing here. Back in
>>>>> March we spent some time figuring out how to implement the OSGi
>>>>> Semantic Versioning policy in our Maven build and release process. Zoe
>>>>> documented it here:
>>>>>
>>>>> http://aries.apache.org/development/versionpolicy.html
>>>>>
>>>>> based discussions on the list, with the last one being here:
>>>>>
>>>>>
>>>> http://mail-archives.apache.org/mod_mbox/aries-dev/201103.mbox/%3C1300364661
>>>>> .27234.33.camel%40meschbix%3E
>>>>>
>>>>> There are some disparities with what you've change w.r.t what was
>>>>> decided back then. I've made a comment in-line to this commit.
>>>>
>>>> ...........snip ..............
>>>>
>>>>>> - <version>0.3</version>
>>>>>> + <version>0.3.2-SNAPSHOT</version>
>>>>>
>>>>> This should stay at 0.3 as there is no difference between trunk and
>>>>> 0.3. blueprint 0.3.1 was released before we moved to the 'release by
>>>>> bundle' process so it ended up releasing blueprint-api 0.3.1 even
>>>>> there were no changes in it over 0.3. Can you describe how you have
>>>>> decided what versions to use here and below? They really should be
>>>>> depending on the released artifact. Thanks.
>>>>
>>>> Well, I would consider that a responsibility of the release manager (or on
>>>> release branches) now to figure that out. On trunk, things really need
>>>> to
>>>> be geared toward the day to day work of the developers doing the work and
>>>> making changes and fixing bugs. For that, they need to be pointing at the
>>>> snapshots for a variety of reasons:
>>>>
>>>> 1) Things like eclipse:eclipse will wire the projects together correctly so
>>>> debugging and developing in the IDE works properly.
>>>>
>>>> 2) The tests (particularly the itests) actually test the code that is being
>>>> developed on trunk. If a developer makes a change in a SNAPSHOT and runs
>>>> the
>>>> tests, it should test the changes, not some release made 3 months ago.
>>>> This
>>>> is very important to me. I want to be able to run "mvn test" before I
>>>> commit
>>>> and make sure everything works.
>>>>
>>>> 3) Related to (2), if a developer does make a change someplace, I really
>>>> don't
>>>> feel he should need to go off and find all the various places that need to
>>>> be
>>>> updated to make sure that change is fully tested.
>>>>
>>>> Remember, one of the goals of an Apache project is to expand the developer
>>>> community. That is best done by making sure the a new developer can jump
>>>> in
>>>> easily and start contributing without jumping through major learning curves
>>>> and wacky and non-standard policies to get there.
>>>>
>>>
>>> This "wacky and non-standard" policy is there to ensure we can do the
>>> "standard" OSGi practice of developing
>>> independently releasable artefacts which are versioned using the standard
>>> OSGi semantic versioning practice.
>>> The goal here is different from yours. If we move everything up all the
>>> time we may "know" that it works against
>>> the latest, but it probably (in some cases certainly) no longer works
>>> against the prior release of dependencies. So
>>> we want to ensure we only up the dependency when we need a new capability
>>> from it.
>>>
>>> I guess the downside is testing against the latest, so we need a solution
>>> to that, but it isn't to break our ability to work
>>> with compatible prior releases of dependencies.
>>>
>>>
>>>>
>>>>
>>>>
>>>> Daniel Kulp
>>>> dkulp@apache.org - http://dankulp.com/blog
>>>> Talend Community Coder - http://coders.talend.com
>>>>
>>>
>>>
>>>
>>> --
>>> Alasdair Nottingham
>>> not@apache.org
>>
Re: svn commit: r1203307 - in /aries/trunk/blueprint:
blueprint-bundle/ blueprint-itests/ blueprint-testbundlea/src/main/java/org/apache/aries/blueprint/testbundlea/
blueprint-testbundlea/src/main/resources/OSGI-INF/blueprint/ blueprint-testbundlea/s
Posted by Jeremy Hughes <hu...@apache.org>.
On 2 December 2011 03:49, David Jencks <da...@yahoo.com> wrote:
> I think there are two valid goals here with conflicting requirements:
>
> - make sure that individual artifacts continue to work against at least one already-released version
>
> - make sure that all the individual artifacts continue to work together as they are developed.
>
> I think these are both really worthwhile goals.
+1 I agree. This has been percolating through the back of my mind the
last few days too.
>
> I suggest we solve this conflict using profiles and have jenkins run two builds using the profiles. We can discuss whether one of the profiles should be default, I think the "released version" profile would be a better default but I don't think this is very important.
>
> Anyway each bundle project would have two profiles perhaps
>
> released - contains version properties for dependencies at the oldest released version we expect the project bundle to work against
would we have to do this using a set of maintained properties files?
Where would this go - in the parent pom, the top level module pom or
the bundle pom. There's a file her
http://svn.apache.org/repos/asf/aries/trunk/aries_release_versions.txt
which is supposed to reflect the latest versions - although I think a
maven plugin could be written and teased into figuring out the latest.
>
> dev - contains version properties for dependencies at the current snapshot version
>
> thoughts?
>
> thanks
> david jencks
>
>
> On Nov 25, 2011, at 4:08 AM, Alasdair Nottingham wrote:
>
>> On 22 November 2011 21:10, Daniel Kulp <dk...@apache.org> wrote:
>>
>>> On Tuesday, November 22, 2011 6:32:57 PM Jeremy Hughes wrote:
>>>> Hi Dan, I'm just catching up with what you're doing here. Back in
>>>> March we spent some time figuring out how to implement the OSGi
>>>> Semantic Versioning policy in our Maven build and release process. Zoe
>>>> documented it here:
>>>>
>>>> http://aries.apache.org/development/versionpolicy.html
>>>>
>>>> based discussions on the list, with the last one being here:
>>>>
>>>>
>>> http://mail-archives.apache.org/mod_mbox/aries-dev/201103.mbox/%3C1300364661
>>>> .27234.33.camel%40meschbix%3E
>>>>
>>>> There are some disparities with what you've change w.r.t what was
>>>> decided back then. I've made a comment in-line to this commit.
>>>
>>> ...........snip ..............
>>>
>>>>> - <version>0.3</version>
>>>>> + <version>0.3.2-SNAPSHOT</version>
>>>>
>>>> This should stay at 0.3 as there is no difference between trunk and
>>>> 0.3. blueprint 0.3.1 was released before we moved to the 'release by
>>>> bundle' process so it ended up releasing blueprint-api 0.3.1 even
>>>> there were no changes in it over 0.3. Can you describe how you have
>>>> decided what versions to use here and below? They really should be
>>>> depending on the released artifact. Thanks.
>>>
>>> Well, I would consider that a responsibility of the release manager (or on
>>> release branches) now to figure that out. On trunk, things really need
>>> to
>>> be geared toward the day to day work of the developers doing the work and
>>> making changes and fixing bugs. For that, they need to be pointing at the
>>> snapshots for a variety of reasons:
>>>
>>> 1) Things like eclipse:eclipse will wire the projects together correctly so
>>> debugging and developing in the IDE works properly.
>>>
>>> 2) The tests (particularly the itests) actually test the code that is being
>>> developed on trunk. If a developer makes a change in a SNAPSHOT and runs
>>> the
>>> tests, it should test the changes, not some release made 3 months ago.
>>> This
>>> is very important to me. I want to be able to run "mvn test" before I
>>> commit
>>> and make sure everything works.
>>>
>>> 3) Related to (2), if a developer does make a change someplace, I really
>>> don't
>>> feel he should need to go off and find all the various places that need to
>>> be
>>> updated to make sure that change is fully tested.
>>>
>>> Remember, one of the goals of an Apache project is to expand the developer
>>> community. That is best done by making sure the a new developer can jump
>>> in
>>> easily and start contributing without jumping through major learning curves
>>> and wacky and non-standard policies to get there.
>>>
>>
>> This "wacky and non-standard" policy is there to ensure we can do the
>> "standard" OSGi practice of developing
>> independently releasable artefacts which are versioned using the standard
>> OSGi semantic versioning practice.
>> The goal here is different from yours. If we move everything up all the
>> time we may "know" that it works against
>> the latest, but it probably (in some cases certainly) no longer works
>> against the prior release of dependencies. So
>> we want to ensure we only up the dependency when we need a new capability
>> from it.
>>
>> I guess the downside is testing against the latest, so we need a solution
>> to that, but it isn't to break our ability to work
>> with compatible prior releases of dependencies.
>>
>>
>>>
>>>
>>>
>>> Daniel Kulp
>>> dkulp@apache.org - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>>>
>>
>>
>>
>> --
>> Alasdair Nottingham
>> not@apache.org
>