RE: Deploying a customized plugin
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.conno...@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 stephen.alan.conno...@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 tre...@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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Deploying a customized plugin
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 tre...@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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Deploying a customized plugin
2008/12/23 Stephen Connolly stephen.alan.conno...@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 tre...@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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
