Thanks for the feedback.I think depdendencyManagement is useful too, but I also think I need to make more use of properties to reduce redundancy.
- Dave On Mon, Jan 4, 2010 at 7:17 PM, Denis Balazuc <[email protected]> wrote: > 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 >> > >> >
