|
»
»
»
How do I go about contributing a plugin to mojo?
|
View:
New views
14 Messages
—
Rating Filter:
Alert me
|
 |
How do I go about contributing a plugin to mojo?
by Stephen Connolly-2
::
Rate this Message:
I have developed a plugin that makes keeping versions of related but
not quite tightly coupled in sync a lot easier. How do I go about contributing this to mojo? -Stephen FYI here's how it works... In your pom you probably have a property used to define the version in one place, for example: <project> ... <dependencyManagement> <dependency> <groupId>blah</groupId> <artifactId>blah-core</artifactId> <version>${blah.version}</version> </dependency> <dependency> <groupId>blah</groupId> <artifactId>blah-logging</artifactId> <version>${blah.version}</version> </dependency> <dependency> <groupId>blah</groupId> <artifactId>blah-reporting</artifactId> <version>${blah.version}</version> </dependency> </dependencyManagement> ... <properties> <blah.version>1.3.4</blah.version> </properties> ... </project> That way you can update the version in one place and not forget any of them. My plugin... which I'm calling properties-maven-plugin for now (if somebody has a better name, I'm more than welcome to hear it) allows you to define what artifact to base property values off... so if we added ... <build> ... <plugins> ... <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>properties-maven-plugin</artifactId> <configuration> <linkedItems> <linkedItem> <property>blah.version</property> <groupId>blah</groupId> <artifactId>blah-core</artifactId> </linkedItem> </linkedItems> </configuration> </plugin> ... </plugins> ... </build> ... Then by running "mvn properties:use-latest" will rewrite the pom so that blah.version is the latest version available to you while "mvn properties:use-latest-releases" will rewrite the pom so that blah.version is the latest non -SNAPSHOT version available. You could then run a build and see if everything is OK before finally doing a checkin using the scm plugin! The plugin also has two other goals... "mvn properties:use-latest-parent" which will update the parent of any project who's parent is not in the reactor to the latest version available to you, while "mvn properties:use-latest-parent-release" will update to the latest non -SNAPSHOT. Note: this will only affect projects who's parent is external to the reactor (for example a corporate pom) Oh... and if you want to prevent jumping too high in versions or too low, it supports adding a version specification to limit things. e.g. <linkedItem> <property>blah.version</property> <groupId>blah</groupId> <artifactId>blah-core</artifactId> <version>[1.3.2,1.4.0-!)</version> </linkedItem> will only update blah.version within the 1.3 stream and must update to at least 1.3.2 If a matching version cannot be found it will leave things as they are. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: How do I go about contributing a plugin to mojo?
by Stephen Connolly-2
::
Rate this Message:
Oh and -Dproperties=blah.version,foo.version will only do the update
check for ${blah.version} and ${foo.version} On Thu, Jul 17, 2008 at 1:35 PM, Stephen Connolly <stephen.alan.connolly@...> wrote: > I have developed a plugin that makes keeping versions of related but > not quite tightly coupled in sync a lot easier. > > How do I go about contributing this to mojo? > > -Stephen > > FYI here's how it works... > > In your pom you probably have a property used to define the version in > one place, for example: > > <project> > ... > <dependencyManagement> > <dependency> > <groupId>blah</groupId> > <artifactId>blah-core</artifactId> > <version>${blah.version}</version> > </dependency> > <dependency> > <groupId>blah</groupId> > <artifactId>blah-logging</artifactId> > <version>${blah.version}</version> > </dependency> > <dependency> > <groupId>blah</groupId> > <artifactId>blah-reporting</artifactId> > <version>${blah.version}</version> > </dependency> > </dependencyManagement> > ... > <properties> > <blah.version>1.3.4</blah.version> > </properties> > ... > </project> > > That way you can update the version in one place and not forget any of them. > > My plugin... which I'm calling properties-maven-plugin for now (if > somebody has a better name, I'm more than welcome to hear it) > > allows you to define what artifact to base property values off... so if we added > > ... > <build> > ... > <plugins> > ... > <plugin> > <groupId>org.codehaus.mojo</groupId> > <artifactId>properties-maven-plugin</artifactId> > <configuration> > <linkedItems> > <linkedItem> > <property>blah.version</property> > <groupId>blah</groupId> > <artifactId>blah-core</artifactId> > </linkedItem> > </linkedItems> > </configuration> > </plugin> > ... > </plugins> > ... > </build> > ... > > Then by running "mvn properties:use-latest" will rewrite the pom so > that blah.version is the latest version available to you while "mvn > properties:use-latest-releases" will rewrite the pom so that > blah.version is the latest non -SNAPSHOT version available. > > You could then run a build and see if everything is OK before finally > doing a checkin using the scm plugin! > > The plugin also has two other goals... > > "mvn properties:use-latest-parent" which will update the parent of any > project who's parent is not in the reactor to the latest version > available to you, while "mvn properties:use-latest-parent-release" > will update to the latest non -SNAPSHOT. > Note: this will only affect projects who's parent is external to the > reactor (for example a corporate pom) > > Oh... and if you want to prevent jumping too high in versions or too > low, it supports adding a version specification to limit things. > > e.g. > <linkedItem> > <property>blah.version</property> > <groupId>blah</groupId> > <artifactId>blah-core</artifactId> > <version>[1.3.2,1.4.0-!)</version> > </linkedItem> > > will only update blah.version within the 1.3 stream and must update to > at least 1.3.2 > > If a matching version cannot be found it will leave things as they are. > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: How do I go about contributing a plugin to mojo?
by Michael McCallum-3
::
Rate this Message:
why not just specify the dependencies with version ranges, if you do there is
no need to rewrite anything it just works... On Fri, 18 Jul 2008 00:35:17 Stephen Connolly wrote: > > Oh... and if you want to prevent jumping too high in versions or too > low, it supports adding a version specification to limit things. > -- Michael McCallum Enterprise Engineer mailto:gholam@... --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: How do I go about contributing a plugin to mojo?
by Stephen Connolly-2
::
Rate this Message:
And then when you want to roll a release?
Anyway, if that was the case why is it that most of the maven plugins themselves use this pattern? e.g. <version>${maven.version}</version> Also you may want to force all one set of components to the same suite release... so blah-core may be only available at 1.3.5 while blah-logging may be at 1.3.7 -Stephen On Thu, Jul 17, 2008 at 1:52 PM, Michael McCallum <gholam@...> wrote: > why not just specify the dependencies with version ranges, if you do there is > no need to rewrite anything it just works... > > On Fri, 18 Jul 2008 00:35:17 Stephen Connolly wrote: >> >> Oh... and if you want to prevent jumping too high in versions or too >> low, it supports adding a version specification to limit things. >> > > > > -- > Michael McCallum > Enterprise Engineer > mailto:gholam@... > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: How do I go about contributing a plugin to mojo?
by Stephen Connolly-2
::
Rate this Message:
one use case for this is when you have a suite of components and you
want to force _all_ of them to the same version. Perhaps you have several suites of components and you want to force all the components in each suite to the same versions across the suite. On Thu, Jul 17, 2008 at 2:56 PM, Stephen Connolly <stephen.alan.connolly@...> wrote: > And then when you want to roll a release? > > Anyway, if that was the case why is it that most of the maven plugins > themselves use this pattern? > > e.g. <version>${maven.version}</version> > > Also you may want to force all one set of components to the same suite > release... so blah-core may be only available at 1.3.5 while > blah-logging may be at 1.3.7 > > -Stephen > > On Thu, Jul 17, 2008 at 1:52 PM, Michael McCallum <gholam@...> wrote: >> why not just specify the dependencies with version ranges, if you do there is >> no need to rewrite anything it just works... >> >> On Fri, 18 Jul 2008 00:35:17 Stephen Connolly wrote: >>> >>> Oh... and if you want to prevent jumping too high in versions or too >>> low, it supports adding a version specification to limit things. >>> >> >> >> >> -- >> Michael McCallum >> Enterprise Engineer >> mailto:gholam@... >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@... >> For additional commands, e-mail: dev-help@... >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: How do I go about contributing a plugin to mojo?
by Stephen Connolly-2
::
Rate this Message:
Anyway, my question is how do I go about contributing this?
On Thu, Jul 17, 2008 at 3:01 PM, Stephen Connolly <stephen.alan.connolly@...> wrote: > one use case for this is when you have a suite of components and you > want to force _all_ of them to the same version. > > Perhaps you have several suites of components and you want to force > all the components in each suite to the same versions across the > suite. > > On Thu, Jul 17, 2008 at 2:56 PM, Stephen Connolly > <stephen.alan.connolly@...> wrote: >> And then when you want to roll a release? >> >> Anyway, if that was the case why is it that most of the maven plugins >> themselves use this pattern? >> >> e.g. <version>${maven.version}</version> >> >> Also you may want to force all one set of components to the same suite >> release... so blah-core may be only available at 1.3.5 while >> blah-logging may be at 1.3.7 >> >> -Stephen >> >> On Thu, Jul 17, 2008 at 1:52 PM, Michael McCallum <gholam@...> wrote: >>> why not just specify the dependencies with version ranges, if you do there is >>> no need to rewrite anything it just works... >>> >>> On Fri, 18 Jul 2008 00:35:17 Stephen Connolly wrote: >>>> >>>> Oh... and if you want to prevent jumping too high in versions or too >>>> low, it supports adding a version specification to limit things. >>>> >>> >>> >>> >>> -- >>> Michael McCallum >>> Enterprise Engineer >>> mailto:gholam@... >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@... >>> For additional commands, e-mail: dev-help@... >>> >>> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
RE: How do I go about contributing a plugin to mojo?
by Brian E Fox
::
Rate this Message:
You would attach it to a jira at the mojo.codehaus.org project and then
try to get some mojo committer to pick it up. -----Original Message----- From: Stephen Connolly [mailto:stephen.alan.connolly@...] Sent: Thursday, July 17, 2008 10:02 AM To: Maven Developers List Subject: Re: How do I go about contributing a plugin to mojo? Anyway, my question is how do I go about contributing this? On Thu, Jul 17, 2008 at 3:01 PM, Stephen Connolly <stephen.alan.connolly@...> wrote: > one use case for this is when you have a suite of components and you > want to force _all_ of them to the same version. > > Perhaps you have several suites of components and you want to force > all the components in each suite to the same versions across the > suite. > > On Thu, Jul 17, 2008 at 2:56 PM, Stephen Connolly > <stephen.alan.connolly@...> wrote: >> And then when you want to roll a release? >> >> Anyway, if that was the case why is it that most of the maven plugins >> themselves use this pattern? >> >> e.g. <version>${maven.version}</version> >> >> Also you may want to force all one set of components to the same >> release... so blah-core may be only available at 1.3.5 while >> blah-logging may be at 1.3.7 >> >> -Stephen >> >> On Thu, Jul 17, 2008 at 1:52 PM, Michael McCallum <gholam@...> wrote: >>> why not just specify the dependencies with version ranges, if you do there is >>> no need to rewrite anything it just works... >>> >>> On Fri, 18 Jul 2008 00:35:17 Stephen Connolly wrote: >>>> >>>> Oh... and if you want to prevent jumping too high in versions or too >>>> low, it supports adding a version specification to limit things. >>>> >>> >>> >>> >>> -- >>> Michael McCallum >>> Enterprise Engineer >>> mailto:gholam@... >>> >>> >>> To unsubscribe, e-mail: dev-unsubscribe@... >>> For additional commands, e-mail: dev-help@... >>> >>> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: How do I go about contributing a plugin to mojo?
by Stephen Connolly-2
::
Rate this Message:
OK, so... i'll give that a shot once I reformat it to the Maven code style!
On Thu, Jul 17, 2008 at 3:04 PM, Brian E. Fox <brianf@...> wrote: > You would attach it to a jira at the mojo.codehaus.org project and then > try to get some mojo committer to pick it up. > > -----Original Message----- > From: Stephen Connolly [mailto:stephen.alan.connolly@...] > Sent: Thursday, July 17, 2008 10:02 AM > To: Maven Developers List > Subject: Re: How do I go about contributing a plugin to mojo? > > Anyway, my question is how do I go about contributing this? > > On Thu, Jul 17, 2008 at 3:01 PM, Stephen Connolly > <stephen.alan.connolly@...> wrote: >> one use case for this is when you have a suite of components and you >> want to force _all_ of them to the same version. >> >> Perhaps you have several suites of components and you want to force >> all the components in each suite to the same versions across the >> suite. >> >> On Thu, Jul 17, 2008 at 2:56 PM, Stephen Connolly >> <stephen.alan.connolly@...> wrote: >>> And then when you want to roll a release? >>> >>> Anyway, if that was the case why is it that most of the maven plugins >>> themselves use this pattern? >>> >>> e.g. <version>${maven.version}</version> >>> >>> Also you may want to force all one set of components to the same > suite >>> release... so blah-core may be only available at 1.3.5 while >>> blah-logging may be at 1.3.7 >>> >>> -Stephen >>> >>> On Thu, Jul 17, 2008 at 1:52 PM, Michael McCallum <gholam@...> > wrote: >>>> why not just specify the dependencies with version ranges, if you do > there is >>>> no need to rewrite anything it just works... >>>> >>>> On Fri, 18 Jul 2008 00:35:17 Stephen Connolly wrote: >>>>> >>>>> Oh... and if you want to prevent jumping too high in versions or > too >>>>> low, it supports adding a version specification to limit things. >>>>> >>>> >>>> >>>> >>>> -- >>>> Michael McCallum >>>> Enterprise Engineer >>>> mailto:gholam@... >>>> >>>> > --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>> For additional commands, e-mail: dev-help@... >>>> >>>> >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: How do I go about contributing a plugin to mojo?
by Ralph Goers
::
Rate this Message:
Michael McCallum wrote: > why not just specify the dependencies with version ranges, if you do there is > no need to rewrite anything it just works... > > My builds never use version ranges. We require that builds be reproduceable at any time in the future. Version ranges don't guarantee that. Ralph --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: How do I go about contributing a plugin to mojo?
by Oleg Gusakov
::
Rate this Message:
Ralph Goers wrote: > > > Michael McCallum wrote: >> why not just specify the dependencies with version ranges, if you do >> there is no need to rewrite anything it just works... >> >> > My builds never use version ranges. We require that builds be > reproduceable at any time in the future. Version ranges don't > guarantee that. surprised by the OSGi spec, which states that version 1.2.3 means [1.2.3,) i.e. anything greater or equal to 1.2.3 ( See table 3.1 on page 29-278 of core spec 4.1, April 2007 ) The only way to guarantee your build reproducibility will be using ranges like [1.2.3,1.2.3] :) I am seriously considering the OSGi spec for Mercury, at least the ranges part. Oleg > > > Ralph > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: How do I go about contributing a plugin to mojo?
by Stephen Connolly-2
::
Rate this Message:
Done.
http://jira.codehaus.org/browse/MOJO-1178 if anyone wants to take a bite... On Thu, Jul 17, 2008 at 3:15 PM, Stephen Connolly <stephen.alan.connolly@...> wrote: > OK, so... i'll give that a shot once I reformat it to the Maven code style! > > On Thu, Jul 17, 2008 at 3:04 PM, Brian E. Fox <brianf@...> wrote: >> You would attach it to a jira at the mojo.codehaus.org project and then >> try to get some mojo committer to pick it up. >> >> -----Original Message----- >> From: Stephen Connolly [mailto:stephen.alan.connolly@...] >> Sent: Thursday, July 17, 2008 10:02 AM >> To: Maven Developers List >> Subject: Re: How do I go about contributing a plugin to mojo? >> >> Anyway, my question is how do I go about contributing this? >> >> On Thu, Jul 17, 2008 at 3:01 PM, Stephen Connolly >> <stephen.alan.connolly@...> wrote: >>> one use case for this is when you have a suite of components and you >>> want to force _all_ of them to the same version. >>> >>> Perhaps you have several suites of components and you want to force >>> all the components in each suite to the same versions across the >>> suite. >>> >>> On Thu, Jul 17, 2008 at 2:56 PM, Stephen Connolly >>> <stephen.alan.connolly@...> wrote: >>>> And then when you want to roll a release? >>>> >>>> Anyway, if that was the case why is it that most of the maven plugins >>>> themselves use this pattern? >>>> >>>> e.g. <version>${maven.version}</version> >>>> >>>> Also you may want to force all one set of components to the same >> suite >>>> release... so blah-core may be only available at 1.3.5 while >>>> blah-logging may be at 1.3.7 >>>> >>>> -Stephen >>>> >>>> On Thu, Jul 17, 2008 at 1:52 PM, Michael McCallum <gholam@...> >> wrote: >>>>> why not just specify the dependencies with version ranges, if you do >> there is >>>>> no need to rewrite anything it just works... >>>>> >>>>> On Fri, 18 Jul 2008 00:35:17 Stephen Connolly wrote: >>>>>> >>>>>> Oh... and if you want to prevent jumping too high in versions or >> too >>>>>> low, it supports adding a version specification to limit things. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Michael McCallum >>>>> Enterprise Engineer >>>>> mailto:gholam@... >>>>> >>>>> >> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>>> For additional commands, e-mail: dev-help@... >>>>> >>>>> >>>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@... >> For additional commands, e-mail: dev-help@... >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@... >> For additional commands, e-mail: dev-help@... >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: How do I go about contributing a plugin to mojo?
by Jason van Zyl-2
::
Rate this Message:
On 17-Jul-08, at 8:08 PM, Ralph Goers wrote: > > > Michael McCallum wrote: >> why not just specify the dependencies with version ranges, if you >> do there is no need to rewrite anything it just works... >> >> > My builds never use version ranges. We require that builds be > reproduceable at any time in the future. Version ranges don't > guarantee that. Version ranges by themselves don't guarantee anything, but I think what you're saying is that they don't guarantee a released versions artifacts being reproducible. The way OSGi works is that the ranges play a part at build time and runtime. During the time working up to a release ranges are useful to allow flexibility of testing new versions of code, much like the way snapshots work and at the time of release you can choose to lock the versions down. If you lock the versions down then there is no flexibility in the runtime to accept new versions. Oleg and I have been trying to work out a way where we can have our cake and eat it too: allow the flexibility of variable runtime versioning while keeping an exact list of what actually worked for a release. I think anyone who has been doing this for a while realizes that once a project has been QA'd it makes no sense to allow everything to vary. I think it's a hybrid of these approaches that will allow the most utility across build and deployment. > > > Ralph > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven jason at sonatype dot com ---------------------------------------------------------- A language that doesn’t affect the way you think about programming is not worth knowing. -— Alan Perlis --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Version ranges (was Re: How do I go about contributing a plugin to mojo?)
by Ralph Goers
::
Rate this Message:
Jason van Zyl wrote:
> > On 17-Jul-08, at 8:08 PM, Ralph Goers wrote: > >> >> >> Michael McCallum wrote: >>> why not just specify the dependencies with version ranges, if you do >>> there is no need to rewrite anything it just works... >>> >>> >> My builds never use version ranges. We require that builds be >> reproduceable at any time in the future. Version ranges don't >> guarantee that. > > Version ranges by themselves don't guarantee anything, but I think > what you're saying is that they don't guarantee a released versions > artifacts being reproducible. > > The way OSGi works is that the ranges play a part at build time and > runtime. During the time working up to a release ranges are useful to > allow flexibility of testing new versions of code, much like the way > snapshots work and at the time of release you can choose to lock the > versions down. If you lock the versions down then there is no > flexibility in the runtime to accept new versions. Oleg and I have > been trying to work out a way where we can have our cake and eat it > too: allow the flexibility of variable runtime versioning while > keeping an exact list of what actually worked for a release. I think > anyone who has been doing this for a while realizes that once a > project has been QA'd it makes no sense to allow everything to vary. I > think it's a hybrid of these approaches that will allow the most > utility across build and deployment. > little differently than a maven project build primarily because the bundle presumably has a larger granularity. In both cases though, I would want a version upgrade to be deliberately controlled. Even while in development we don't use version ranges. If we choose to upgrade the version of an artifact we do it in our third party pom's dependencyManagement and then retest. With OSGi I'd imagine doing more or less the same thing by installing the new bundle and testing long before QA. However, this would be done deliberately, not automagically. Ralph --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: Version ranges (was Re: How do I go about contributing a plugin to mojo?)
by Jason van Zyl-2
::
Rate this Message:
On 18-Jul-08, at 10:30 AM, Ralph Goers wrote: > Jason van Zyl wrote: >> >> On 17-Jul-08, at 8:08 PM, Ralph Goers wrote: >> >>> >>> >>> Michael McCallum wrote: >>>> why not just specify the dependencies with version ranges, if you >>>> do there is no need to rewrite anything it just works... >>>> >>>> >>> My builds never use version ranges. We require that builds be >>> reproduceable at any time in the future. Version ranges don't >>> guarantee that. >> >> Version ranges by themselves don't guarantee anything, but I think >> what you're saying is that they don't guarantee a released versions >> artifacts being reproducible. >> >> The way OSGi works is that the ranges play a part at build time and >> runtime. During the time working up to a release ranges are useful >> to allow flexibility of testing new versions of code, much like the >> way snapshots work and at the time of release you can choose to >> lock the versions down. If you lock the versions down then there is >> no flexibility in the runtime to accept new versions. Oleg and I >> have been trying to work out a way where we can have our cake and >> eat it too: allow the flexibility of variable runtime versioning >> while keeping an exact list of what actually worked for a release. >> I think anyone who has been doing this for a while realizes that >> once a project has been QA'd it makes no sense to allow everything >> to vary. I think it's a hybrid of these approaches that will allow >> the most utility across build and deployment. >> > That pretty much sums up what I am saying. I view an OSGi bundle a > little differently than a maven project build primarily because the > bundle presumably has a larger granularity. In can, and a lot of people I've seen use OSGi use ranges. > In both cases though, I would want a version upgrade to be > deliberately controlled. Even while in development we don't use > version ranges. If we choose to upgrade the version of an artifact > we do it in our third party pom's dependencyManagement and then > retest. With OSGi I'd imagine doing more or less the same thing by > installing the new bundle and testing long before QA. However, this > would be done deliberately, not automagically. Sure, this is sane for your 3rd party deps, but I think you have to be a little more dynamic while integrating team code. You just need to be able to track the point at which it was stable and lock it all down. Vary freely while in determination mode, when successful make that deterministically reproducible. > > > Ralph > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven jason at sonatype dot com ---------------------------------------------------------- What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. -- Paul Graham --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
| Free Forum Powered by Nabble | Forum Help |