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 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. Yeah you can ask on this list because I know some people already use it. > > > > 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 > -- Alexandre Poitras Québec, Canada --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
