Hi Matt, Hi all
My 2 cents on <dependencyManagement>
One of the main advantage of using this tag is that you will not have to
specify versions and scopes in children POMs, thus providing a central place
for managing all JARs and making the child POM much simpler, avoiding
version mix-up in the process. Usually, it's used in combination with
<properties>:
Example:
In your parent POM
<properties>
<my.package.version>0.1</my.package.version>
</properties>
<dependencyManagement>
<dependency>
<groupId>my.package</groupId>
<artifactId>artifact</artifactId>
<version>${my.package.version}</version>
<scope>runtime</scope>
</dependencyManagement>
If you want to use the above dependency in your child POM, you will only
have to do:
<dependency>
<groupId>my.package</groupId>
<artifactId>artifact</artifactId>
</dependency>
which is very nice and lightweight, compared to specifying <version> and
maybe <scope> on each child dependency.
You can also set <exclusion> in <dependencyManagement>, so as to make sure
that children will not inadvertently import unwanted packages through their
dependency settings, and that is in my opinion a great feature as it avoids
having to browse dependency graphs to find out who imported "unwanted.jar"
in the resulting assembly and repeat <exclusions> all over the place.
In another related topic, I'm in favor of always specifying <packaging> and
<scope> even if there are some default. Default values always require that
you know about them and may hide important details to those who aren't
familiar with Maven (this remark stands for any other kind of code
actually...yes I am one who always specify super() in my constructors....sue
me :D )
Hope this helps
Cheers
On Mon, Jan 4, 2010 at 5:22 PM, Matt Raible <[email protected]> wrote:
> Finally got a chance to look at this today. Here's some findings:
>
> * In the root pom.xml, there's a <repositories> element. Ideally, this
> is only configured for snapshots and the rest of the dependencies are
> in Maven's central repo. For example, here's AppFuse's:
>
> <repositories>
> <repository>
> <id>appfuse-snapshots</id>
> <url>
> http://oss.sonatype.org/content/repositories/appfuse-snapshots</url>
> <releases>
> <enabled>false</enabled>
> </releases>
> <snapshots>
> <enabled>true</enabled>
> </snapshots>
> </repository>
> </repositories>
>
> If artifacts are not in the Central Repo, we should do our best to get
> them in there. I can help with that if you like.
>
> * There's no <distributionManagement> section for deploying snapshots
> and releases. Apache has a Nexus instance at
> https://repository.apache.org that we should be able to leverage for
> this.
>
> * <type>jar</type> is unnecessary since it's the default. Same goes
> for <scope>compile</scope>.
>
> * An XSD on <project> might give IDEs better support for Maven.
>
> * The <dependencyManagement> section is useful for managing versions,
> but seems cumbersome to me. I tend to use <properties> instead and
> define them at the root level. I don't know if <dependencyManagement>
> provides more than I'm aware of.
>
> * Shouldn't the test dependencies use <scope>test</scope> so they're
> not included in the distribution? If they should be included, you
> might want to remove the "test deps" comment in the root pom.xml.
>
> * Why is javax.mail provided? It's available in the central repo and
> it might make more sense to distribute it with Roller.
>
> * I get "[WARNING] Using platform encoding (MacRoman actually) to copy
> filtered resources" when running "mvn install". Adding
> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> to
> the <properties> section will fix this.
>
> * When I tried to run "mvn jetty:run" on the weblogger-web project, I
> received the following error:
>
> [INFO] Starting jetty 6.1.22 ...
> 2010-01-04 15:21:21.762:INFO::jetty-6.1.22
> 2010-01-04 15:21:22.023:WARN::Config error at <New id="rollerdb"
>
> class="org.mortbay.jetty.plus.naming.Resource"><Arg>jdbc/rollerdb</Arg><Arg>|
> <New class="org.apache.commons.dbcp.BasicDataSource"><Set
> name="driverClassName">org.apache.derby.jdbc.ClientDriver</Set><Set
> name="url">jdbc:derby://localhost:3219/rollerdb;create=true</Set><Set
> name="username">APP</Set><Set name="password">APP</Set></New>|
> </Arg></New> java.lang.ClassNotFoundException:
> org.apache.commons.dbcp.BasicDataSource
> 2010-01-04 15:21:22.024:WARN::Failed startup of context
> org.mortbay.jetty.plugin.jetty6pluginwebappcont...@d338d3d
> {/roller-weblogger-web,/Users/mraible/Work/roller/weblogger-web/src/main/webapp}
> java.lang.ClassNotFoundException: org.apache.commons.dbcp.BasicDataSource
>
> Cheers,
>
> Matt
>
>
> On Wed, Dec 30, 2009 at 3:58 PM, Dave <[email protected]> wrote:
> > Re: Mavenize Roller (https://issues.apache.org/jira/browse/ROL-1849)
> >
> > I just did a complete Mavenization of Roller and comitted it into the
> > roller_mavenized branch. I created the following Maven bundles:
> >
> > test-utils: test utils (e.g. start/stop Derby task)
> > roller-core: core Roller component
> > planet-business: Planet POJOs and business logic
> > planet-web: Planet webapp (under construction as before)
> > weblogger-business: Weblogger POJOs and business logic
> > weblogger-web: Weblogger webapp, rendering system, Struts2 UI
> > weblogger-assembly: assembly that builds Roller distro
> >
> > To build and run all unit tests, you do this:
> >
> > svn co
> https://svn.apache.org/repos/asf/roller/branches/roller_mavenized
> > cd roller_mavenized
> > mvn install
> >
> > You'll find the Roller webapp in weblogger-web/target/roller. To build
> > a Roller distribution, you do this:
> >
> > cd weblogger-assembly
> > mvn assembly:single
> >
> > And you will find Roller distribution files in weblogger-assembly/target
> >
> > I still need to do a little work to trim down the number of jars in
> > WEB-INF/lib but other than that, I'm ready to merge this into trunk. I
> > think it will be a great improvement. It will make it easier for new
> > developers to understand the Roller source code and to do development
> > in Eclipse, IDEA, Netbeans and any other IDE that has Maven support. I
> > know it is late in the "release cycle" but we will have time to work
> > out the kinks as we create 5.0 betas and release candidates.
> >
> > I hope to merge this work into the trunk this weekend. Does anybody
> > object to this?
> >
> > Thanks,
> > - Dave
> >
>
