Re: [m2] Newbie dependency question
On 2/21/06, Dave Hoffer [EMAIL PROTECTED] wrote: Alexandre, I have some further questions below... -Original Message- From: Alexandre Poitras [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 21, 2006 9:52 PM To: Maven Users List Subject: Re: [m2] Newbie dependency question About the version, the best practices recommend to keep a separate build for bug maintenance (using a separate SCM branch) and one for adding new features (the trunk). You usually set some features milestones and each time you complete one, you can release a new major version, for instance 1.0, 2.0, ... The tricky part here is that you have to merge your branch with the trunk often to resolve the bug quickly and avoid big conflicts. When you do that, you usually ugrade the minor version, for instance 1.0 to 1.0.1. I [dh] ok. In the mean time, you provide Snapshots in case some developpers need the latest bug fixes. Maven2 handle Snapshot very well. For instance, today I was debugging some components and I was able to publish about 10 snapshots to our repository. Each time I was deploying it, one of my coworker was immediatly testing it in an application. Maven always downloaded the lastest one without any problem, granted the dependency was deployed in a snapshot repository and the lookup policy was set to always check for a newer version (there is 3 suppported types of repositories release, snaphot and plugins but usually you use the same location for the three). [dh] So you have 10 components each with versioned releases and Snapshots? The applications that use these 10 components specify their dependencies as needing the versioned releases but because 'the lookup policy was set to always check for a newer version' it grabs the Snapshots instead? No sorry, I guess I wasn't clear enoug. We we're doing some performance testing so I deployed 10 versions of the same componet. The application always grabbed the snapshot because it declared a dependency on the component with a version 1.0-SNAPSHOT specified. [dh] How do you configure your applications to set 'the lookup policy was set to always check for a newer version'? In your pom.xml, you have to define your release and snapshot repositories. There you can add an updatePolicy element with it [dh] Can you configure your application to look for newer versioned components as well as Snapshots? [dh] If this is true it seems you could ship your application with Snapshots if you forgot to turn off the policy to check for a newer version. So basically, the other developers you are working with can use one of your components by declaring it as a dependency in their project pom. What is really important is that they state the correct version number, ie if they want the official version 1.0, they should just put 1.0 but if they want always the latest build, they should put something like 1.0-SNAPSHOT. Using an official version you are sure your project will always build but you won't have your latest bug fixes available. For internal components, I am usually comfortable to use SNAPSHOT versions (until the release of course, not after) but not when it is an external dependency. [dh] So you could go right up to app release using SNAPSHOT and then start changing to specifying versioned components? [dh] The problem I see is that since the (internal) components have been at SNAPSHOT for so long nobody would know what version to set it to. You would have to look at the history of labels/branches, check the version number and increment the appropriate version (major/minor/sp) number by one. This would be entirely manual and subject to possible errors. [dh] It seems this approach eliminates any need for a build number. SNAPSHOT becomes the build number and it's the same for all builds. I'm not clear if this is good or bad yet. Take a look there to have more details on the good practices Maven team suggest and that I just listed : http://maven.apache.org/development-process.html We don't use an automated build tool yet (I have to integrate it in our process first), but we plan to use Continuum (the last is 1.0.2) very soon. So I can't really help you there but I think you can tell him what projects to construct. [dh] Okay, I too would like to use Continuum but I didn't find many docs to help with this. Well, I hope it's help. Hard to explain all of those concepts in a small mail. If you need more advice, don't be afraid to ask. [dh] Thanks a lot! -dh On 2/21/06, Dave Hoffer [EMAIL PROTECTED] wrote: Alexandre, Let me see if I understand correctly by asking some questions, I am very new to maven ant so please excuse the newbie nature of these. Currently we have one ant script that builds all of our components/applications synchronously every 15 minutes after a check in. So we create full builds often. This works well as we always have the latest build to test
Re: [m2] Newbie dependency question
whoops I pushed send by accident here the true email On 2/22/06, Alexandre Poitras [EMAIL PROTECTED] wrote: On 2/21/06, Dave Hoffer [EMAIL PROTECTED] wrote: Alexandre, I have some further questions below... -Original Message- From: Alexandre Poitras [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 21, 2006 9:52 PM To: Maven Users List Subject: Re: [m2] Newbie dependency question About the version, the best practices recommend to keep a separate build for bug maintenance (using a separate SCM branch) and one for adding new features (the trunk). You usually set some features milestones and each time you complete one, you can release a new major version, for instance 1.0, 2.0, ... The tricky part here is that you have to merge your branch with the trunk often to resolve the bug quickly and avoid big conflicts. When you do that, you usually ugrade the minor version, for instance 1.0 to 1.0.1. I [dh] ok. In the mean time, you provide Snapshots in case some developpers need the latest bug fixes. Maven2 handle Snapshot very well. For instance, today I was debugging some components and I was able to publish about 10 snapshots to our repository. Each time I was deploying it, one of my coworker was immediatly testing it in an application. Maven always downloaded the lastest one without any problem, granted the dependency was deployed in a snapshot repository and the lookup policy was set to always check for a newer version (there is 3 suppported types of repositories release, snaphot and plugins but usually you use the same location for the three). [dh] So you have 10 components each with versioned releases and Snapshots? The applications that use these 10 components specify their dependencies as needing the versioned releases but because 'the lookup policy was set to always check for a newer version' it grabs the Snapshots instead? No sorry, I guess I wasn't clear enoug. We we're doing some performance testing so I deployed 10 versions of the same componet. The application always grabbed the snapshot because it declared a dependency on the component with a version 1.0-SNAPSHOT specified. [dh] How do you configure your applications to set 'the lookup policy was set to always check for a newer version'? In your pom.xml, you have to define your release and snapshot repositories. There you can add an updatePolicy element with it value set to always. [dh] Can you configure your application to look for newer versioned components as well as Snapshots? I don't know the answer to this question, I am still wondering the same but I prefer to update the version number myself to test if my build doesn't break with a new version. [dh] If this is true it seems you could ship your application with Snapshots if you forgot to turn off the policy to check for a newer version. No, if you use the release plugin when you make a release, you will an error if you have snapshot dependencies. Maven is pretty smart ;) So basically, the other developers you are working with can use one of your components by declaring it as a dependency in their project pom. What is really important is that they state the correct version number, ie if they want the official version 1.0, they should just put 1.0 but if they want always the latest build, they should put something like 1.0-SNAPSHOT. Using an official version you are sure your project will always build but you won't have your latest bug fixes available. For internal components, I am usually comfortable to use SNAPSHOT versions (until the release of course, not after) but not when it is an external dependency. [dh] So you could go right up to app release using SNAPSHOT and then start changing to specifying versioned components? Yes, if you want to but if in the mean time a new component release is made, for instance 2.0, then you have to update your project to use the version 2.0-SNAPSHOT instead of 1.0-SNAPSHOT. [dh] The problem I see is that since the (internal) components have been at SNAPSHOT for so long nobody would know what version to set it to. You would have to look at the history of labels/branches, check the version number and increment the appropriate version (major/minor/sp) number by one. This would be entirely manual and subject to possible errors. See my previous answer, snapshots still care about the version, it just allow you to deploy many quick releases (Maven just add a timestamp to your dependency name). [dh] It seems this approach eliminates any need for a build number. SNAPSHOT becomes the build number and it's the same for all builds. I'm not clear if this is good or bad yet. See the previous answer again :) Take a look there to have more details on the good practices Maven team suggest and that I just listed : http://maven.apache.org/development-process.html We don't use
RE: [m2] Newbie dependency question
Alexandre, Let me see if I understand correctly by asking some questions, I am very new to maven ant so please excuse the newbie nature of these. Currently we have one ant script that builds all of our components/applications synchronously every 15 minutes after a check in. So we create full builds often. This works well as we always have the latest build to test/release etc. However we have poor version control to support releases, service packs, etc and it doesn't scale well to using these same components in parallel project builds. So I am looking to maven2 to see if I can get a better system practice. So given your description, it seems I would need SNAPSHOT builds that build after each check in (with some delay) else I would not have my continuous builds. (Waiting for a nightly build would be too long. Our testers work right with developers and we often want to fix something and get them a build asap. And it may be this build that we release if it has the quality they are looking for!) In our case the big question is...when do we create component releases? In reality we don't have 'official' releases of many internal components because who cares? All each project cares about is two things; first if I am dependent on the new stuff being developed in a component I want the latest. On the other hand, if I am satisfied with the content of a component the way it is, I don't want changes wrecking my build so a released versioned component that doesn't change is what I want. How can I get this with maven? I could do SNAPSHOTS as the norm and then specify versions once it surpasses a certain milestone. However, it seems I would always be looking back applying a version once I already have released a product with a SNAPSHOT. This doesn't seem like the way to use maven. By the way, what do you use to do the continuous build part of the system? Is Continuum ready? How about QuickBuild or CruiseControl? How do these integrate? Do they label the source, apply the right value to the version tag in the pom, and keep track of incrementing the build number? Also, I assume in maven that each artifact/pom should be built in an autonomous manor, each with its own automation script. Is this correct? As for the enterprise snapshot repository; isn't this the same repository as the versioned one? I think that if I get the big picture of how to use maven2 in an aggressive continuous build system I can get going with it, right now I feel I don't know how to begin. (I have ordered a maven book but it isn't published yet.) Any ideas/suggestions are greatly appreciated. -dh -Original Message- From: Alexandre Poitras [mailto:[EMAIL PROTECTED] Sent: Monday, February 20, 2006 6:13 PM To: Maven Users List Subject: Re: [m2] Newbie dependency question From what I understand you want to use the fresh version of some components that are still in development, what is usually called a night build or a snapshot. You should declare their version as 1.0-SNAPSHOT or something like that. Then you just need to setup an enterprise snapshot repository wich always give you the lastest snapshot of your artefacts. When the components actually go throught a new release, I suggest you to update the dependencies version manually when new versions come out so you can test if everything still work ok. On 2/20/06, Dave Hoffer [EMAIL PROTECTED] wrote: Being new to maven I have so basic questions regarding best practices in maven. Specifically, I want to know what the recommended practice is in configuring projects that have dependencies which is all but the most basic of applications. In our company we develop applications that are comprised of several components that we create. As I understand maven, all artifacts have the version in the jar name. This is great in one sense as it lets your project(s) refer to the specific jar version that you want. However, it causes problems also because ideally we want our applications to work with the 'latest' version of all of our components. It seems the default maven behavior would encourage our applications and components to be created to something other than the 'latest' version. I would like to setup our IntelliJ projects and our continuous integration build system to generally use the 'latest' version of components so that we attempt to minimize code that is written to old components. How can this be accomplished in maven2? What are the best practices? Thanks! -dh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexandre Poitras Québec, Canada - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: [m2] Newbie dependency question
a maven book but it isn't published yet.) Any ideas/suggestions are greatly appreciated. -dh -Original Message- From: Alexandre Poitras [mailto:[EMAIL PROTECTED] Sent: Monday, February 20, 2006 6:13 PM To: Maven Users List Subject: Re: [m2] Newbie dependency question From what I understand you want to use the fresh version of some components that are still in development, what is usually called a night build or a snapshot. You should declare their version as 1.0-SNAPSHOT or something like that. Then you just need to setup an enterprise snapshot repository wich always give you the lastest snapshot of your artefacts. When the components actually go throught a new release, I suggest you to update the dependencies version manually when new versions come out so you can test if everything still work ok. On 2/20/06, Dave Hoffer [EMAIL PROTECTED] wrote: Being new to maven I have so basic questions regarding best practices in maven. Specifically, I want to know what the recommended practice is in configuring projects that have dependencies which is all but the most basic of applications. In our company we develop applications that are comprised of several components that we create. As I understand maven, all artifacts have the version in the jar name. This is great in one sense as it lets your project(s) refer to the specific jar version that you want. However, it causes problems also because ideally we want our applications to work with the 'latest' version of all of our components. It seems the default maven behavior would encourage our applications and components to be created to something other than the 'latest' version. I would like to setup our IntelliJ projects and our continuous integration build system to generally use the 'latest' version of components so that we attempt to minimize code that is written to old components. How can this be accomplished in maven2? What are the best practices? Thanks! -dh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexandre Poitras Québec, Canada - 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] -- Alexandre Poitras Québec, Canada - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] Newbie dependency question
Alexandre, I have some further questions below... -Original Message- From: Alexandre Poitras [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 21, 2006 9:52 PM To: Maven Users List Subject: Re: [m2] Newbie dependency question About the version, the best practices recommend to keep a separate build for bug maintenance (using a separate SCM branch) and one for adding new features (the trunk). You usually set some features milestones and each time you complete one, you can release a new major version, for instance 1.0, 2.0, ... The tricky part here is that you have to merge your branch with the trunk often to resolve the bug quickly and avoid big conflicts. When you do that, you usually ugrade the minor version, for instance 1.0 to 1.0.1. I [dh] ok. In the mean time, you provide Snapshots in case some developpers need the latest bug fixes. Maven2 handle Snapshot very well. For instance, today I was debugging some components and I was able to publish about 10 snapshots to our repository. Each time I was deploying it, one of my coworker was immediatly testing it in an application. Maven always downloaded the lastest one without any problem, granted the dependency was deployed in a snapshot repository and the lookup policy was set to always check for a newer version (there is 3 suppported types of repositories release, snaphot and plugins but usually you use the same location for the three). [dh] So you have 10 components each with versioned releases and Snapshots? The applications that use these 10 components specify their dependencies as needing the versioned releases but because 'the lookup policy was set to always check for a newer version' it grabs the Snapshots instead? [dh] How do you configure your applications to set 'the lookup policy was set to always check for a newer version'? [dh] Can you configure your application to look for newer versioned components as well as Snapshots? [dh] If this is true it seems you could ship your application with Snapshots if you forgot to turn off the policy to check for a newer version. So basically, the other developers you are working with can use one of your components by declaring it as a dependency in their project pom. What is really important is that they state the correct version number, ie if they want the official version 1.0, they should just put 1.0 but if they want always the latest build, they should put something like 1.0-SNAPSHOT. Using an official version you are sure your project will always build but you won't have your latest bug fixes available. For internal components, I am usually comfortable to use SNAPSHOT versions (until the release of course, not after) but not when it is an external dependency. [dh] So you could go right up to app release using SNAPSHOT and then start changing to specifying versioned components? [dh] The problem I see is that since the (internal) components have been at SNAPSHOT for so long nobody would know what version to set it to. You would have to look at the history of labels/branches, check the version number and increment the appropriate version (major/minor/sp) number by one. This would be entirely manual and subject to possible errors. [dh] It seems this approach eliminates any need for a build number. SNAPSHOT becomes the build number and it's the same for all builds. I'm not clear if this is good or bad yet. Take a look there to have more details on the good practices Maven team suggest and that I just listed : http://maven.apache.org/development-process.html We don't use an automated build tool yet (I have to integrate it in our process first), but we plan to use Continuum (the last is 1.0.2) very soon. So I can't really help you there but I think you can tell him what projects to construct. [dh] Okay, I too would like to use Continuum but I didn't find many docs to help with this. Well, I hope it's help. Hard to explain all of those concepts in a small mail. If you need more advice, don't be afraid to ask. [dh] Thanks a lot! -dh On 2/21/06, Dave Hoffer [EMAIL PROTECTED] wrote: Alexandre, Let me see if I understand correctly by asking some questions, I am very new to maven ant so please excuse the newbie nature of these. Currently we have one ant script that builds all of our components/applications synchronously every 15 minutes after a check in. So we create full builds often. This works well as we always have the latest build to test/release etc. However we have poor version control to support releases, service packs, etc and it doesn't scale well to using these same components in parallel project builds. So I am looking to maven2 to see if I can get a better system practice. So given your description, it seems I would need SNAPSHOT builds that build after each check in (with some delay) else I would not have my continuous builds. (Waiting for a nightly build would be too long. Our testers work right with developers and we
Re: [m2] Newbie dependency question
From what I understand you want to use the fresh version of some components that are still in development, what is usually called a night build or a snapshot. You should declare their version as 1.0-SNAPSHOT or something like that. Then you just need to setup an enterprise snapshot repository wich always give you the lastest snapshot of your artefacts. When the components actually go throught a new release, I suggest you to update the dependencies version manually when new versions come out so you can test if everything still work ok. On 2/20/06, Dave Hoffer [EMAIL PROTECTED] wrote: Being new to maven I have so basic questions regarding best practices in maven. Specifically, I want to know what the recommended practice is in configuring projects that have dependencies which is all but the most basic of applications. In our company we develop applications that are comprised of several components that we create. As I understand maven, all artifacts have the version in the jar name. This is great in one sense as it lets your project(s) refer to the specific jar version that you want. However, it causes problems also because ideally we want our applications to work with the 'latest' version of all of our components. It seems the default maven behavior would encourage our applications and components to be created to something other than the 'latest' version. I would like to setup our IntelliJ projects and our continuous integration build system to generally use the 'latest' version of components so that we attempt to minimize code that is written to old components. How can this be accomplished in maven2? What are the best practices? Thanks! -dh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexandre Poitras Québec, Canada - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
