SNAPSHOT Vs release version. Hi, In our intranet maven repository we have both release version and snaphot version under the same groupId (under the same folder on file system). While amounting to ignorance to SNAPSHOT versions, release version existed long before SNAPSHOT versions started getting placed in the same folder. Now we realized that when people changed their dependency versions to snapshot, maven is not able to fetch the SNAPSHOT version, and it just tells not able to find the specified jar.
The earlier dependency of y on x <groupId>com.group.x</groupId> <artifactId>x</artifactId> <version>1.0.0</version> has become <groupId>com.group.x</groupId> <artifactId>x</artifactId> <version>1.0.0-SNAPSHOT</version> and x has already been deployed to the repository with 1.0.0-SNAPSHOTversion. Could someone please help me figure out what exactly is happening here? Regards, Amit On Thu, Feb 14, 2008 at 3:17 PM, <[EMAIL PROTECTED]> wrote: > 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] > > > > > > > > > > > > > > > > > > > > > > > > > > >
