On Wed, Mar 30, 2011 at 12:44 AM, Anders Hammar wrote:
> Be aware that you're talking of two different strategies. Using a pom
> artifact as a dependency and using import scope to import depMgmt declared
> in another pom. Two different things!
>
Yes, that's exactly my point. I've seen import sc
Be aware that you're talking of two different strategies. Using a pom
artifact as a dependency and using import scope to import depMgmt declared
in another pom. Two different things!
/Anders
On Tue, Mar 29, 2011 at 22:18, Laird Nelson wrote:
> On Tue, Mar 29, 2011 at 3:35 PM, Anders Hammar wro
On Tue, Mar 29, 2011 at 3:35 PM, Anders Hammar wrote:
> Tim talks about this in this blog post:
>
> http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-grouping-dependencies/
>
Thank you, yes, this is the first I've seen this documented. So that seems
like you don't need import in orde
Tim talks about this in this blog post:
http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-grouping-dependencies/
A pom artifact is an artifact like all others...it's just that the artifact
is the pom itself.
/Anders
On Tue, Mar 29, 2011 at 19:59, Laird Nelson wrote:
> On Tue, Mar 29
On 29/03/2011 1:59 PM, Laird Nelson wrote:
On Tue, Mar 29, 2011 at 1:22 PM, Ron Wheeler
wrote:
We follow Stephen's path but build aggregation poms that only contain
libraries so that our project POMs only depend on our libraries.
For example if the war file needs the Apache Commons that we suppor
On Tue, Mar 29, 2011 at 2:01 PM, Wendy Smoak wrote:
> Are you asking about import scope?
>
> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies
>
I guess I am; is it required that when you're using import scope that the
element be set to
On Tue, Mar 29, 2011 at 1:59 PM, Laird Nelson wrote:
> Just out of curiosity, where is it written down that one can depend on an
> artifact of type pom? I've always been curious about this.
Are you asking about import scope?
http://maven.apache.org/guides/introduction/introduction-to-dependency
On Tue, Mar 29, 2011 at 1:22 PM, Ron Wheeler wrote:
> We follow Stephen's path but build aggregation poms that only contain
> libraries so that our project POMs only depend on our libraries.
> For example if the war file needs the Apache Commons that we support in our
> development environment, t
We follow Stephen's path but build aggregation poms that only contain
libraries so that our project POMs only depend on our libraries.
For example if the war file needs the Apache Commons that we support in
our development environment, the project will depend on the current
version of ours-lib-c
juranta wrote:
> Well, we put all the versions in the parent pom. It makes the versions
> easy to change from the project's perspective. You don't have to browse
> through many files to see where the dependency is declared. Also, two or
> more of the sub-project may have a dependency on a same art
if you put the
version in the parent pom, you have the version in only one place.
--
View this message in context:
http://maven.40175.n5.nabble.com/Versions-in-dependencyManagement-vs-dependency-tp4269473p4269530.html
Sent from the Maven - Users mailing list archive at
it depends on how often you update versions and how often you will
release the parent.
if you update versions very often, but you don't want to release the
parent very often, then don't do it.
what I tend to do is aggregate the version info as high up in each
independently releasable tree.
On 29
Got a bit of an architecture/style question here.
I'm familiar with the use of the dependencyManagement block in a parent pom to
fix versions of or otherwise configure a dependency. However, except for cases
which need it (for example, when transitive dependencies are otherwise pulling
in two
13 matches
Mail list logo
