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/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] > > > > > > --------------------------------------------------------------------- > > 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]
