|
View:
New views
6 Messages
—
Rating Filter:
Alert me
|
|
|
How to build custom inhouse maven release?Hello,
I just submitted a patch for this bug: http://jira.codehaus.org/browse/MNG-3559 I don't know if it is the 'correct' fix, but it does the job for my issue. Unfortunately, I can't want for a new Maven release, so I need to build an in-house version with this patch to deploy to my development team. I'm building off the maven 2.0.9 tag, and tried tweaking the top level pom's version to be 2.0.9.1 and that didn't seem to work (mvn package still built 2.0.9). How would I change the Maven version number? Is there a best practice for naming an in house version? I was thinking of something like 2.0.9-kiva-1. Last question: Is there any way I can ease deployment of this version via our shared in-house repository? If it was a plugin I would just upload it into the repo and change our project's dependency, but in this case its Maven it self. I think I need everyone to download the tar.bz or zip and install it, right? Thanks, Josh -- Joshua ChaitinPollak | Software Engineer Kiva Systems, Inc., 225 Wildwood Ave, Woburn, MA 01970 |
|
|
Re: How to build custom inhouse maven release?I'd like to know too. I'm also using a custom version.
I am waiting on: http://jira.codehaus.org/browse/MNG-3380 On 4/30/08, Joshua ChaitinPollak <jpollak@...> wrote: > > Hello, > > I just submitted a patch for this bug: > > http://jira.codehaus.org/browse/MNG-3559 > > I don't know if it is the 'correct' fix, but it does the job for my issue. > > Unfortunately, I can't want for a new Maven release, so I need to build an > in-house version with this patch to deploy to my development team. I'm > building off the maven 2.0.9 tag, and tried tweaking the top level pom's > version to be 2.0.9.1 and that didn't seem to work (mvn package still > built 2.0.9). > > How would I change the Maven version number? > > Is there a best practice for naming an in house version? I was thinking of > something like 2.0.9-kiva-1. > > Last question: Is there any way I can ease deployment of this version via > our shared in-house repository? If it was a plugin I would just upload it > into the repo and change our project's dependency, but in this case its > Maven it self. I think I need everyone to download the tar.bz or zip and > install it, right? > > Thanks, > > Josh > > -- > Joshua ChaitinPollak | Software Engineer > Kiva Systems, Inc., 225 Wildwood Ave, Woburn, MA 01970 > > > > > > > |
|
|
RE: How to build custom inhouse maven release?Change all the 2.0.9's you find in there...there is also a property in
the root pom that has 2.0.9. -----Original Message----- From: Luke Patterson [mailto:lukewpatterson@...] Sent: Wednesday, April 30, 2008 10:20 AM To: Maven Developers List Subject: Re: How to build custom inhouse maven release? I'd like to know too. I'm also using a custom version. I am waiting on: http://jira.codehaus.org/browse/MNG-3380 On 4/30/08, Joshua ChaitinPollak <jpollak@...> wrote: > > Hello, > > I just submitted a patch for this bug: > > http://jira.codehaus.org/browse/MNG-3559 > > I don't know if it is the 'correct' fix, but it does the job for my issue. > > Unfortunately, I can't want for a new Maven release, so I need to build an > in-house version with this patch to deploy to my development team. I'm > building off the maven 2.0.9 tag, and tried tweaking the top level pom's > version to be 2.0.9.1 and that didn't seem to work (mvn package still > built 2.0.9). > > How would I change the Maven version number? > > Is there a best practice for naming an in house version? I was thinking of > something like 2.0.9-kiva-1. > > Last question: Is there any way I can ease deployment of this version via > our shared in-house repository? If it was a plugin I would just upload it > into the repo and change our project's dependency, but in this case its > Maven it self. I think I need everyone to download the tar.bz or zip and > install it, right? > > Thanks, > > Josh > > -- > Joshua ChaitinPollak | Software Engineer > Kiva Systems, Inc., 225 Wildwood Ave, Woburn, MA 01970 > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: How to build custom inhouse maven release?as for standard versioning in this case, its never going to see the
light of day outside your organization so whatever is fine..fwiw I think maven-2.0.9-kiva-1 is fine. jesse On Wed, Apr 30, 2008 at 9:27 AM, Brian E. Fox <brianf@...> wrote: > Change all the 2.0.9's you find in there...there is also a property in > the root pom that has 2.0.9. > > > > -----Original Message----- > From: Luke Patterson [mailto:lukewpatterson@...] > Sent: Wednesday, April 30, 2008 10:20 AM > To: Maven Developers List > Subject: Re: How to build custom inhouse maven release? > > I'd like to know too. I'm also using a custom version. > > I am waiting on: > > http://jira.codehaus.org/browse/MNG-3380 > > > On 4/30/08, Joshua ChaitinPollak <jpollak@...> wrote: > > > > Hello, > > > > I just submitted a patch for this bug: > > > > http://jira.codehaus.org/browse/MNG-3559 > > > > I don't know if it is the 'correct' fix, but it does the job for my > issue. > > > > Unfortunately, I can't want for a new Maven release, so I need to > build an > > in-house version with this patch to deploy to my development team. I'm > > building off the maven 2.0.9 tag, and tried tweaking the top level > pom's > > version to be 2.0.9.1 and that didn't seem to work (mvn package still > > built 2.0.9). > > > > How would I change the Maven version number? > > > > Is there a best practice for naming an in house version? I was > thinking of > > something like 2.0.9-kiva-1. > > > > Last question: Is there any way I can ease deployment of this version > via > > our shared in-house repository? If it was a plugin I would just upload > it > > into the repo and change our project's dependency, but in this case > its > > Maven it self. I think I need everyone to download the tar.bz or zip > and > > install it, right? > > > > Thanks, > > > > Josh > > > > -- > > Joshua ChaitinPollak | Software Engineer > > Kiva Systems, Inc., 225 Wildwood Ave, Woburn, MA 01970 > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > > -- jesse mcconnell jesse.mcconnell@... --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: How to build custom inhouse maven release?The better question is what will it take to get the patches applied? I
took a glance at 3559 and nothing jumped out and bit me. However, I'd like other feedback, plus I'd be hesitant to apply it without the patch having a test case included to verify the fix. I don't have the bandwidth right now to convert the demo project into an integration test. Ralph Luke Patterson wrote: > I'd like to know too. I'm also using a custom version. > > I am waiting on: > > http://jira.codehaus.org/browse/MNG-3380 > > > On 4/30/08, Joshua ChaitinPollak <jpollak@...> wrote: > >> Hello, >> >> I just submitted a patch for this bug: >> >> http://jira.codehaus.org/browse/MNG-3559 >> >> I don't know if it is the 'correct' fix, but it does the job for my issue. >> >> Unfortunately, I can't want for a new Maven release, so I need to build an >> in-house version with this patch to deploy to my development team. I'm >> building off the maven 2.0.9 tag, and tried tweaking the top level pom's >> version to be 2.0.9.1 and that didn't seem to work (mvn package still >> built 2.0.9). >> >> How would I change the Maven version number? >> >> Is there a best practice for naming an in house version? I was thinking of >> something like 2.0.9-kiva-1. >> >> Last question: Is there any way I can ease deployment of this version via >> our shared in-house repository? If it was a plugin I would just upload it >> into the repo and change our project's dependency, but in this case its >> Maven it self. I think I need everyone to download the tar.bz or zip and >> install it, right? >> >> Thanks, >> >> Josh >> >> -- >> Joshua ChaitinPollak | Software Engineer >> Kiva Systems, Inc., 225 Wildwood Ave, Woburn, MA 01970 >> >> >> >> >> >> >> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: How to build custom inhouse maven release?On May 1, 2008, at 1:15 AM, Ralph Goers wrote:
> The better question is what will it take to get the patches applied? > I took a glance at 3559 and nothing jumped out and bit me. Well, that's obviously in the back of my mind, but I didn't want to jump onto the dev list as a newbie and start hollering "apply my patch, apply my patch"... :) > However, I'd like other feedback, plus I'd be hesitant to apply it > without the patch having a test case included to verify the fix. I > don't have the bandwidth right now to convert the demo project into > an integration test. I'm not sure how the Maven IT's work, but I'll take a look at it and see if I can roll one out, although I've spent two solid weeks on our migration to Maven and I'm pretty sure my boss wants me actually writing code. :) Also, being my first Maven-internal edit I'm not sure the patch, while functional, is exactly the right change. It strikes me from a design perspective that it might make more sense in the long run to treat the "test-jar" artifact as an MavenProject object of its own internally. I'm not really sure about that, but it does seem odd to be special casing the ActiveProjectArtifact.getFile() function based on the Artifact's getFile(). On the other hand, I guess its ok, because you aren't risking an explosion of special cases for other artifact types. -Josh > Ralph > > Luke Patterson wrote: >> I'd like to know too. I'm also using a custom version. >> >> I am waiting on: >> >> http://jira.codehaus.org/browse/MNG-3380 >> >> >> On 4/30/08, Joshua ChaitinPollak <jpollak@...> wrote: >> >>> Hello, >>> >>> I just submitted a patch for this bug: >>> >>> http://jira.codehaus.org/browse/MNG-3559 >>> >>> I don't know if it is the 'correct' fix, but it does the job for >>> my issue. >>> >>> Unfortunately, I can't want for a new Maven release, so I need to >>> build an >>> in-house version with this patch to deploy to my development team. >>> I'm >>> building off the maven 2.0.9 tag, and tried tweaking the top level >>> pom's >>> version to be 2.0.9.1 and that didn't seem to work (mvn package >>> still >>> built 2.0.9). >>> >>> How would I change the Maven version number? >>> >>> Is there a best practice for naming an in house version? I was >>> thinking of >>> something like 2.0.9-kiva-1. >>> >>> Last question: Is there any way I can ease deployment of this >>> version via >>> our shared in-house repository? If it was a plugin I would just >>> upload it >>> into the repo and change our project's dependency, but in this >>> case its >>> Maven it self. I think I need everyone to download the tar.bz or >>> zip and >>> install it, right? >>> >>> Thanks, >>> >>> Josh >>> >>> -- >>> Joshua ChaitinPollak | Software Engineer >>> Kiva Systems, Inc., 225 Wildwood Ave, Woburn, MA 01970 >>> >>> >>> >>> >>> >>> >>> >>> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > > -- Joshua ChaitinPollak | Software Engineer Kiva Systems, Inc., 225 Wildwood Ave, Woburn, MA 01970 |
| Free Forum Powered by Nabble | Forum Help |