7 messages in org.apache.roller.devRe: Mavenizing Roller| From | Sent On | Attachments |
|---|---|---|
| Dave | Dec 30, 2009 2:58 pm | |
| Denis Balazuc | Jan 3, 2010 11:51 am | |
| Matt Raible | Jan 4, 2010 2:22 pm | |
| Denis Balazuc | Jan 4, 2010 4:17 pm | |
| David Johnson | Jan 5, 2010 6:56 am | |
| Dave | Jan 6, 2010 4:59 am | |
| Laszlo Csaba Lorincz | Jan 9, 2010 4:58 pm |
| Subject: | Re: Mavenizing Roller | |
|---|---|---|
| From: | Laszlo Csaba Lorincz (lasz...@gmail.com) | |
| Date: | Jan 9, 2010 4:58:36 pm | |
| List: | org.apache.roller.dev | |
Hi!
I also got an error on mvn install:
[INFO] [jar:jar {execution: default-jar}] [INFO] Building jar: U:\works\Java\roller-dev\planet-business\target\roller-planet-business-5.0-BETA2-SNAPSHOT.jar [INFO] [antrun:run {execution: stopdb}] [INFO] Executing tasks Stopping Derby 2010-01-10 00:32:09.515 GMT : Apache Derby Network Server - 10.5.3.0 - (802917) shutdown [delete] Deleting directory U:\works\Java\roller-dev\planet-business\target\test-classes\derby-system [INFO]
------------------------------------------------------------------------ [ERROR] BUILD ERROR [INFO]
------------------------------------------------------------------------ [INFO] An Ant BuildException has occured: Unable to delete file U:\works\Java\roller-dev\planet-business\target\test-classes\derby-system\planet_business\derby.log
[INFO]
------------------------------------------------------------------------ [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: An Ant BuildException has occured: Unable to delete file U:\works\Java\roller-dev\planet-business\target\test-classes\derby-system\planet_business\derby.log at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: An Ant BuildException has occured: Unable to delete file U:\works\Java\roller-dev\planet-business\target\test-classes\derby-system\planet_business\derby.log at org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:131) at org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:98) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) ... 17 more Caused by: Unable to delete file U:\works\Java\roller-dev\planet-business\target\test-classes\derby-system\planet_business\derby.log at org.apache.tools.ant.taskdefs.Delete.handle(Delete.java:624) at org.apache.tools.ant.taskdefs.Delete.removeDir(Delete.java:683) at org.apache.tools.ant.taskdefs.Delete.removeDir(Delete.java:679) at org.apache.tools.ant.taskdefs.Delete.execute(Delete.java:543) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:357) at org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:118) ... 20 more
Do you use Maven in Eclipse too? If yes with which plugin: m2eclipse or Eclipse IAM?
thanks Laszlo
On Tue, Jan 5, 2010 at 1:17 AM, Denis Balazuc <den...@balazuc.net> 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 <ma...@raibledesigns.com> 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.Jetty6PluginWebAppContext@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 <snoo...@gmail.com> 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