You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Stephen Connolly <st...@gmail.com> on 2008/07/17 14:35:17 UTC
How do I go about contributing a plugin to mojo?
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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: How do I go about contributing a plugin to mojo?
Posted by Stephen Connolly <st...@gmail.com>.
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
<st...@gmail.com> 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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: How do I go about contributing a plugin to mojo?
Posted by Oleg Gusakov <ol...@gmail.com>.
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.
Ralph, if you start using OSGi builds, you will be unpleasantly
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@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges (was Re: How do I go about contributing a plugin to mojo?)
Posted by Jason van Zyl <ja...@maven.org>.
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@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Version ranges (was Re: How do I go about contributing a plugin to
mojo?)
Posted by Ralph Goers <Ra...@dslextreme.com>.
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 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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: How do I go about contributing a plugin to mojo?
Posted by Jason van Zyl <ja...@maven.org>.
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@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: How do I go about contributing a plugin to mojo?
Posted by Ralph Goers <Ra...@dslextreme.com>.
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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: How do I go about contributing a plugin to mojo?
Posted by Stephen Connolly <st...@gmail.com>.
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
<st...@gmail.com> 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 <br...@reply.infinity.nu> 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@gmail.com]
>> 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
>> <st...@gmail.com> 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
>>> <st...@gmail.com> 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 <gh...@apache.org>
>> 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@apache.org
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: How do I go about contributing a plugin to mojo?
Posted by Stephen Connolly <st...@gmail.com>.
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 <br...@reply.infinity.nu> 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@gmail.com]
> 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
> <st...@gmail.com> 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
>> <st...@gmail.com> 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 <gh...@apache.org>
> 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@apache.org
>>>>
>>>>
> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: How do I go about contributing a plugin to mojo?
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
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@gmail.com]
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
<st...@gmail.com> 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
> <st...@gmail.com> 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 <gh...@apache.org>
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@apache.org
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: How do I go about contributing a plugin to mojo?
Posted by Stephen Connolly <st...@gmail.com>.
Anyway, my question is how do I go about contributing this?
On Thu, Jul 17, 2008 at 3:01 PM, Stephen Connolly
<st...@gmail.com> 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
> <st...@gmail.com> 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 <gh...@apache.org> 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@apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: How do I go about contributing a plugin to mojo?
Posted by Stephen Connolly <st...@gmail.com>.
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
<st...@gmail.com> 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 <gh...@apache.org> 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@apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: How do I go about contributing a plugin to mojo?
Posted by Stephen Connolly <st...@gmail.com>.
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 <gh...@apache.org> 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@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: How do I go about contributing a plugin to mojo?
Posted by Michael McCallum <gh...@apache.org>.
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@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org