-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You should never need to do that in maven2. Instead, you have an option
of defining a hierarchy of poms, and within that hierarchy defining a
set of managed dependencies. This is an important concept, since it
allows you to declare properties (notably version) of a dependency for
use in that hierarchy BUT NOT EVERYWHERE. What I mean is, you can define
it once in a parent pom in this way:

<project>
...
~  <dependencyManagement>
~    <dependencies>
~      <dependency>
~        <groupId>junit</groupId>
~        <artifactId>junit</artifactId>
~        <version>3.8.1</version>
~        <scope>test</scope>
~      </dependency>
~    </dependencies>
~  </dependencyManagement>
...
</project>

in the parent pom, and then refer to this in one or more of the child
poms like so:

<project>
...
~  <dependencies>
~    <dependency>
~      <groupId>junit</groupId>
~      <artifactId>junit</artifactId>
~    </dependency>
~  </dependencies>
...
</project>

In this child pom, the scope and version will be inferred from the
managed dependencies section of it's ancestry. However, if you define
another child pom like such:

<project>
...
~  <dependencies>
~    <dependency>
~      <groupId>something-else</groupId>
~      <artifactId>something-else</artifactId>
~      <version>1.0</version>
~    </dependency>
~    <!-- NOTE: no reference to junit here -->
~  </dependencies>
...
</project>

then THIS child will NOT have any dependency on junit; it will not be
included in any of the compile, test, or other classpaths during the
build, and it will not be bundled with that second child in any way.

Therefore, the managed dependencies allow you to provide standardization
of the usage for certain dependencies used in your project hierarchy,
without requiring that they be used in all subprojects.

For maven2, the pom is completely self-contained for portability. In
rare cases, you may also provide build profiles to specify certain
plugin configurations for different targeted builds, like for a
development environment vs. a testing environment. However, in general,
we're discouraging the old non-portable companion file approach that we
used in maven 1.x.

Hope that helps,

john

David Le Strat wrote:
| All,
|
| Does any one know the equivalent of build.properties
| in M2?  How can I do something like
|
| pom.xml:
|
| ....
| <dependency>
|     ...
|     <version>${my.dep.version}</version>
|     ...
| </dependency>
|
| Regards,
|
| David Le Strat.
|
| ________________________
| David Le Strat
| Blogging @ http://dlsthoughts.blogspot.com
|
|
|               
| ____________________________________________________
| Start your day with Yahoo! - make it your home page
| http://www.yahoo.com/r/hs
|
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: [EMAIL PROTECTED]
| For additional commands, e-mail: [EMAIL PROTECTED]
|
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFC1rC+K3h2CZwO/4URAu1OAKCCypl68GInmU50jPrJd+199TLxTwCeOsYN
IcI3KmCWN7xQWk9BAyKOqUU=
=o+On
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to