You can add a property to your finalName and fill that with a profile, or use the build definition inside a profile to add your finalName to.
Hth, Nick Stolwijk -----Original Message----- From: amit kumar [mailto:[EMAIL PROTECTED] Sent: Thu 2/14/2008 10:45 To: Maven Users List Subject: Re: Maven Concepts *Different finalName for development and integration environment: Something like the builds at CI server would have x-INT-2008.jar. * Hi, The above is a requirement to be catered to. But my doubt is the finalName gets overridden in children projects if it is present(which is the case). How to accomplish this. Is profiles the answer? But submodules doesn't have a profile for finalName, they have it directly in the <build> tag. Regards, Amit Kumar On Tue, Feb 12, 2008 at 9:49 PM, <[EMAIL PROTECTED]> wrote: > The modules section is only used when building an aggregate project. It is > not used for dependencies in any way. If submodule b uses submodule a, you > have to give submodule b a dependency on submodule a. If multiple submodules > depend on submodule a, you can have submodule a in the dependencyManagement, > with the right version (often it is ${project.version}, which is the > version of your aggregate project) so you don't need to include the version > number in each submodule. > > Hth, > > Nick Stolwijk > > > -----Original Message----- > From: amit kumar [mailto:[EMAIL PROTECTED] > Sent: Tue 2/12/2008 15:15 > To: Maven Users List > Subject: Re: Maven Concepts > > Continuing on the dependency Vs dependencyManagement, I read the documents > on it but after encountering the archetype:create for j2ee simple, I am > not > able to figure out what is the motive behind giving sub-modules of the > project in the dependencyManagement section. > > > Regards, > Amit > > On Feb 12, 2008 7:08 PM, amit kumar <[EMAIL PROTECTED]> wrote: > > > Thanks Nick. I was unaware of that part. Configured the repository for > > snapshots and now it is working. > > > > Regards, > > Amit > > > > > > On Feb 12, 2008 3:16 PM, <[EMAIL PROTECTED]> wrote: > > > > > How did you configure your repository? Especially take a look at the > > > updatePolicy element in your snapshot repository. [1] If this one is > > > omitted, it will default to "daily", so it is possible it won't take > your > > > newest snapshot. You can use "mvn -U" to look for newer versions of > the > > > snapshot dependencies. Or set the updatePolicy to another value: "The > > > frequency for downloading updates - can be "always", "daily" > (default), > > > "interval:XXX" (in minutes) or "never" (only if it doesn't exist > locally)." > > > > > > Hth, > > > > > > Nick S. > > > > > > [1] > > > > http://maven.apache.org/ref/2.0.7/maven-settings/settings.html#class_snapshots > > > > > > > > > -----Original Message----- > > > From: amit kumar [mailto:[EMAIL PROTECTED] > > > Sent: Tue 2/12/2008 10:40 > > > To: Maven Users List > > > Subject: Re: Maven Concepts > > > > > > I tested with SNAPSHOT version as well. But maven still seems to > prefer > > > the > > > local version of even the SNAPSHOT version? > > > > > > i have these two modules a.jar and b.jar, > > > a-1.0-SNAPSHOT.jar depends on b-1.0-SNAPSHOT.jar, I tested and > deployed > > > b.jar at a later time stamp and again tried to build a.jar. But still > it > > > fetched the local version which was build at 14:29 while the one of > two > > > jars > > > at repository is a 14:45 built? > > > > > > Am I missing something here? I am using the buildNumber as well to > have > > > the > > > finalName appended with time stamp. > > > > > > Regards, > > > Amit > > > > > > On Feb 8, 2008 3:52 PM, Simon Kitching <[EMAIL PROTECTED]> > wrote: > > > > > > > ---- Stephen Connolly <[EMAIL PROTECTED]> schrieb: > > > > > Redeploying a non-SNAPSHOT version is a _bad thing_ as Maven will > > > not > > > > > re-download it. > > > > > > > > Absolutely. Never overwrite an existing deployed file except when it > > > has > > > > SNAPSHOT in the version. > > > > > > > > Builds should be repeatable, ie you should be able to compile > > > something > > > > today, then compile it again next week and get the same result. This > > > means > > > > that stuff deployed to a repository should never change. > > > > > > > > The only exception is SNAPSHOT versions; when a project depends on > one > > > of > > > > these, then it is explicitly acknowledging that repeatable builds > are > > > not > > > > possible. > > > > > > > > One of the things the release plugin does is check that there are no > > > > SNAPSHOT dependencies anywere; if there are then it refuses to > > > continue with > > > > the release process as the release is not repeatable. Of course > using > > > the > > > > release plugin is not mandatory, but that particular check is a very > > > good > > > > idea. > > > > > > > > And because Maven assumes people never overwrite non-snapshot files, > > > it > > > > never bothers to check for newer ones. Only with SNAPSHOTs does > maven > > > look > > > > for newer versions, on an "every time", "daily" or "weekly" basis as > > > > configured. > > > > > > > > Regards, > > > > Simon > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > >
