You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Trevor Harmon <tr...@vocaro.com> on 2008/12/23 16:32:26 UTC
Deploying a customized plugin
There's a plugin I'd like to use, but it has some bugs that prevent me
from doing so. Fortunately, it's an open-source plugin, so I was able
to fix the bugs, but I'm not sure how to make the fixes available to
others on my team. Although I've submitted bug reports, there's no
telling when (or if) the bugs will be fixed upstream.
I assume the best option is to change the version of my bug-fixed
plugin, deploy it to the team's repository, and have the other
developers reference this custom version number rather than the one on
Central. Then, if the same bugs are ever fixed upstream, the
developers can simply reference that version instead, and the one on
the team repository will no longer be used.
Is that the right course of action? If so, is there a convention on
how to choose a version number for this customized plugin? Thanks,
Trevor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Deploying a customized plugin
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
If I'm not changing the source, then I like to use the scm version of
the source I pulled from the external source. That way I can always go
back and easily update it. Something like 3.5.1-vocaro-[svnrev]. This
saves me from having to pull the whole source into my scm. (provided I
trust the remote won't disappear) In your case you will probably need to
check it in anyway since you're making changes so the scm rev is
probably not usefull.
-----Original Message-----
From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
Sent: Tuesday, December 23, 2008 11:26 AM
To: Maven Users List
Subject: Re: Deploying a customized plugin
2008/12/23 Stephen Connolly <st...@gmail.com>
> Take the current version number, e.g. 1.0-SNAPSHOT and replace the
> -SNAPSHOT with -yourcompany-1
>
> Thus.... as you work for vocaro....
>
> if the plugin's SCM version that you've modified is 3.5.1-SNAPSHOT,
you
> would release it as 3.5.1-vocaro-1
>
> I would add that if you intend doing more that 10 such patch releases,
> start with 3.5.1-vocaro-01
>
> Also, have a look at how maven specifies version numbers... some
plugins
> don't understand this and you will have problems with them if they
don't
> stick to the [major].[minor].[update]-[descriptor or build number]
BTW, the importance of this is when there is a real release.
in fact as I think about this more... i'd nearly recommend using
3.5.1-aavocaro-01
that way if they release 3.5.1-alpha-01 after your release then Maven's
version sorting rules will be ok...
if you are patching an alpha release e.g. 3.5.1-alpha-2-SNAPSHOT... you
can
do
3.5.1-alpha-2-vocaro-01
>
>
> essentially, you are doing the "vocaro-01" release as opposed to the
> "alpha-01" release or the "beta-03" release
>
> 2008/12/23 Trevor Harmon <tr...@vocaro.com>
>
> There's a plugin I'd like to use, but it has some bugs that prevent me
from
>> doing so. Fortunately, it's an open-source plugin, so I was able to
fix the
>> bugs, but I'm not sure how to make the fixes available to others on
my team.
>> Although I've submitted bug reports, there's no telling when (or if)
the
>> bugs will be fixed upstream.
>>
>> I assume the best option is to change the version of my bug-fixed
plugin,
>> deploy it to the team's repository, and have the other developers
reference
>> this custom version number rather than the one on Central. Then, if
the same
>> bugs are ever fixed upstream, the developers can simply reference
that
>> version instead, and the one on the team repository will no longer be
used.
>>
>> Is that the right course of action? If so, is there a convention on
how to
>> choose a version number for this customized plugin? Thanks,
>>
>> Trevor
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Deploying a customized plugin
Posted by Stephen Connolly <st...@gmail.com>.
2008/12/23 Stephen Connolly <st...@gmail.com>
> Take the current version number, e.g. 1.0-SNAPSHOT and replace the
> -SNAPSHOT with -yourcompany-1
>
> Thus.... as you work for vocaro....
>
> if the plugin's SCM version that you've modified is 3.5.1-SNAPSHOT, you
> would release it as 3.5.1-vocaro-1
>
> I would add that if you intend doing more that 10 such patch releases,
> start with 3.5.1-vocaro-01
>
> Also, have a look at how maven specifies version numbers... some plugins
> don't understand this and you will have problems with them if they don't
> stick to the [major].[minor].[update]-[descriptor or build number]
BTW, the importance of this is when there is a real release.
in fact as I think about this more... i'd nearly recommend using
3.5.1-aavocaro-01
that way if they release 3.5.1-alpha-01 after your release then Maven's
version sorting rules will be ok...
if you are patching an alpha release e.g. 3.5.1-alpha-2-SNAPSHOT... you can
do
3.5.1-alpha-2-vocaro-01
>
>
> essentially, you are doing the "vocaro-01" release as opposed to the
> "alpha-01" release or the "beta-03" release
>
> 2008/12/23 Trevor Harmon <tr...@vocaro.com>
>
> There's a plugin I'd like to use, but it has some bugs that prevent me from
>> doing so. Fortunately, it's an open-source plugin, so I was able to fix the
>> bugs, but I'm not sure how to make the fixes available to others on my team.
>> Although I've submitted bug reports, there's no telling when (or if) the
>> bugs will be fixed upstream.
>>
>> I assume the best option is to change the version of my bug-fixed plugin,
>> deploy it to the team's repository, and have the other developers reference
>> this custom version number rather than the one on Central. Then, if the same
>> bugs are ever fixed upstream, the developers can simply reference that
>> version instead, and the one on the team repository will no longer be used.
>>
>> Is that the right course of action? If so, is there a convention on how to
>> choose a version number for this customized plugin? Thanks,
>>
>> Trevor
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
Re: Deploying a customized plugin
Posted by Stephen Connolly <st...@gmail.com>.
Take the current version number, e.g. 1.0-SNAPSHOT and replace the -SNAPSHOT
with -yourcompany-1
Thus.... as you work for vocaro....
if the plugin's SCM version that you've modified is 3.5.1-SNAPSHOT, you
would release it as 3.5.1-vocaro-1
I would add that if you intend doing more that 10 such patch releases, start
with 3.5.1-vocaro-01
Also, have a look at how maven specifies version numbers... some plugins
don't understand this and you will have problems with them if they don't
stick to the [major].[minor].[update]-[descriptor or build number]
essentially, you are doing the "vocaro-01" release as opposed to the
"alpha-01" release or the "beta-03" release
2008/12/23 Trevor Harmon <tr...@vocaro.com>
> There's a plugin I'd like to use, but it has some bugs that prevent me from
> doing so. Fortunately, it's an open-source plugin, so I was able to fix the
> bugs, but I'm not sure how to make the fixes available to others on my team.
> Although I've submitted bug reports, there's no telling when (or if) the
> bugs will be fixed upstream.
>
> I assume the best option is to change the version of my bug-fixed plugin,
> deploy it to the team's repository, and have the other developers reference
> this custom version number rather than the one on Central. Then, if the same
> bugs are ever fixed upstream, the developers can simply reference that
> version instead, and the one on the team repository will no longer be used.
>
> Is that the right course of action? If so, is there a convention on how to
> choose a version number for this customized plugin? Thanks,
>
> Trevor
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>