I'm going through and fixing parts of the maven build system and learning
quite a bit. A few questions to the maven experts here:
* Right now we have this project structure:
shindig-project
shindig-parent
shindig-features
shindig-social-api
shindig-gadgets
shindig-server
shindig-samples
assembly
Is there any good reason for the intermediate shindig-parent project? In my
local tree I removed that and all seems to be working well. If we want
things really clean we could move the subprojects in the java directory up a
level.
* I've converted over to the new apache-rat plugin (0.6) and that seems to
be working better, I still have to put a long configuration in the
pluginManagement and reporting sections. Is there any way to use a combined
config for both? The new config looks like this:
+ <plugin>
+ <groupId>org.apache.rat</groupId>
+ <artifactId>apache-rat-plugin</artifactId>
+
+ <version>0.6</version>
+ <configuration>
+ <excludeSubProjects>false</excludeSubProjects>
+ <excludes>
+ <exclude>**/README*</exclude>
+ <exclude>**/target/**</exclude>
+ <exclude>**/php/external/**</exclude>
+ <exclude>**/features/swfobject/swfobject.js</exclude>
+ <exclude>**/features/swfobject/swfobject.opt.js</exclude>
+ <exclude>etc/svn-ignores</exclude>
+ <exclude>etc/svn-props</exclude>
+ <exclude>etc/eclipse/shindig.importorder</exclude>
+ <exclude>php/src/common/JsMin.php</exclude>
+ <exclude>php/test/misc/rewriter*.css</exclude>
+ <exclude>php/test/misc/rewriter*.js</exclude>
+ <exclude>php/test/misc/ok.html</exclude>
+ <exclude>BUILD-JAVA</exclude>
+ <exclude>COMMITTERS</exclude>
+ <exclude>**/MANIFEST.MF</exclude>
+ <exclude>**/src/test/resources/**/*.html</exclude>
+ <exclude>**/src/test/resources/**/*.css</exclude>
+ <exclude>**/src/test/resources/**/*.json</exclude>
+ <exclude>**/src/test/resources/**/*.xml</exclude>
+ <exclude>**/create.sql</exclude>
+ <exclude>**/drop.sql</exclude>
+ <exclude>**/derby.log</exclude>
+ </excludes>
+ </configuration>
+ </plugin>
I also note that the rat plugin gets confused with some of the optional
modules we use. For example the assembly and samples projects target
directories were being searched.
* The staged docs have broken links for sub-modules. Not sure if that works
in a regular deploy.. For now you can use these module specific URLs:
* I upgraded some of the plugins, all seems to be working fine:
cobertura-maven-plugin 2.2->2.3
findbugs-maven-plugin 1.2 -> 2.0.1
maven-site-plugin 2.0 -> 2.0.1
maven-checkstyle-plugin 2.2->2.3
maven-javadoc-plugin 2.5->2.6 (we'll see if 2.6 fixes the hudson build
issue...)
maven-pmd-plugin 2.1->2.4
* cobertura seems to be very fragile. when running with a plain mvn site I
had test errors, using site:stage with clean and install seems to get past
that. I still see some errors though:
[cobertura] WARN [main]
net.sourceforge.cobertura.instrument.ClassInstrumenter - No line number
information found for class org
.apache.shindig.gadgets.DefaultMessageBundleFactory$1. Perhaps you need to
compile with debug=true?
[cobertura] WARN [main]
net.sourceforge.cobertura.instrument.ClassInstrumenter - No line number
information found for class org
.apache.shindig.gadgets.http.HttpResponse$1. Perhaps you need to compile
with debug=true?
[cobertura] WARN [main]
net.sourceforge.cobertura.instrument.ClassInstrumenter - No line number
information found for class org
.apache.shindig.gadgets.oauth.OAuthResponseParams$1. Perhaps you need to
compile with debug=true?
[cobertura] WARN [main]
net.sourceforge.cobertura.instrument.ClassInstrumenter - No line number
information found for class org
.apache.shindig.gadgets.parse.GadgetHtmlParser$1. Perhaps you need to
compile with debug=true?
[cobertura] WARN [main]
net.sourceforge.cobertura.instrument.ClassInstrumenter - No line number
information found for class org
.apache.shindig.gadgets.spec.ModulePrefs$1. Perhaps you need to compile
with debug=true?
[cobertura] WARN [main]
net.sourceforge.cobertura.instrument.ClassInstrumenter - No line number
information found for class org
.apache.shindig.gadgets.spec.UserPref$1. Perhaps you need to compile with
debug=true?
* Some misc errors and oddities encountered:
-- [INFO] Unable to load parent project from a relative path: Could not find
the model file '/Volumes/SSD/pom.xml'. for project unknown
(seems to be a relative filename addressing issue.)
-- [WARNING] DEPRECATED [aggregate]: since 2.5. Use the goals
<code>javadoc:aggregate</code> and <code>javadoc:test-aggregate</code>
instead.
(not sure how to do that.. help appreciated..)