Re: Best practices for release and version management?
2005/9/2, Jose Gonzalez Gomez <[EMAIL PROTECTED]>: > Hi there, > > How do you use to manage your project version among releases? I > mean... what do you exactly put in currentVersion in your pom and how > do you change it among releases? > > I'm currently using the following approach: > > 1. Developing version 0.1 - currentVersion = 0.1-SNAPSHOT > 2. V0.1 release: commit all pending changes, change currentVersion to > 0.1, commit pom, tag/branch repository, make release. > 3. Developing version 0.2 - change currentVersion to 0.2-SNAPSHOT, > commit pom, update and continue developing > > What do you think about this? This approach has one annoying thing: > maven tries to download SNAPSHOT versions from remote repositories, > although they're only locally installed in the developer repository. > After some timeout maven uses the local version, but in case of large > projects the sum of the timeouts may be big. Do you use any other > approach? > > Thanks in advance, best regards > Jose > After re-reading some of the maven documentation it seems I'm following the suggested approach (although manually, instead of using the scm plugin)... anyway, is there any way to force maven to use the local repository version of my own SNAPSHOT artifacts while still downloading external dependencies? Thanks in advance, best regards Jose - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practices for release and version management?
On Fri, Sep 02, 2005 at 11:46:49AM +0200, Jose Gonzalez Gomez wrote: > Hi there, > > How do you use to manage your project version among releases? I > mean... what do you exactly put in currentVersion in your pom and how > do you change it among releases? > > I'm currently using the following approach: > > 1. Developing version 0.1 - currentVersion = 0.1-SNAPSHOT > 2. V0.1 release: commit all pending changes, change currentVersion to > 0.1, commit pom, tag/branch repository, make release. > 3. Developing version 0.2 - change currentVersion to 0.2-SNAPSHOT, > commit pom, update and continue developing This is the way that we're recomending and using ourselfs. > What do you think about this? This approach has one annoying thing: > maven tries to download SNAPSHOT versions from remote repositories, > although they're only locally installed in the developer repository. > After some timeout maven uses the local version, but in case of large > projects the sum of the timeouts may be big. Do you use any other > approach? The easiest solution to this problem is to either configure a proxy so it doesn't time out (but rather get a 404 response from the HTTP server) or just run Maven in off-line mode (by using the -o switch) -- Trygve signature.asc Description: Digital signature
RE: Best practices for release and version management?
We're pretty much doing what Jose is doing, but we don't see these timeouts. I think it's because the Maven properties are set up to look in our internal repository first and then go global from there. Just about everything is in the internal repository (certainly the artifacts for our projects are there), so the download time isn't much at all. My maven.repo.remote property lists the internal repository first, and ibiblio second. As far as the approach to take when releasing and incrementing versions, the process you describe is essentially what we're doing. In fact, I just wrote up a document outlining our internal process for releasing projects for our developers (since we're about to release the big project soon), so I know the details very well. ..David.. -Original Message- From: Trygve Laugstøl [mailto:[EMAIL PROTECTED] Sent: Friday, September 02, 2005 4:14 AM To: Maven Users List Subject: Re: Best practices for release and version management? On Fri, Sep 02, 2005 at 11:46:49AM +0200, Jose Gonzalez Gomez wrote: > Hi there, > > How do you use to manage your project version among releases? I > mean... what do you exactly put in currentVersion in your pom and how > do you change it among releases? > > I'm currently using the following approach: > > 1. Developing version 0.1 - currentVersion = 0.1-SNAPSHOT 2. V0.1 > release: commit all pending changes, change currentVersion to 0.1, > commit pom, tag/branch repository, make release. > 3. Developing version 0.2 - change currentVersion to 0.2-SNAPSHOT, > commit pom, update and continue developing This is the way that we're recomending and using ourselfs. > What do you think about this? This approach has one annoying thing: > maven tries to download SNAPSHOT versions from remote repositories, > although they're only locally installed in the developer repository. > After some timeout maven uses the local version, but in case of large > projects the sum of the timeouts may be big. Do you use any other > approach? The easiest solution to this problem is to either configure a proxy so it doesn't time out (but rather get a 404 response from the HTTP server) or just run Maven in off-line mode (by using the -o switch) -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Best practices for release and version management?
How does one do it for m2? I am new to maven and I have decided to skip maven 1.x and start with m2 directly. -Moiz -Original Message- From: David Jackman [mailto:[EMAIL PROTECTED] Sent: Friday, September 02, 2005 7:00 AM To: Maven Users List Subject: RE: Best practices for release and version management? We're pretty much doing what Jose is doing, but we don't see these timeouts. I think it's because the Maven properties are set up to look in our internal repository first and then go global from there. Just about everything is in the internal repository (certainly the artifacts for our projects are there), so the download time isn't much at all. My maven.repo.remote property lists the internal repository first, and ibiblio second. As far as the approach to take when releasing and incrementing versions, the process you describe is essentially what we're doing. In fact, I just wrote up a document outlining our internal process for releasing projects for our developers (since we're about to release the big project soon), so I know the details very well. ..David.. -Original Message- From: Trygve Laugstøl [mailto:[EMAIL PROTECTED] Sent: Friday, September 02, 2005 4:14 AM To: Maven Users List Subject: Re: Best practices for release and version management? On Fri, Sep 02, 2005 at 11:46:49AM +0200, Jose Gonzalez Gomez wrote: > Hi there, > > How do you use to manage your project version among releases? I > mean... what do you exactly put in currentVersion in your pom and how > do you change it among releases? > > I'm currently using the following approach: > > 1. Developing version 0.1 - currentVersion = 0.1-SNAPSHOT 2. V0.1 > release: commit all pending changes, change currentVersion to 0.1, > commit pom, tag/branch repository, make release. > 3. Developing version 0.2 - change currentVersion to 0.2-SNAPSHOT, > commit pom, update and continue developing This is the way that we're recomending and using ourselfs. > What do you think about this? This approach has one annoying thing: > maven tries to download SNAPSHOT versions from remote repositories, > although they're only locally installed in the developer repository. > After some timeout maven uses the local version, but in case of large > projects the sum of the timeouts may be big. Do you use any other > approach? The easiest solution to this problem is to either configure a proxy so it doesn't time out (but rather get a 404 response from the HTTP server) or just run Maven in off-line mode (by using the -o switch) -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practices for release and version management?
On Fri, Sep 02, 2005 at 10:54:37AM -0400, dohadwala, moiz wrote: > How does one do it for m2? > > I am new to maven and I have decided to skip maven 1.x and start with m2 > directly. In Maven 2 there is the same off-line option as in Maven 1 but you can also say that repositories can contain snapshots or not so by default Maven won't go to Ibiblio to look for snapshots. -- Trygve signature.asc Description: Digital signature
Re: Best practices for release and version management?
Hi David, Is it possible for you to share the "internal process" document with us? It will help a lot. -Sanjay On 9/2/05, David Jackman <[EMAIL PROTECTED]> wrote: > > We're pretty much doing what Jose is doing, but we don't see these > timeouts. I think it's because the Maven properties are set up to look in > our internal repository first and then go global from there. Just about > everything is in the internal repository (certainly the artifacts for our > projects are there), so the download time isn't much at all. > > My maven.repo.remote property lists the internal repository first, and > ibiblio second. > > As far as the approach to take when releasing and incrementing versions, > the process you describe is essentially what we're doing. In fact, I just > wrote up a document outlining our internal process for releasing projects > for our developers (since we're about to release the big project soon), so I > know the details very well. > > ..David.. > > > -Original Message- > From: Trygve Laugstøl [mailto:[EMAIL PROTECTED] > Sent: Friday, September 02, 2005 4:14 AM > To: Maven Users List > Subject: Re: Best practices for release and version management? > > On Fri, Sep 02, 2005 at 11:46:49AM +0200, Jose Gonzalez Gomez wrote: > > Hi there, > > > > How do you use to manage your project version among releases? I > > mean... what do you exactly put in currentVersion in your pom and how > > do you change it among releases? > > > > I'm currently using the following approach: > > > > 1. Developing version 0.1 - currentVersion = 0.1-SNAPSHOT 2. V0.1 > > release: commit all pending changes, change currentVersion to 0.1, > > commit pom, tag/branch repository, make release. > > 3. Developing version 0.2 - change currentVersion to 0.2-SNAPSHOT, > > commit pom, update and continue developing > > This is the way that we're recomending and using ourselfs. > > > What do you think about this? This approach has one annoying thing: > > maven tries to download SNAPSHOT versions from remote repositories, > > although they're only locally installed in the developer repository. > > After some timeout maven uses the local version, but in case of large > > projects the sum of the timeouts may be big. Do you use any other > > approach? > > The easiest solution to this problem is to either configure a proxy so it > doesn't time out (but rather get a 404 response from the HTTP server) or > just run Maven in off-line mode (by using the -o switch) > > -- > Trygve > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Best practices for release and version management?
2005/9/2, Trygve Laugstøl <[EMAIL PROTECTED]>: > On Fri, Sep 02, 2005 at 10:54:37AM -0400, dohadwala, moiz wrote: > > How does one do it for m2? > > > > I am new to maven and I have decided to skip maven 1.x and start with m2 > > directly. > > In Maven 2 there is the same off-line option as in Maven 1 but you can > also say that repositories can contain snapshots or not so by default > Maven won't go to Ibiblio to look for snapshots. > I think that's what I was looking for... so if I explicitly list the default repositories and add a false to them, Maven won't look for snapshots there and directly get snapshots from the developer local repository... I'll give it a try. Thanks, best regards Jose - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practices for release and version management?
David, I understand that you're deploying your snapshot versions for your projects in your internal repository, but I don't fully understand your environment (or maybe Maven's way of working)... let me explain: I understand that you can publish snapshot versions of artifacts under development that are used across projects using a checked out source tree of those artifacts. The problem comes when you have several developers working on a project and using artifacts that are private to that project, and where several developers may be changing the same artifact (think of two different developers working on two different EJBs in the same artifact, or two different parts of a web interface). In this case you cannot publish that artifact until changes are comitted, and every developer must use her own snapshot copy of the artifact with her local changes that must be taken from her local repository. It's in this case that I don't want those artifacts to be taken from any other repository. How do you handle this, or how do you configure Maven to tell that those artifacts should only be taken from the developer local repository? Best regards Jose 2005/9/2, David Jackman <[EMAIL PROTECTED]>: > We're pretty much doing what Jose is doing, but we don't see these timeouts. > I think it's because the Maven properties are set up to look in our internal > repository first and then go global from there. Just about everything is in > the internal repository (certainly the artifacts for our projects are there), > so the download time isn't much at all. > > My maven.repo.remote property lists the internal repository first, and > ibiblio second. > > As far as the approach to take when releasing and incrementing versions, the > process you describe is essentially what we're doing. In fact, I just wrote > up a document outlining our internal process for releasing projects for our > developers (since we're about to release the big project soon), so I know the > details very well. > > ..David.. > > > -Original Message- > From: Trygve Laugstøl [mailto:[EMAIL PROTECTED] > Sent: Friday, September 02, 2005 4:14 AM > To: Maven Users List > Subject: Re: Best practices for release and version management? > > On Fri, Sep 02, 2005 at 11:46:49AM +0200, Jose Gonzalez Gomez wrote: > > Hi there, > > > > How do you use to manage your project version among releases? I > > mean... what do you exactly put in currentVersion in your pom and how > > do you change it among releases? > > > > I'm currently using the following approach: > > > > 1. Developing version 0.1 - currentVersion = 0.1-SNAPSHOT 2. V0.1 > > release: commit all pending changes, change currentVersion to 0.1, > > commit pom, tag/branch repository, make release. > > 3. Developing version 0.2 - change currentVersion to 0.2-SNAPSHOT, > > commit pom, update and continue developing > > This is the way that we're recomending and using ourselfs. > > > What do you think about this? This approach has one annoying thing: > > maven tries to download SNAPSHOT versions from remote repositories, > > although they're only locally installed in the developer repository. > > After some timeout maven uses the local version, but in case of large > > projects the sum of the timeouts may be big. Do you use any other > > approach? > > The easiest solution to this problem is to either configure a proxy so it > doesn't time out (but rather get a 404 response from the HTTP server) or just > run Maven in off-line mode (by using the -o switch) > > -- > Trygve > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Best practices for release and version management?
I don't know of a way to configure Maven this way, other than the -o option to tell Maven to run in offline mode, where nothing ever gets downloaded. We haven't really had this problem come up. The un-committed changes for any given developer is usually limited to one or two projects. Plus, most of our developers use an IDE for doing their own builds of projects while developing instead of using Maven. When they are ready to commit their changes, they'll do a Maven build to make sure that build still works. ..David.. -Original Message- From: Jose Gonzalez Gomez [mailto:[EMAIL PROTECTED] Sent: Saturday, September 03, 2005 3:16 AM To: Maven Users List Subject: Re: Best practices for release and version management? David, I understand that you're deploying your snapshot versions for your projects in your internal repository, but I don't fully understand your environment (or maybe Maven's way of working)... let me explain: I understand that you can publish snapshot versions of artifacts under development that are used across projects using a checked out source tree of those artifacts. The problem comes when you have several developers working on a project and using artifacts that are private to that project, and where several developers may be changing the same artifact (think of two different developers working on two different EJBs in the same artifact, or two different parts of a web interface). In this case you cannot publish that artifact until changes are comitted, and every developer must use her own snapshot copy of the artifact with her local changes that must be taken from her local repository. It's in this case that I don't want those artifacts to be taken from any other repository. How do you handle this, or how do you configure Maven to tell that those artifacts should only be taken from the developer local repository? Best regards Jose 2005/9/2, David Jackman <[EMAIL PROTECTED]>: > We're pretty much doing what Jose is doing, but we don't see these timeouts. > I think it's because the Maven properties are set up to look in our internal > repository first and then go global from there. Just about everything is in > the internal repository (certainly the artifacts for our projects are there), > so the download time isn't much at all. > > My maven.repo.remote property lists the internal repository first, and > ibiblio second. > > As far as the approach to take when releasing and incrementing versions, the > process you describe is essentially what we're doing. In fact, I just wrote > up a document outlining our internal process for releasing projects for our > developers (since we're about to release the big project soon), so I know the > details very well. > > ..David.. > > > -Original Message----- > From: Trygve Laugstøl [mailto:[EMAIL PROTECTED] > Sent: Friday, September 02, 2005 4:14 AM > To: Maven Users List > Subject: Re: Best practices for release and version management? > > On Fri, Sep 02, 2005 at 11:46:49AM +0200, Jose Gonzalez Gomez wrote: > > Hi there, > > > > How do you use to manage your project version among releases? I > > mean... what do you exactly put in currentVersion in your pom and > > how do you change it among releases? > > > > I'm currently using the following approach: > > > > 1. Developing version 0.1 - currentVersion = 0.1-SNAPSHOT 2. V0.1 > > release: commit all pending changes, change currentVersion to 0.1, > > commit pom, tag/branch repository, make release. > > 3. Developing version 0.2 - change currentVersion to 0.2-SNAPSHOT, > > commit pom, update and continue developing > > This is the way that we're recomending and using ourselfs. > > > What do you think about this? This approach has one annoying thing: > > maven tries to download SNAPSHOT versions from remote repositories, > > although they're only locally installed in the developer repository. > > After some timeout maven uses the local version, but in case of > > large projects the sum of the timeouts may be big. Do you use any > > other approach? > > The easiest solution to this problem is to either configure a proxy so > it doesn't time out (but rather get a 404 response from the HTTP > server) or just run Maven in off-line mode (by using the -o switch) > > -- > Trygve > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practices for release and version management?
Jose Gonzalez Gomez wrote: I understand that you're deploying your snapshot versions for your projects in your internal repository, but I don't fully understand your environment (or maybe Maven's way of working)... let me explain: I understand that you can publish snapshot versions of artifacts under development that are used across projects using a checked out source tree of those artifacts. The problem comes when you have several developers working on a project and using artifacts that are private to that project, and where several developers may be changing the same artifact (think of two different developers working on two different EJBs in the same artifact, or two different parts of a web interface). In this case you cannot publish that artifact until changes are comitted, and every developer must use her own snapshot copy of the artifact with her local changes that must be taken from her local repository. It's in this case that I don't want those artifacts to be taken from any other repository. How do you handle this, or how do you configure Maven to tell that those artifacts should only be taken from the developer local repository? Jose, I think that one way to solve the problem that you have posed would be to expand the namespace used by individuals/teams for the development artifacts. If you and I are each making mutually exclusive changes to an artifact that we each call artifact-dev-SNAPSHOT.jar, then there is a serious problem, which you identified. If on the other hand, you call your artifact artifact-j-dev-SNAPSHOT.jar and I call my artifact artifact-a-dev-SNAPSHOT.jar, then each SNAPSHOT is qualified by owner. As long as each owner uses a unique name then there can be no problems. This naming convention allows the various teams to roll their changes stepwise into an artifact-dev-SNAPSHOT.jar at integration time, if that is desirable. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
