acra jar not in any maven repositories?

[GoogleCodeExporter]

Is acra.jar available in any maven repositories?  I checked around and couldn't 
find it anywhere.

(Thanks for the great tool by the way, and apologies if I overlooked something 
blindingly obvious in my search.)

Original issue reported on code.google.com by brstr...@gmail.com on 18 Nov 2010 at 11:07

[GoogleCodeExporter]

We did not do anything to make it available on mvn repositories. If people 
think it would be useful, I'll look how to do it. I have no maven knowledge, so 
if you want to help, you are welcome ;-)

Original comment by kevin.gaudin on 18 Nov 2010 at 11:17

• Added labels: Type-Other
• Removed labels: Type-Defect

[GoogleCodeExporter]

I'm a maven non-user myself; I only use the maven repos from scala (via sbt and 
its ivy support, which can use maven repos), so I'm pretty far from useful 
here, sadly.  
http://www.vineetmanohar.com/2009/12/publishing-to-maven-central-repo-in-5-steps
/ looked handy though.  Since it looks like acra is an eclipse-based project, 
http://maven.apache.org/eclipse-plugin.html might be useful too.

From painful experience, I know it's easy to get bogged down in build 
infrastructure quagmires, so as a stop-gap would it be possible to publish the 
acra-$version.jar directly, in addition to the zip?

Original comment by brstr...@gmail.com on 19 Nov 2010 at 6:02

[GoogleCodeExporter]

Sorry if I wasn't clear, by "publish" I meant on google code next to the 
existing zips.

Original comment by brstr...@gmail.com on 19 Nov 2010 at 6:04

[GoogleCodeExporter]

How do you build ACRA Jar ? Did you document the steps somewhere ? I think ACRA 
could be Mavenized, and use its SVN repo as a Maven repository. That's quite 
easy to do when the project is well organised. However, currently, it seems 
that the same folder on the svn contains both a sample project and the ACRA 
library.

I'd be glad to help if you tell me how you currently build the ACRA jar ;-) . 
I've done it for AndroidAnnotations 
(http://code.google.com/p/androidannotations/source/browse/trunk/AndroidAnnotati
ons/pom.xml), so that releasing now is only a matter of typing "mvn 
release:prepare && mvn release:perform".

Original comment by py.ricau on 22 Mar 2011 at 10:11

[GoogleCodeExporter]

Hi Pierre-Yves, there is an open discussion on this topic:
https://groups.google.com/forum/#!topic/acra-discuss/SEmpPj34hps
I would be really happy if you joined the effort for a better build ;-)

Original comment by kevin.gaudin on 22 Mar 2011 at 10:51

[GoogleCodeExporter]

OK, I've attached 2 Maven POMs (build files).
The first is a bare bones build that builds acra.
It could be simpler, but would require 
1) the java files in the src folder being moved to src/main/java 
2) the other files in the src folder being moved to either src/main/resources 
or src/site depending on whether you want to ship them as part of Acra or as 
part of the published site.

The 2nd POM shows a few more possibilities of what can be configured as part of 
a Maven POM. This is where we would configure URLs for distribution of released 
artefacts and any website for publishing.

To get the POM to build Acra, do the following.
Install Maven 3.0 (3.0.3 is current) http://maven.apache.org/download.html
Set MAVEN_HOME and add MAVEN_HOME/bin to path.
Put the attached Maven POM in the root of the Acra folder.
On a command line (you can configure your IDE to do this too, but start with 
the simple approach), go to the ACra folder and type:
  mvn install

This will compile all the sources, gather the resources, jar them and give the 
jar a version. The jar will be in the target folder.
It will also install that jar into your local (your machine only) Maven 
repository. So it has now become visible to all other builds on your machine.

OK, that was long. My apoligies.
Since as Pierre has noted, the sample and some web-site resources (the doc 
folder) is mixed in the same project as the Acra source, I suggest that the 
next step (assuming its thought to be a good idea) would be to create a 
sub-module holding just the Acra source and any web-site resources and mavenize 
it. 
We can then create a sub-module for the sample source. Unless you just want to 
publish it as part of the web-site, in which case we could do it as a single 
module.

Anyway for a really good understanding of all the benefits Maven can provide, 
so night time reading is 
http://repo.exist.com/dist/maestro/1.7.0/BetterBuildsWithMaven.pdf

Original comment by william....@gmail.com on 22 Mar 2011 at 11:58

Attachments:

• pom.xml
• pom2.xml

[GoogleCodeExporter]

Pierre, if Acra goes down this path, then I would appreicate your help getting 
the distribution configured as you did for AndroidAnnotations.

Original comment by william....@gmail.com on 22 Mar 2011 at 12:01

[GoogleCodeExporter]

That would be a pleasure. The only thing that bother me is that I think we 
should make Acra more "maven like", which would also mean moving somes files 
around. Providing patches will not suffice, we might need commit access, or 
creating a clone. What do you think, Kévin ?

Original comment by py.ricau on 22 Mar 2011 at 1:46

[GoogleCodeExporter]

I think I'm gonna let Pierre-Yves refactor the project... at least I know I can 
find him and kick his ass if anything goes wrong ;-))))

Original comment by kevin.gaudin on 22 Mar 2011 at 3:44

[GoogleCodeExporter]

Done.

The Maven version of ACRA is currently available in the following branch :
* (browsable) 
http://code.google.com/p/acra/source/browse/#svn%2Fbranches%2Fmaven_build
* (SVN) http://acra.googlecode.com/svn/branches/maven_build/

To use it :

* Delete the previous ACRA project from your Eclipse workspace
* Install the M2Eclipse plugin in your Eclipse
* Install the SVN / M2Eclipse integration if you need it (I use git svn to 
basically I don't need any VCS integration with my IDE).
* Import the ACRA project from SVN, as a Maven project
* Import the example project from SVN
* The example project references the ACRA project throught Eclipse. This is 
because I didn't wanted to mavenize the example project, and I wanted ACRA 
project changes to be instantly available in the example project.

Please test it, test it and test it, to make sure I didn't break anything.

I also made a test release, using the svn as a maven repo. The release is 
available here :
http://acra.googlecode.com/svn/repository/releases/org/acra/acra/3.1.1-maven-tes
t/

To create a new release :
* Go into the "acra" folder, and enter the following command

mvn release:prepare
mvn release:perform

If the "mvn release:perfom" command hangs forever on a certificate stuff, just 
Ctrl+C, do a "mvn deploy", accept permanently the certificate (p), then Ctrl+C 
immediately after and "mvn release:perform" again.

When everything seems OK, I'll merge my changes into the trunk. But please 
don't put too much confidence on my work, and check it works ;-)

Original comment by py.ricau on 22 Mar 2011 at 5:57

[GoogleCodeExporter]

One more thing : the maven release standard way or naming tags is "acra-1.3.2", 
not "REL-1_3_2" (JCD habit ? :P). It doesn't really matter, but when using the 
mvn release plugin it's going to be faster if you just have to press "enter" to 
validate the default choices.

Original comment by py.ricau on 22 Mar 2011 at 6:01

[GoogleCodeExporter]

And of course, many thanks to William Ferguson that wrote the POM, integrating 
it was a no brainer ;-)

Original comment by py.ricau on 22 Mar 2011 at 6:02

[GoogleCodeExporter]

Oh, and one last thing (I promess, last thing) : if you have a mavenized 
Android project, you will need the following repository :

<repositories>
        <repository>
                <id>acra-repository</id>
                <name>acra Maven2 repository</name>
                <url>http://acra.googlecode.com/svn/repository/releases</url>
        </repository>
</repositories>

And the following dependency:

        <dependency>
                <groupId>org.acra</groupId>
                <artifactId>acra</artifactId>
                <version>3.1.1-maven-test</version>
        </dependency>

Original comment by py.ricau on 22 Mar 2011 at 6:05

[GoogleCodeExporter]

Nice work Pierre! A very crisp POM.
Especially like using the SVN repository to host the built artefacts.

I can confirm I can build branches/maven_build/acra
Both using the command line (and IntelliJ).

Next steps?

It would be great to simplify the examples folder and clarify its intent.
Is it just to provide a code example?
If so, then we can lose the doc, javadoc and res folders along wih all the 
files in the root.

It would be great to have the Acra project generate a web site as part of a 
release. Perhaps deploying it to the wiki? I'd vote for Javadoc at the least, 
but there are loads of other good reports about code health that can be auto 
generated. You could also have it generate those pages on the current wiki 
(sans comments) ie http://code.google.com/p/acra/w/list but it might be easier 
to just maintain them in the wiki itself.

Original comment by william....@gmail.com on 22 Mar 2011 at 9:53

[GoogleCodeExporter]

Any hint on how to have the Maven release plugin generate the doc and publish 
it to some SVN repo ? It could be done manually using "mvn javadoc:javadoc" + 
"svn add", but I think the mvn release plugin can handle it (I just can't 
remember how to do so).

Original comment by py.ricau on 22 Mar 2011 at 11:39

[GoogleCodeExporter]

The release plugin can and normally does as part of release:perform, but it 
looks like Maven 3 can't (at this point).

The ability to execute the reports has been temporarily removed, see "Site and 
reporting" at https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html

2 options
1) Require that Maven 2 be used to build Acra and include the Maven2 reporting 
config.
2) Use Maven 3 and until reporting becomes available generate any reports 
explicitly. We could probably bind javadoc:javadoc goal and svn:add to one of 
the release phases and make sure they happen then.

However, wouldn't it be better to make the Javadoc available via the site 
rather than committing it to SVN? Is there a way to injct a bunch of html into 
the wiki?

Original comment by william....@gmail.com on 22 Mar 2011 at 11:58

[GoogleCodeExporter]

Actually, the Wiki is on the svn ;-) .

See http://code.google.com/p/acra/source/browse/#svn%2Fwiki

Original comment by py.ricau on 23 Mar 2011 at 12:11

[GoogleCodeExporter]

Ah, well in that case add it to SVN.
I'd suggest a new folder for each version.

Original comment by william....@gmail.com on 23 Mar 2011 at 12:22

[GoogleCodeExporter]

Ok guys, I've been able to update my dev tools and perform a release:prepare 
successfuly. Had a few issues with upgrading an old CLI svn, but now it is 
running fine.

A few questions:
- the CrashReports-Template.csv file is a part of the release. It should be in 
the acra project and not the example as it can evolve with acra releases. Where 
should we put it in a "clean" maven project ?
- I think we should continue to publish the good old .zip package which 
includes the acra jar, javadoc and .csv. I don't think all android developers 
use maven on their projects. How do we procede to generate it ? the ant build 
file was doing it since recently, can maven create this locally so I can add it 
in googlecode's downloads ?

About the "example" application. My usage of it is for testing purposes. I have 
a not-commited-yet version with new features (a preferences screen to test the 
behavior of the new preference items). Having it in a separate project is ok 
for me.

Original comment by kevin.gaudin on 23 Mar 2011 at 12:39

[GoogleCodeExporter]

- While CrashReports-Template.csv evolves with the codebase, its not something 
you want to package up in the shipped jar. I see it as something that needs to 
be deployed to the website with each release. SO I would be inclined to move it 
back to the Acra project and include it under src/site where it can included as 
one of the resources making up the Acra release site.

- I'd be disinclined to continue packaging up a zip archive. IMO the javadoc 
and the template CSV should both be published via the Acra website (as part of 
a release), though its common to publish jars for both the javadoc and source 
alongside the compiled classes in a Maven release. And to access the Javadoc 
eithe via the website or as a separate release bundle doesn't require the user 
to be using Maven.
However, if your heart is set on it, the maven-assembly-plugin could be 
configured to package up the library jar, javadoc jar and template CSV.

- If the example application is just for testing (and not as example) then I 
would recommend 
1) renaming it
2) stripping out the doc and javadoc folders.
However, I think the idea of a source code example or two that is published to 
the website (or as a source bundle) is an excellent idea.

Original comment by william....@gmail.com on 23 Mar 2011 at 12:52

[GoogleCodeExporter]

Pierre, just noticed that it loks like maven-site-plugin-3.0-beta-3 should now 
work with Maven 3.0. So we might be able to generate the site using Maven 3,0 
after all.

Original comment by william....@gmail.com on 23 Mar 2011 at 12:59

[GoogleCodeExporter]

Ok, so my understanding is that now we should move the sources of the wiki 
pages + the .csv template to acra/src/site and let maven publish them when 
releasing a new version ? It could work for me, I usually don't update the Wiki 
pages directly from the googlecode web interface. And even if I wanted to do it 
on the go without dev tools, the source browser now allow to edit files.

About the javadoc, as all the storage for googlecode projects is on svn, I had 
decided to store an up-to-date version of the javadoc in each release tag. This 
allowed to browse the correct javadoc for each specific release just by going 
in its tag.

If the release:prepare can't do this, we might create a /javadoc/acra-X.Y.Z/ 
folder for each release.

Original comment by kevin.gaudin on 23 Mar 2011 at 1:33

[GoogleCodeExporter]

Yes to moving the wiki sources and CSV template to src/site.
I can't recall exact position off hand. Section 3.10 of Better Builds with
Maven details site generation.

Unfortunately it doesn't support straight HTML
� The XDOC format, which is a simple XML format used widely at Apache.
� The APT format (Almost Plain Text), which is a wiki-like format that
allows you to write simple,
structured documents (like this) very quickly. A full reference of the APT
Format is available.
� The FML format, which is the FAQ format. A simple XML format for managing
FAQs.
� The DocBook Simple format, which is a less complex version of the full
DocBook format.
Maven also has limited support for:
� The Twiki format, which is a popular Wiki markup format.
� The Confluence format, which is another popular Wiki markup format.
� The DocBook format.

I like the idea of versioned Javadoc.
I have always wanted to get the site/release plugins to generate a versioned
site, I just haven't spent the time to make it happen yet.

Commit the wiki source and I'll string something together.
Just a bit busy today.

Original comment by william....@gmail.com on 23 Mar 2011 at 1:43

[GoogleCodeExporter]

I'm not really sure to understand exactly what you want to be generated as the 
project site (this is due to my lack of maven knowledge) and how this will 
integrate in GoogleCode structure.

For project documentation, standard GoogleCode projects are just a bunch of 
.wiki files in the /wiki svn structure. I don't think we can host there 
anything but those .wiki files to be rendered by GoogleCode with their 
WikiSyntax: http://code.google.com/p/support/wiki/WikiSyntax#Wiki_Syntax

We can override each project tab destination but only to target a GoogleDoc 
wiki page.

We can have a browsable html subtree in SVN (the javadoc is a good example) but 
we will have to put a link in a GoogleDoc wiki page to give users access to it.

Original comment by kevin.gaudin on 23 Mar 2011 at 6:03

[GoogleCodeExporter]

We can choose to include whatever we like on the project site.
A typical Maven site includes some details about the project, team, usage, 
javadoc, whatever is appropriate for the intended audience.

Here is an example of an GUI app that is intended to be used by generally 
non-technical users: http://www.xandar.com.au/projects/laserforce-scaling/

Since Acra is a technical project that already has some of this provided by the 
GoogleCode infrastructure, I would suggest a project site that includes:
- usage, ie descriptive code examples
- javadoc
- we can include other metrics here too (for very little extra effort). but 
Javadoc is probably plenty right now.

The Maven site plugin generates its output in html, so pushing the project site 
to an SVN folder and referencing that from the GoogleDoc wiki sounds like a 
good solution.

Original comment by william....@gmail.com on 23 Mar 2011 at 6:20

[GoogleCodeExporter]

Hello!

I have moved the missing files from the example folder to the acra folder. I've 
then configured the build to use the Maven assembly plugin, that can generates 
ZIP artifacts. I have configured it so that it exactly matches the old ZIP 
distribution of acra, except that it also contains the sources jar.

When running "mvn release:perform", the ZIP artifact is pushed to the 
repository.

I've made a test release, which is located here : 
http://acra.googlecode.com/svn/repository/releases/org/acra/acra/3.1.1-MVN_TEST_
ZIP/

=> The zip file is 
http://acra.googlecode.com/svn/repository/releases/org/acra/acra/3.1.1-MVN_TEST_
ZIP/acra-3.1.1-MVN_TEST_ZIP.zip

The name of the zip is "acra-VERSION.zip".

Here is the content of the ZIP :

acra-3.1.1-MVN_TEST_ZIP/
|-- build
|   `-- acra-3.1.1-MVN_TEST_ZIP.jar
|-- doc
|   |-- acra-3.1.1-MVN_TEST_ZIP-javadoc.jar
|   |-- CrashReports-Template.csv
|   `-- html-javadoc
|       |-- [...] A LOT OF HTML FILE [...] 
|-- LICENSE
|-- NOTICE
`-- src
    `-- acra-3.1.1-MVN_TEST_ZIP-sources.jar

Original comment by py.ricau on 23 Mar 2011 at 10:27

[GoogleCodeExporter]

On the "wiki / site / online javadoc" topic : I don't really like mvn sites. I 
find them ugly, and I'm always a bit lost when looking for some specific 
information. Too me, it seems that it contains too much useless auto generated 
information.

I like Google code wiki docs, and I don't think there should be one frozen 
version per release. Plus, it's quite easy to edit them online using Google 
Code.

On the other side, I do think that it is a good idea to have online browsable 
javadocs, one per version. We can publish those javadocs html files to the svn, 
but that's not enough : you also need to give them the right svn mime type 
property, otherwise your browser will render them raw.

To do so automatically, you need to configure your svn client before committing 
the files. The procedure is described here : 
http://code.google.com/p/maven-googlecode-plugin/wiki/MavenSiteDeployOnSVN

Basically : edit ~/.subversion/config and add the following :

enable-auto-props = yes

### Section for configuring automatic properties.
[auto-props]
*.png = svn:mime-type=image/png
*.jpg = svn:mime-type=image/jpeg
*.gif = svn:mime-type=application/octet-stream
*.xml = svn:eol-style=native;svn:mime-type=text/xml
*.css = svn:eol-style=native;svn:mime-type=text/css
*.js = svn:eol-style=native;svn:mime-type=text/javascript
*.sql = svn:eol-style=native;svn:mime-type=text/plain
*.txt = svn:eol-style=native;svn:mime-type=text/plain
*.html = svn:eol-style=native;svn:mime-type=text/html
*.properties = svn:eol-style=native;svn:mime-type=text/plain
*.php = svn:eol-style=native;svn:mime-type=text/plain
*.tpl = svn:eol-style=native;svn:mime-type=text/html
*.ptpl = svn:eol-style=native;svn:mime-type=text/plain

And that's all!

Here is the procedure I used to push the Javadocs online.
After running "mvn release:perform" in your project, stay in the same 
directory, and run the following command (adapt the version number before).

svn checkout https://acra.googlecode.com/svn/javadoc
cp -r target/apidocs javadoc/acra-3.1.1-MVN_TEST_ZIP
cd javadoc
svn add acra-3.1.1-MVN_TEST_ZIP
svn commit -m "Uploading Javadocs for version acra-3.1.1-MVN_TEST_ZIP"

And done: the Javadoc is available online. E.g.: 
http://acra.googlecode.com/svn/javadoc/acra-3.1.1-MVN_TEST_ZIP/index.html

When everyone is OK and the branch is merged to the trunk, we should 'svn rm' 
the versions / artifacts / javadocs that we have created for testing purposes.

Original comment by py.ricau on 23 Mar 2011 at 10:48

[GoogleCodeExporter]

I have created a new wiki page that sums up the knowledge written here on how 
to create a new release: http://code.google.com/p/acra/wiki/Releasing

Original comment by py.ricau on 23 Mar 2011 at 11:37

[GoogleCodeExporter]

On the wiki vs. mvn site topic, let's keep it simple for the moment. I'd
like to experiment maven myself before going further.

Thanks a lot to both of you for your efforts in enhancing the project
structure, it would have taken months for me to do this with the so rare
time I can allow to acra (nights, between 0:00 and 2:00).
Le 23 mars 2011 12:38, <acra@googlecode.com> a �crit :

repositories?

Original comment by kevin.gaudin on 23 Mar 2011 at 12:30

[GoogleCodeExporter]

You're welcome. I'll merge to the trunk when you'll say "go" ;-) .

Original comment by py.ricau on 23 Mar 2011 at 1:02

[GoogleCodeExporter]

Well, the build/release process looks good to me, "go" ! :-)

Original comment by kevin.gaudin on 24 Mar 2011 at 12:05

[GoogleCodeExporter]

Did you want to try to build and publish any project doco (including wiki pages 
or Javadoc) to SVN as html during release? If so, let me know what you want 
built and I'll see what I can do.

Otherwise its looks good to go.

Original comment by william....@gmail.com on 24 Mar 2011 at 12:10

[GoogleCodeExporter]

@William : well, with the current process it is manual, so if you find out a 
way to automate this, that would be great.

Here is what the release should do :

- generate Javadocs as HTML (already done, can be found in target/apidocs)
- Upload the HTML Javadoc via SVN to 
http://acra.googlecode.com/svn/javadoc/acra-${project.version}

BTW, I'll merge the current changes to trunk.

Original comment by py.ricau on 24 Mar 2011 at 12:22

[GoogleCodeExporter]

Here is what I've done

- merged to trunk
- removed the empty folders (git..)
- removed the old Ant files.
- removed the test releases and snapshots on the repository
- removed the test javadocs

- deployed a snapshot : 3.1.2-SNAPSHOT 
(http://acra.googlecode.com/svn/repository/snapshots/org/acra/acra/3.1.2-SNAPSHO
T/)
- uploaded the 3.1.2-SNAPSHOT javadoc 
(http://acra.googlecode.com/svn/javadoc/3.1.2-SNAPSHOT/)
- Wrote a Maven wiki page : http://code.google.com/p/acra/wiki/Maven

I didn't create any release, only the snapshot, because releasing is your 
responsability Kévin ;-) . I think it would be nice to create a release ASAP, 
so that users may depend on it instead of depending on a snapshot.

I've moved this bug to the "Fixed" status. I'll let you change it to "Verified" 
Kévin ;-) (I miss TestTrack Pro... :-P)

Original comment by py.ricau on 24 Mar 2011 at 1:35

• Changed state: Fixed

[GoogleCodeExporter]

OK, the attached patch configures the site-plugin such that 'mvn site' will 
generate a website for the project that includes a bunch of reports. Ths is 
normally executed (automatically) as part of the release process.

I've tried to only include those I think there might be some interest in.
Rather than me walk through all the reports here, I suggest you apply the patch 
locally and have a look for yourself. Some of the reports are more client 
facing and some targeted more at the development team.

For instance the PMD and checkstyle reports are more for the Acra development 
team to track project health. While the jxr (publishes the source as 
referenceable line numbered html) and javadoc are more or users of Acra.

Any report can be switched off, and all are configurable.
I have made a personal config change to the checkstyle report to only report 
line numbers greater than 160 (the default is 80) because I haven't been 
limited to an 80 column terminal inside of the last 10 years.

Some of the reports (the developer facing ones) can also be configured (or 
alternatively configured) to run as part of the build and optionally fail if 
violated.

Kevin this should give you some idea over whats available report wise within 
Maven. I understand Pierre's dislike of Maven project sites, I don't like the 
default behaviour myself. I try to cut down the site to be the bare minimum 
that gets the info across. Ie go for a high power/weight ratio.

Anyway, see what value you find.

Original comment by william....@gmail.com on 30 Mar 2011 at 2:29

Attachments:

• acra-reports-patch.txt

[GoogleCodeExporter]

Thanks for your work ! I'm on holiday till the end of the week, I'll
have a look when I'm back ;-)

Le mercredi 30 mars 2011,  <acra@googlecode.com> a �crit�:

Original comment by py.ricau on 1 Apr 2011 at 5:41

[GoogleCodeExporter]

Hi William,

I just generated the site after applying your patch. Here are my comments about 
the reports:
  * dependencies: ACRA does not (and should not) depend on anything else than android. Introducing the "transitive dependencies" reported by maven could let ACRA users think that they HAVE to include these other libs to their projects whereas they are included in the android framework. I don't want it.
  * Issue tracking: irrelevant, links from the googlecode project page are enough
  * Project license: there is already a link to the license in the googlecode project pages
  * Project summary + Project Team: googlecode Home Page + Users tab are already there
  * Source repository: checkout instructions from the googlecode Source tab are guaranteed to be always relevant
  * Change Log: googlecode Source/Changes page provides the same data
  * Checkstyle: ok, there are interesting points, as always with checkstyle. My opinion is that if we start caring about this, it should be enforced on build time.
  * Copy/Paste Detector: somewhat interesting... even if the reported code duplications come from external code (Base64 is a copy of the android Base64 impl which is only available since API 8, and CrashReportData is a modified version of java.util.Properties).
  * Developer Activity: not really useful for the moment...
  * File Activity: I don't think it is really useful for a small project like ACRA (23 source files).
  * Javadocs: already managed with the current deployment
  * PMD: could be useful to validate builds frequently
  * source XRef: I think the googlecode source browser is much better. Links from checkstyle/PMD reports are interesting, though.

My conclusion is that most of these reports are already covered by the 
googlecode platform. I don't see much added value in generating and hosting a 
full new site based on this maven site... I prefer keeping consistency with 
what googlecode users expect from a googlecode hosted project.

Checkstyle and PMD could be used on the project to validate code quality, but I 
think this should be introduced in the build process and not the release 
process. I prefer having them integrated as Eclipse plugins, for example.

Thanks a lot for your work William, I'm sorry I will not use maven site 
features for the moment though. But you helped me a lot to learn quickly about 
maven features and this is priceless!

Kevin

Original comment by kevin.gaudin on 4 Apr 2011 at 11:06

[GoogleCodeExporter]

No problem Kevin.
Your decisions seem sane to me :-)

Original comment by william....@gmail.com on 4 Apr 2011 at 11:45

[GoogleCodeExporter]

Issue 32 has been merged into this issue.

Original comment by kevin.gaudin on 5 Apr 2011 at 1:49

[GoogleCodeExporter]

Original comment by kevin.gaudin on 22 Dec 2011 at 9:08

• Changed state: Verified