Re: Maven Concepts
Thanks simon I will take care for the selection of threads in future.Apologies for the same. On Fri, Feb 15, 2008 at 1:28 PM, Mark Struberg [EMAIL PROTECTED] wrote: The only reason i can think of to have a snapshot repo in a company is to get rid of very old snapshots which may bump up your repo size heavily. It is much easier to drop obsolete snapshots if they are strictly separated from released modules. LieGrü, strub --- [EMAIL PROTECTED] [EMAIL PROTECTED] schrieb: Hi Amit, Firstly, when you have a question that is not really related to an existing thread, then please start a new email thread rather than replying to the existing one. By doing that, and choosing a good subject line for the email, other people with the same problem can later search the email archives and find the necessary answer. AFAIK, there's no major problem having release and snapshot versions in the same repository. This doesn't happen often with open-source projects because (a) all releases get put into the official repositories (ibiblio, rep1.maven.org) that are mirrored arround the world, and (b) mirroring snapshots is silly. So for apache software for example, there is a non-mirrored repo that only holds snapshots, with all actual releases going to the mirrored repos. But for a company that doesn't mirror its releases, I'm not aware of any reason why snapshots and releases cannot be on the same repo. Your problem is probably that you have the repository tag that points to your repo configured with snapshot-lookup disabled. Try adding this to the repository tag: snapshots enabledtrue/enabled /snapshots Regards, Simon amit kumar schrieb: 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 groupIdcom.group.x/groupId artifactIdx/artifactId version1.0.0/version has become groupIdcom.group.x/groupId artifactIdx/artifactId version1.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? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Lesen Sie Ihre E-Mails auf dem Handy. www.yahoo.de/go - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Concepts
I think your problem is as follows: Maven regards 1.0.0-SNAPSHOT as before 1.0.0. Also Maven does not necessarily use the version you've declared. The version tag is really more of a hint or suggestion than an absolute requirement. (Unless you've locked down your versions.) Thus, although you have a declared dependency on 1.0.0-SNAPSHOT, Maven sees the 1.0.0 release version and uses it instead. I would suggest simply bumping the version to 1.0.1-SNAPSHOT. Or perhaps using version[1.0.0-SNAPSHOT]/version in your dependency declaration. That will force Maven to use the snapshot and not the release. In the future, do not number things like this. Snapshot always comes before a release, and then you bump the version and make another Snapshot. Wayne On 2/15/08, amit kumar [EMAIL PROTECTED] wrote: Thanks simon I will take care for the selection of threads in future.Apologies for the same. On Fri, Feb 15, 2008 at 1:28 PM, Mark Struberg [EMAIL PROTECTED] wrote: The only reason i can think of to have a snapshot repo in a company is to get rid of very old snapshots which may bump up your repo size heavily. It is much easier to drop obsolete snapshots if they are strictly separated from released modules. LieGrü, strub --- [EMAIL PROTECTED] [EMAIL PROTECTED] schrieb: Hi Amit, Firstly, when you have a question that is not really related to an existing thread, then please start a new email thread rather than replying to the existing one. By doing that, and choosing a good subject line for the email, other people with the same problem can later search the email archives and find the necessary answer. AFAIK, there's no major problem having release and snapshot versions in the same repository. This doesn't happen often with open-source projects because (a) all releases get put into the official repositories (ibiblio, rep1.maven.org) that are mirrored arround the world, and (b) mirroring snapshots is silly. So for apache software for example, there is a non-mirrored repo that only holds snapshots, with all actual releases going to the mirrored repos. But for a company that doesn't mirror its releases, I'm not aware of any reason why snapshots and releases cannot be on the same repo. Your problem is probably that you have the repository tag that points to your repo configured with snapshot-lookup disabled. Try adding this to the repository tag: snapshots enabledtrue/enabled /snapshots Regards, Simon amit kumar schrieb: 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 groupIdcom.group.x/groupId artifactIdx/artifactId version1.0.0/version has become groupIdcom.group.x/groupId artifactIdx/artifactId version1.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? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Lesen Sie Ihre E-Mails auf dem Handy. www.yahoo.de/go - 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]
Re: Maven Concepts
Thanks Wayne. The problem seems to be resolved. Regards, Amit On Fri, Feb 15, 2008 at 9:26 PM, Wayne Fay [EMAIL PROTECTED] wrote: I think your problem is as follows: Maven regards 1.0.0-SNAPSHOT as before 1.0.0. Also Maven does not necessarily use the version you've declared. The version tag is really more of a hint or suggestion than an absolute requirement. (Unless you've locked down your versions.) Thus, although you have a declared dependency on 1.0.0-SNAPSHOT, Maven sees the 1.0.0 release version and uses it instead. I would suggest simply bumping the version to 1.0.1-SNAPSHOT. Or perhaps using version[1.0.0-SNAPSHOT]/version in your dependency declaration. That will force Maven to use the snapshot and not the release. In the future, do not number things like this. Snapshot always comes before a release, and then you bump the version and make another Snapshot. Wayne On 2/15/08, amit kumar [EMAIL PROTECTED] wrote: Thanks simon I will take care for the selection of threads in future.Apologies for the same. On Fri, Feb 15, 2008 at 1:28 PM, Mark Struberg [EMAIL PROTECTED] wrote: The only reason i can think of to have a snapshot repo in a company is to get rid of very old snapshots which may bump up your repo size heavily. It is much easier to drop obsolete snapshots if they are strictly separated from released modules. LieGrü, strub --- [EMAIL PROTECTED] [EMAIL PROTECTED] schrieb: Hi Amit, Firstly, when you have a question that is not really related to an existing thread, then please start a new email thread rather than replying to the existing one. By doing that, and choosing a good subject line for the email, other people with the same problem can later search the email archives and find the necessary answer. AFAIK, there's no major problem having release and snapshot versions in the same repository. This doesn't happen often with open-source projects because (a) all releases get put into the official repositories (ibiblio, rep1.maven.org) that are mirrored arround the world, and (b) mirroring snapshots is silly. So for apache software for example, there is a non-mirrored repo that only holds snapshots, with all actual releases going to the mirrored repos. But for a company that doesn't mirror its releases, I'm not aware of any reason why snapshots and releases cannot be on the same repo. Your problem is probably that you have the repository tag that points to your repo configured with snapshot-lookup disabled. Try adding this to the repository tag: snapshots enabledtrue/enabled /snapshots Regards, Simon amit kumar schrieb: 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 groupIdcom.group.x/groupId artifactIdx/artifactId version1.0.0/version has become groupIdcom.group.x/groupId artifactIdx/artifactId version1.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? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Lesen Sie Ihre E-Mails auf dem Handy. www.yahoo.de/go - 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]
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]
RE: Maven Concepts
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]
Re: Maven Concepts
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
groupIdcom.group.x/groupId
artifactIdx/artifactId
version1.0.0/version
has become
groupIdcom.group.x/groupId
artifactIdx/artifactId
version1.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
Re: Maven Concepts
Hi Amit, Firstly, when you have a question that is not really related to an existing thread, then please start a new email thread rather than replying to the existing one. By doing that, and choosing a good subject line for the email, other people with the same problem can later search the email archives and find the necessary answer. AFAIK, there's no major problem having release and snapshot versions in the same repository. This doesn't happen often with open-source projects because (a) all releases get put into the official repositories (ibiblio, rep1.maven.org) that are mirrored arround the world, and (b) mirroring snapshots is silly. So for apache software for example, there is a non-mirrored repo that only holds snapshots, with all actual releases going to the mirrored repos. But for a company that doesn't mirror its releases, I'm not aware of any reason why snapshots and releases cannot be on the same repo. Your problem is probably that you have the repository tag that points to your repo configured with snapshot-lookup disabled. Try adding this to the repository tag: snapshots enabledtrue/enabled /snapshots Regards, Simon amit kumar schrieb: 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 groupIdcom.group.x/groupId artifactIdx/artifactId version1.0.0/version has become groupIdcom.group.x/groupId artifactIdx/artifactId version1.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? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Concepts
The only reason i can think of to have a snapshot repo in a company is to get rid of very old snapshots which may bump up your repo size heavily. It is much easier to drop obsolete snapshots if they are strictly separated from released modules. LieGrü, strub --- [EMAIL PROTECTED] [EMAIL PROTECTED] schrieb: Hi Amit, Firstly, when you have a question that is not really related to an existing thread, then please start a new email thread rather than replying to the existing one. By doing that, and choosing a good subject line for the email, other people with the same problem can later search the email archives and find the necessary answer. AFAIK, there's no major problem having release and snapshot versions in the same repository. This doesn't happen often with open-source projects because (a) all releases get put into the official repositories (ibiblio, rep1.maven.org) that are mirrored arround the world, and (b) mirroring snapshots is silly. So for apache software for example, there is a non-mirrored repo that only holds snapshots, with all actual releases going to the mirrored repos. But for a company that doesn't mirror its releases, I'm not aware of any reason why snapshots and releases cannot be on the same repo. Your problem is probably that you have the repository tag that points to your repo configured with snapshot-lookup disabled. Try adding this to the repository tag: snapshots enabledtrue/enabled /snapshots Regards, Simon amit kumar schrieb: 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 groupIdcom.group.x/groupId artifactIdx/artifactId version1.0.0/version has become groupIdcom.group.x/groupId artifactIdx/artifactId version1.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? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Lesen Sie Ihre E-Mails auf dem Handy. www.yahoo.de/go - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
RE: Maven Concepts
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]
RE: Maven Concepts
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]
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]
Re: Maven Concepts
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]
Re: Maven Concepts
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
-aps
On Feb 9, 2008 3:25 AM, amit kumar [EMAIL PROTECTED] wrote:
what is the difference between dependency and dependencyManagement? I mean
when do we use dependency and when do we use dependencyManagement?
On Feb 8, 2008 10:26 PM, amit kumar [EMAIL PROTECTED] wrote:
That makes two of us Dhruva. Seriously guys thanks a lot. Great help.
On Feb 8, 2008 9:46 PM, Dhruva Reddy [EMAIL PROTECTED] wrote:
This really clears things up--many thanks!
--
Dhruva B. Reddy
Senior Associate of Technology, Level 2 | Sapient
25 1st Street
Cambridge, MA, 02141, USA
desk: +1 617 452 1900
fax: +1 617 621 1300
www.sapient.com
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Thursday, 07 February 2008 17:01
To: Maven Users List
Subject: Re: Maven Concepts
You've got it exactly right.
Maven builds are usually oriented around the concept of a lifecycle,
which consists of phases in a specific order. Each phase has zero or
more mojos (usually called goals) bound to it. Each phase in the
lifecycle implies all of the phases that come before it. This allows
users to bind (or configure) different goals to different phases of
the build, then the standard phase names to run the build. The
default goals for a given type of project are also bound to the
lifecycle in this way, but behind the scenes, such that the user can
supplement these default goals using configurations in the pom.xml.
So, if you have a jar project (packagingjar/packaging), you might
have something like this:
Phase Goals
---
validate(none)
initialize (none)
...
compileorg.apache.maven.plugins:maven-compiler-
plugin:compile
...
testorg.apache.maven.plugins:maven-surefire-
plugin:test
...
package org.apache.maven.plugins:maven-jar-plugin:jar
...
install org.apache.maven.plugins:maven-install-
plugin:install
...
etc.
Now, if you just want to compile your project, you simply call the
'compile' phase, like this:
mvn compile
If you want to run the unit tests, call this:
mvn test
Note that in order to run unit tests, you must have compiled your
project's main sources. That's handled here, since the test phase is
later in the lifecycle than the compile phase...'test' implies
'compile' and all the other phases (in order) that come before 'test'.
On the other hand, Maven also supports certain one-off goals that are
usually meant to help manage the project build in certain special
cases, or give information about the build. One such example gives
you a glimpse of the POM after all inheritance and profile injection
has been completed:
mvn help:effective-pom
which is shorthand for:
mvn org.apache.maven.plugins:maven-help-plugin:effective-pom
Hope that helps,
-john
On Feb 7, 2008, at 4:50 PM, Dhruva Reddy wrote:
I know this seems like a silly thing to post on here, but...
What exactly is a goal and what is a phase? I can't find a good
answer in the documentation and there's a lot of seemingly
conflicting information out there.
My current understanding is that a phase is a part of a lifecycle
(process-resources, compile, etc). A goal is somewhat analogous to
an ANT-task, but with a focus on what should happen, rather than
how it is done.
Can someone clear this up for me, giving examples?
Thanks,
Dhruva
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
What lies behind us and what lies in front of us is of little concern to
what lies within us. -Ralph Waldo Emerson
Re: Maven Concepts
what is the difference between dependency and dependencyManagement? I mean when do we use dependency and when do we use dependencyManagement? On Feb 8, 2008 10:26 PM, amit kumar [EMAIL PROTECTED] wrote: That makes two of us Dhruva. Seriously guys thanks a lot. Great help. On Feb 8, 2008 9:46 PM, Dhruva Reddy [EMAIL PROTECTED] wrote: This really clears things up--many thanks! -- Dhruva B. Reddy Senior Associate of Technology, Level 2 | Sapient 25 1st Street Cambridge, MA, 02141, USA desk: +1 617 452 1900 fax: +1 617 621 1300 www.sapient.com -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Thursday, 07 February 2008 17:01 To: Maven Users List Subject: Re: Maven Concepts You've got it exactly right. Maven builds are usually oriented around the concept of a lifecycle, which consists of phases in a specific order. Each phase has zero or more mojos (usually called goals) bound to it. Each phase in the lifecycle implies all of the phases that come before it. This allows users to bind (or configure) different goals to different phases of the build, then the standard phase names to run the build. The default goals for a given type of project are also bound to the lifecycle in this way, but behind the scenes, such that the user can supplement these default goals using configurations in the pom.xml. So, if you have a jar project (packagingjar/packaging), you might have something like this: Phase Goals --- validate(none) initialize (none) ... compileorg.apache.maven.plugins:maven-compiler- plugin:compile ... testorg.apache.maven.plugins:maven-surefire- plugin:test ... package org.apache.maven.plugins:maven-jar-plugin:jar ... install org.apache.maven.plugins:maven-install- plugin:install ... etc. Now, if you just want to compile your project, you simply call the 'compile' phase, like this: mvn compile If you want to run the unit tests, call this: mvn test Note that in order to run unit tests, you must have compiled your project's main sources. That's handled here, since the test phase is later in the lifecycle than the compile phase...'test' implies 'compile' and all the other phases (in order) that come before 'test'. On the other hand, Maven also supports certain one-off goals that are usually meant to help manage the project build in certain special cases, or give information about the build. One such example gives you a glimpse of the POM after all inheritance and profile injection has been completed: mvn help:effective-pom which is shorthand for: mvn org.apache.maven.plugins:maven-help-plugin:effective-pom Hope that helps, -john On Feb 7, 2008, at 4:50 PM, Dhruva Reddy wrote: I know this seems like a silly thing to post on here, but... What exactly is a goal and what is a phase? I can't find a good answer in the documentation and there's a lot of seemingly conflicting information out there. My current understanding is that a phase is a part of a lifecycle (process-resources, compile, etc). A goal is somewhat analogous to an ANT-task, but with a focus on what should happen, rather than how it is done. Can someone clear this up for me, giving examples? Thanks, Dhruva --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john rss: http://feeds.feedburner.com/ejlife/john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Concepts
You'd use dependencyManagement to baseline dependencies and their versions across various inheriting modules, while a dependency is, well, a dependency :-) Once specified in the dependencyManagement, you don't need to provider versions for those dependencies in child module's pom. HTH, Rahul amit kumar wrote: what is the difference between dependency and dependencyManagement? I mean when do we use dependency and when do we use dependencyManagement? On Feb 8, 2008 10:26 PM, amit kumar [EMAIL PROTECTED] wrote: That makes two of us Dhruva. Seriously guys thanks a lot. Great help. On Feb 8, 2008 9:46 PM, Dhruva Reddy [EMAIL PROTECTED] wrote: This really clears things up--many thanks! -- Dhruva B. Reddy Senior Associate of Technology, Level 2 | Sapient 25 1st Street Cambridge, MA, 02141, USA desk: +1 617 452 1900 fax: +1 617 621 1300 www.sapient.com -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Thursday, 07 February 2008 17:01 To: Maven Users List Subject: Re: Maven Concepts You've got it exactly right. Maven builds are usually oriented around the concept of a lifecycle, which consists of phases in a specific order. Each phase has zero or more mojos (usually called goals) bound to it. Each phase in the lifecycle implies all of the phases that come before it. This allows users to bind (or configure) different goals to different phases of the build, then the standard phase names to run the build. The default goals for a given type of project are also bound to the lifecycle in this way, but behind the scenes, such that the user can supplement these default goals using configurations in the pom.xml. So, if you have a jar project (packagingjar/packaging), you might have something like this: Phase Goals --- validate(none) initialize (none) ... compileorg.apache.maven.plugins:maven-compiler- plugin:compile ... testorg.apache.maven.plugins:maven-surefire- plugin:test ... package org.apache.maven.plugins:maven-jar-plugin:jar ... install org.apache.maven.plugins:maven-install- plugin:install ... etc. Now, if you just want to compile your project, you simply call the 'compile' phase, like this: mvn compile If you want to run the unit tests, call this: mvn test Note that in order to run unit tests, you must have compiled your project's main sources. That's handled here, since the test phase is later in the lifecycle than the compile phase...'test' implies 'compile' and all the other phases (in order) that come before 'test'. On the other hand, Maven also supports certain one-off goals that are usually meant to help manage the project build in certain special cases, or give information about the build. One such example gives you a glimpse of the POM after all inheritance and profile injection has been completed: mvn help:effective-pom which is shorthand for: mvn org.apache.maven.plugins:maven-help-plugin:effective-pom Hope that helps, -john On Feb 7, 2008, at 4:50 PM, Dhruva Reddy wrote: I know this seems like a silly thing to post on here, but... What exactly is a goal and what is a phase? I can't find a good answer in the documentation and there's a lot of seemingly conflicting information out there. My current understanding is that a phase is a part of a lifecycle (process-resources, compile, etc). A goal is somewhat analogous to an ANT-task, but with a focus on what should happen, rather than how it is done. Can someone clear this up for me, giving examples? Thanks, Dhruva --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john rss: http://feeds.feedburner.com/ejlife/john - 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]
Re: Maven Concepts
And at times you can use the '-U' option to force an update check for dependencies. Rahul Simon Kitching 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Concepts
--- Rahul Thakur [EMAIL PROTECTED] schrieb: And at times you can use the '-U' option to force an update check for dependencies. But again, this works only for SNAPSHOT dependencies, and not for 'released' versions. LieGrü, strub Machen Sie Yahoo! zu Ihrer Startseite. Los geht's: http://de.yahoo.com/set - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Concepts
From the following command: mvn -help I get this description for -U option: -U,--update-snapshots Forces a check for updated releases and snapshots on remote repositories I would imagine both SNAPSHOT and releases are checked for updates :-) Rahul Mark Struberg wrote: --- Rahul Thakur [EMAIL PROTECTED] schrieb: And at times you can use the '-U' option to force an update check for dependencies. But again, this works only for SNAPSHOT dependencies, and not for 'released' versions. LieGrü, strub Machen Sie Yahoo! zu Ihrer Startseite. Los geht's: http://de.yahoo.com/set - 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]
Re: Maven Concepts
It really depends on what you mean by checked for updates... SNAPSHOTS are checked for new versions of the snapshot artifact, and they are pulled down into your local repo cache to be used in this and future builds. Depending on how your versions are declared, new versions of non-snapshot artifacts will also be checked for, pulled down, and used in the build as well. For example, Maven will look for new versions of plugins (eg Jar, War, etc) and use them unless you've locked down your versions. But Maven will not look for an updated version 1.5.2 if one already exists in your local repo cache. It is assumed that there is one and only one version 1.5.2 for a given artifact. Wayne On 2/9/08, Rahul Thakur [EMAIL PROTECTED] wrote: From the following command: mvn -help I get this description for -U option: -U,--update-snapshots Forces a check for updated releases and snapshots on remote repositories I would imagine both SNAPSHOT and releases are checked for updates :-) Rahul Mark Struberg wrote: --- Rahul Thakur [EMAIL PROTECTED] schrieb: And at times you can use the '-U' option to force an update check for dependencies. But again, this works only for SNAPSHOT dependencies, and not for 'released' versions. LieGrü, strub Machen Sie Yahoo! zu Ihrer Startseite. Los geht's: http://de.yahoo.com/set - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Concepts
Ah, gotcha! May be we should update the help message then to something like: Forces a check for newer releases and updated snapshots on remote repositories Cheers, Rahul Wayne Fay wrote: It really depends on what you mean by checked for updates... SNAPSHOTS are checked for new versions of the snapshot artifact, and they are pulled down into your local repo cache to be used in this and future builds. Depending on how your versions are declared, new versions of non-snapshot artifacts will also be checked for, pulled down, and used in the build as well. For example, Maven will look for new versions of plugins (eg Jar, War, etc) and use them unless you've locked down your versions. But Maven will not look for an updated version 1.5.2 if one already exists in your local repo cache. It is assumed that there is one and only one version 1.5.2 for a given artifact. Wayne On 2/9/08, Rahul Thakur [EMAIL PROTECTED] wrote: From the following command: mvn -help I get this description for -U option: -U,--update-snapshots Forces a check for updated releases and snapshots on remote repositories I would imagine both SNAPSHOT and releases are checked for updates :-) Rahul Mark Struberg wrote: --- Rahul Thakur [EMAIL PROTECTED] schrieb: And at times you can use the '-U' option to force an update check for dependencies. But again, this works only for SNAPSHOT dependencies, and not for 'released' versions. LieGrü, strub Machen Sie Yahoo! zu Ihrer Startseite. Los geht's: http://de.yahoo.com/set - 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] - 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]
Re: Maven Concepts
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]
Re: Maven Concepts
Redeploying a non-SNAPSHOT version is a _bad thing_ as Maven will not re-download it. This is why -SNAPSHOT versions are needed (because Maven knows to check for updates). But another reason why the update may not have occurred is if the artifact was copied into the remote repository and not deployed using one of: - mvn deploy:deploy - mvn deploy:deploy-file - maven ant tasks (which are a set of tasks that can be used from ant build scripts to download artifacts from maven repositories or deploy files to maven repositories) These three methods of deploying to the remote repository will ensure that the repository metadata is updated. If you just copy the file then maven can be unaware of this version as it checks the metadata first -Stephen On Feb 8, 2008 7:37 AM, Sahoo [EMAIL PROTECTED] wrote: I am no maven expert. AFAIK, only if it is SNAPSHOT (the one that ends with -SNAPSHOT) version then maven checks the timestamp etc. against the remote repository. Otherwise Maven always prefers the one in the local repository if one is available there. In your case, the artifact version looks to be 1.0 which means once the artifact is available in your local repo, maven won't go to remote repo for that one. Question why did the owner of the artifact chose to update the artifact, but did not bother to change the version number? Someone can correct me if need be. Thanks, Sahoo amit kumar wrote: Continuing on this thread I would also like to put a doubt(misconception)- Until yesterday I used to think that if I have an artifact on local repository + remote repository with same groupId-artifactId-version. The maven will take the one which is built at a later time or some system property attached to it which maven uses to differentiate. The origin for this assumption was no matter if the artifact is present in my local repository maven shows Downloading \\remoteRepository\org\apache\x\x-1.0.pom Downloading http:\\repo1.maven.org\org\apache\x\x-1.0.pom . . . . . What I assumed of this was that it compares where the latest of the artifact is available even with same groupId+artifactId+version. But yesterday when I cross checked even at the remote repository had a artifact newly deployed (though with same groupId+artifactId+versionId) what I was seeing in the classpath was the one from local repository. Am I right in what I am concluding? Or again missing somewhere. If what I have concluded upon is right, is there a way to make maven pick up the one from remote repository(in case it is build and deployed later? ) Thanks and regards, Amit On Feb 8, 2008 4:55 AM, Graham Leggett [EMAIL PROTECTED] wrote: Dhruva Reddy wrote: What exactly is a goal and what is a phase? In maven 1, there were only goals, and goals were specific targets that were embedded in specific maven plugins, a bit like an ant target. So the jar plugin would have the jar goal which when run, would jar up some classes. It soon became apparent that this leaves too much up to the end user: what if the artifact you are producing isn't a jar, but an ear instead? Or a war file? Why should the user have to know or care that they must run the ear:ear goal instead of the jar:jar goal? Enter the phases of the lifecycle in maven 2. Plugins attach various goals to the various phases in the lifecycles, and depending on which phase of the lifecycle you've asked maven to complete, all the relevant goals attached to that lifecycle will be run up to that phase. So if you run mvn install (or run all goals in all phases up until the 'install' phase), maven figures out for itself that the compile:compile goal must run, and the ear:ear goal (because the artifact is an ear file), the user no longer needs to care. So to sum up: The lifecycle contains a list of phases, and each phase has a goal or goals attached to that phase. So running a phase is a convenient way of saying run all goals I need to run to make this artifact up to this phase, and don't tell me what those goals are, I don't care. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Concepts
Hi, This is an excellent explanation, thanks for posting. How do executions fit into this? Is it that the pom can define many executions of a plugin, each with different configuration and phases (and potentially goals). How do you 'run' a single execution of a plugin, in a similar way to calling mvn plugin:goal to run a goal? Thanks for any explanations, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Concepts
That makes two of us Dhruva. Seriously guys thanks a lot. Great help. On Feb 8, 2008 9:46 PM, Dhruva Reddy [EMAIL PROTECTED] wrote: This really clears things up--many thanks! -- Dhruva B. Reddy Senior Associate of Technology, Level 2 | Sapient 25 1st Street Cambridge, MA, 02141, USA desk: +1 617 452 1900 fax: +1 617 621 1300 www.sapient.com -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Thursday, 07 February 2008 17:01 To: Maven Users List Subject: Re: Maven Concepts You've got it exactly right. Maven builds are usually oriented around the concept of a lifecycle, which consists of phases in a specific order. Each phase has zero or more mojos (usually called goals) bound to it. Each phase in the lifecycle implies all of the phases that come before it. This allows users to bind (or configure) different goals to different phases of the build, then the standard phase names to run the build. The default goals for a given type of project are also bound to the lifecycle in this way, but behind the scenes, such that the user can supplement these default goals using configurations in the pom.xml. So, if you have a jar project (packagingjar/packaging), you might have something like this: Phase Goals --- validate(none) initialize (none) ... compileorg.apache.maven.plugins:maven-compiler- plugin:compile ... testorg.apache.maven.plugins:maven-surefire- plugin:test ... package org.apache.maven.plugins:maven-jar-plugin:jar ... install org.apache.maven.plugins:maven-install- plugin:install ... etc. Now, if you just want to compile your project, you simply call the 'compile' phase, like this: mvn compile If you want to run the unit tests, call this: mvn test Note that in order to run unit tests, you must have compiled your project's main sources. That's handled here, since the test phase is later in the lifecycle than the compile phase...'test' implies 'compile' and all the other phases (in order) that come before 'test'. On the other hand, Maven also supports certain one-off goals that are usually meant to help manage the project build in certain special cases, or give information about the build. One such example gives you a glimpse of the POM after all inheritance and profile injection has been completed: mvn help:effective-pom which is shorthand for: mvn org.apache.maven.plugins:maven-help-plugin:effective-pom Hope that helps, -john On Feb 7, 2008, at 4:50 PM, Dhruva Reddy wrote: I know this seems like a silly thing to post on here, but... What exactly is a goal and what is a phase? I can't find a good answer in the documentation and there's a lot of seemingly conflicting information out there. My current understanding is that a phase is a part of a lifecycle (process-resources, compile, etc). A goal is somewhat analogous to an ANT-task, but with a focus on what should happen, rather than how it is done. Can someone clear this up for me, giving examples? Thanks, Dhruva --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john rss: http://feeds.feedburner.com/ejlife/john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven Concepts
This really clears things up--many thanks! -- Dhruva B. Reddy Senior Associate of Technology, Level 2 | Sapient 25 1st Street Cambridge, MA, 02141, USA desk: +1 617 452 1900 fax: +1 617 621 1300 www.sapient.com -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Thursday, 07 February 2008 17:01 To: Maven Users List Subject: Re: Maven Concepts You've got it exactly right. Maven builds are usually oriented around the concept of a lifecycle, which consists of phases in a specific order. Each phase has zero or more mojos (usually called goals) bound to it. Each phase in the lifecycle implies all of the phases that come before it. This allows users to bind (or configure) different goals to different phases of the build, then the standard phase names to run the build. The default goals for a given type of project are also bound to the lifecycle in this way, but behind the scenes, such that the user can supplement these default goals using configurations in the pom.xml. So, if you have a jar project (packagingjar/packaging), you might have something like this: Phase Goals --- validate(none) initialize (none) ... compileorg.apache.maven.plugins:maven-compiler- plugin:compile ... testorg.apache.maven.plugins:maven-surefire- plugin:test ... package org.apache.maven.plugins:maven-jar-plugin:jar ... install org.apache.maven.plugins:maven-install- plugin:install ... etc. Now, if you just want to compile your project, you simply call the 'compile' phase, like this: mvn compile If you want to run the unit tests, call this: mvn test Note that in order to run unit tests, you must have compiled your project's main sources. That's handled here, since the test phase is later in the lifecycle than the compile phase...'test' implies 'compile' and all the other phases (in order) that come before 'test'. On the other hand, Maven also supports certain one-off goals that are usually meant to help manage the project build in certain special cases, or give information about the build. One such example gives you a glimpse of the POM after all inheritance and profile injection has been completed: mvn help:effective-pom which is shorthand for: mvn org.apache.maven.plugins:maven-help-plugin:effective-pom Hope that helps, -john On Feb 7, 2008, at 4:50 PM, Dhruva Reddy wrote: I know this seems like a silly thing to post on here, but... What exactly is a goal and what is a phase? I can't find a good answer in the documentation and there's a lot of seemingly conflicting information out there. My current understanding is that a phase is a part of a lifecycle (process-resources, compile, etc). A goal is somewhat analogous to an ANT-task, but with a focus on what should happen, rather than how it is done. Can someone clear this up for me, giving examples? Thanks, Dhruva --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john rss: http://feeds.feedburner.com/ejlife/john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Concepts
You've got it exactly right. Maven builds are usually oriented around the concept of a lifecycle, which consists of phases in a specific order. Each phase has zero or more mojos (usually called goals) bound to it. Each phase in the lifecycle implies all of the phases that come before it. This allows users to bind (or configure) different goals to different phases of the build, then the standard phase names to run the build. The default goals for a given type of project are also bound to the lifecycle in this way, but behind the scenes, such that the user can supplement these default goals using configurations in the pom.xml. So, if you have a jar project (packagingjar/packaging), you might have something like this: Phase Goals --- validate(none) initialize (none) ... compileorg.apache.maven.plugins:maven-compiler- plugin:compile ... testorg.apache.maven.plugins:maven-surefire- plugin:test ... package org.apache.maven.plugins:maven-jar-plugin:jar ... install org.apache.maven.plugins:maven-install- plugin:install ... etc. Now, if you just want to compile your project, you simply call the 'compile' phase, like this: mvn compile If you want to run the unit tests, call this: mvn test Note that in order to run unit tests, you must have compiled your project's main sources. That's handled here, since the test phase is later in the lifecycle than the compile phase...'test' implies 'compile' and all the other phases (in order) that come before 'test'. On the other hand, Maven also supports certain one-off goals that are usually meant to help manage the project build in certain special cases, or give information about the build. One such example gives you a glimpse of the POM after all inheritance and profile injection has been completed: mvn help:effective-pom which is shorthand for: mvn org.apache.maven.plugins:maven-help-plugin:effective-pom Hope that helps, -john On Feb 7, 2008, at 4:50 PM, Dhruva Reddy wrote: I know this seems like a silly thing to post on here, but... What exactly is a goal and what is a phase? I can't find a good answer in the documentation and there's a lot of seemingly conflicting information out there. My current understanding is that a phase is a part of a lifecycle (process-resources, compile, etc). A goal is somewhat analogous to an ANT-task, but with a focus on what should happen, rather than how it is done. Can someone clear this up for me, giving examples? Thanks, Dhruva --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john rss: http://feeds.feedburner.com/ejlife/john
Maven Concepts
I know this seems like a silly thing to post on here, but... What exactly is a goal and what is a phase? I can't find a good answer in the documentation and there's a lot of seemingly conflicting information out there. My current understanding is that a phase is a part of a lifecycle (process-resources, compile, etc). A goal is somewhat analogous to an ANT-task, but with a focus on what should happen, rather than how it is done. Can someone clear this up for me, giving examples? Thanks, Dhruva
Re: Maven Concepts
Dhruva Reddy wrote: What exactly is a goal and what is a phase? In maven 1, there were only goals, and goals were specific targets that were embedded in specific maven plugins, a bit like an ant target. So the jar plugin would have the jar goal which when run, would jar up some classes. It soon became apparent that this leaves too much up to the end user: what if the artifact you are producing isn't a jar, but an ear instead? Or a war file? Why should the user have to know or care that they must run the ear:ear goal instead of the jar:jar goal? Enter the phases of the lifecycle in maven 2. Plugins attach various goals to the various phases in the lifecycles, and depending on which phase of the lifecycle you've asked maven to complete, all the relevant goals attached to that lifecycle will be run up to that phase. So if you run mvn install (or run all goals in all phases up until the 'install' phase), maven figures out for itself that the compile:compile goal must run, and the ear:ear goal (because the artifact is an ear file), the user no longer needs to care. So to sum up: The lifecycle contains a list of phases, and each phase has a goal or goals attached to that phase. So running a phase is a convenient way of saying run all goals I need to run to make this artifact up to this phase, and don't tell me what those goals are, I don't care. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Maven Concepts
Continuing on this thread I would also like to put a doubt(misconception)- Until yesterday I used to think that if I have an artifact on local repository + remote repository with same groupId-artifactId-version. The maven will take the one which is built at a later time or some system property attached to it which maven uses to differentiate. The origin for this assumption was no matter if the artifact is present in my local repository maven shows Downloading \\remoteRepository\org\apache\x\x-1.0.pom Downloading http:\\repo1.maven.org\org\apache\x\x-1.0.pom . . . . . What I assumed of this was that it compares where the latest of the artifact is available even with same groupId+artifactId+version. But yesterday when I cross checked even at the remote repository had a artifact newly deployed (though with same groupId+artifactId+versionId) what I was seeing in the classpath was the one from local repository. Am I right in what I am concluding? Or again missing somewhere. If what I have concluded upon is right, is there a way to make maven pick up the one from remote repository(in case it is build and deployed later? ) Thanks and regards, Amit On Feb 8, 2008 4:55 AM, Graham Leggett [EMAIL PROTECTED] wrote: Dhruva Reddy wrote: What exactly is a goal and what is a phase? In maven 1, there were only goals, and goals were specific targets that were embedded in specific maven plugins, a bit like an ant target. So the jar plugin would have the jar goal which when run, would jar up some classes. It soon became apparent that this leaves too much up to the end user: what if the artifact you are producing isn't a jar, but an ear instead? Or a war file? Why should the user have to know or care that they must run the ear:ear goal instead of the jar:jar goal? Enter the phases of the lifecycle in maven 2. Plugins attach various goals to the various phases in the lifecycles, and depending on which phase of the lifecycle you've asked maven to complete, all the relevant goals attached to that lifecycle will be run up to that phase. So if you run mvn install (or run all goals in all phases up until the 'install' phase), maven figures out for itself that the compile:compile goal must run, and the ear:ear goal (because the artifact is an ear file), the user no longer needs to care. So to sum up: The lifecycle contains a list of phases, and each phase has a goal or goals attached to that phase. So running a phase is a convenient way of saying run all goals I need to run to make this artifact up to this phase, and don't tell me what those goals are, I don't care. Regards, Graham --
Re: Maven Concepts
I am no maven expert. AFAIK, only if it is SNAPSHOT (the one that ends with -SNAPSHOT) version then maven checks the timestamp etc. against the remote repository. Otherwise Maven always prefers the one in the local repository if one is available there. In your case, the artifact version looks to be 1.0 which means once the artifact is available in your local repo, maven won't go to remote repo for that one. Question why did the owner of the artifact chose to update the artifact, but did not bother to change the version number? Someone can correct me if need be. Thanks, Sahoo amit kumar wrote: Continuing on this thread I would also like to put a doubt(misconception)- Until yesterday I used to think that if I have an artifact on local repository + remote repository with same groupId-artifactId-version. The maven will take the one which is built at a later time or some system property attached to it which maven uses to differentiate. The origin for this assumption was no matter if the artifact is present in my local repository maven shows Downloading \\remoteRepository\org\apache\x\x-1.0.pom Downloading http:\\repo1.maven.org\org\apache\x\x-1.0.pom . . . . . What I assumed of this was that it compares where the latest of the artifact is available even with same groupId+artifactId+version. But yesterday when I cross checked even at the remote repository had a artifact newly deployed (though with same groupId+artifactId+versionId) what I was seeing in the classpath was the one from local repository. Am I right in what I am concluding? Or again missing somewhere. If what I have concluded upon is right, is there a way to make maven pick up the one from remote repository(in case it is build and deployed later? ) Thanks and regards, Amit On Feb 8, 2008 4:55 AM, Graham Leggett [EMAIL PROTECTED] wrote: Dhruva Reddy wrote: What exactly is a goal and what is a phase? In maven 1, there were only goals, and goals were specific targets that were embedded in specific maven plugins, a bit like an ant target. So the jar plugin would have the jar goal which when run, would jar up some classes. It soon became apparent that this leaves too much up to the end user: what if the artifact you are producing isn't a jar, but an ear instead? Or a war file? Why should the user have to know or care that they must run the ear:ear goal instead of the jar:jar goal? Enter the phases of the lifecycle in maven 2. Plugins attach various goals to the various phases in the lifecycles, and depending on which phase of the lifecycle you've asked maven to complete, all the relevant goals attached to that lifecycle will be run up to that phase. So if you run mvn install (or run all goals in all phases up until the 'install' phase), maven figures out for itself that the compile:compile goal must run, and the ear:ear goal (because the artifact is an ear file), the user no longer needs to care. So to sum up: The lifecycle contains a list of phases, and each phase has a goal or goals attached to that phase. So running a phase is a convenient way of saying run all goals I need to run to make this artifact up to this phase, and don't tell me what those goals are, I don't care. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
