search

githubgit / urlrewritefilter

Automatically exported from code.google.com/p/urlrewritefilter
Other
0 stars 0 forks source link

Improve Maven build experience #110

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Here are some points which can improve the overall Maven build experience based 
on the current trunk.

1. Move (test) resources to the designated directories /src/main/resources and 
/src/test/resources
2. Provide a defined output encoding with UTF-8. (Input encoding already 
defined in oss-parent)
3. Make JavaDoc plugin silent with <quiet>true</true>. Only errors are of 
interest and not any single file generation.
4. Remove GPG singing, source jar and javadocs jar generation use the single 
release profile which the oss-parent already provides. This is the best way to 
do it automatically with a release/deployment. A constant generation is not 
necessary during the development phase.

Reference/support for 2,3 and 4 can be provided.

Again, thanks for this great piece of software Paul. Serves me very well for 
the last couple of years.

Original issue reported on code.google.com by 1983-01...@gmx.net on 5 Jul 2012 at 7:38

GoogleCodeExporter commented 9 years ago 
Trunk updated with these improvements.

Original comment by p...@tuckey.org on 5 Jul 2012 at 10:21

GoogleCodeExporter commented 9 years ago 
Point 3 and 4 are not complete in trunk.

Original comment by 1983-01...@gmx.net on 5 Jul 2012 at 11:34

GoogleCodeExporter commented 9 years ago 

3 - Is this not right?
    http://code.google.com/p/urlrewritefilter/source/browse/trunk/pom.xml#143

4 - I removed the reverence to maven-gpg-plugin.  Is that right?

Original comment by p...@tuckey.org on 12 Jul 2012 at 8:56

GoogleCodeExporter commented 9 years ago 
3: This correct but incomplete, project report plugins do not inherit from the 
plugin section you have to duplicate the quiet flag.
4: That is correct but you did not remove the generation of the Javadocs and 
source jar (executions). As you can see in the OSS parent pom, the release 
profile does already generate the jars for you. No need to duplicate that.

More points:

5. The trunk contains always a SNAPSHOT of your software not a release version. 
You should seriously use the release plugin to help you manage that. It will 
tag the project, generate binary, javadoc and source jar, sign them and then 
push them to Sonatype RSO. So the version right now should be 4.0.4-SNAPSHOT.

6. Redirect the test ouput to a file [1] to make the build process output more 
readable.

7. buildnumber plugin: Why are you abusing the timestamp as a build number? You 
can follow the convention rule layed out by this [2]

a simple build.properties in src/main/resources with:
version=${project.version}
buildNumber=${buildNumber}
timestamp=${timestamp}

will inject you the correct version and the SCM revision, in this case the SVN 
rev. 
This is exactly done by the Maven folks if you type mvn --version.
So the output would/should/could be: <version> (r<buildNumber>; <ISO timestamp>)
As you do in UrlRewriteFilter#getFullVersionString
Java code is available for that which covers all cases. testVersion() has to be 
adapted of course.

[1] 
http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#redirectTes
tOutputToFile
[2] http://mojo.codehaus.org/buildnumber-maven-plugin/usage.html

Original comment by 1983-01...@gmx.net on 21 Jul 2012 at 5:45

GoogleCodeExporter commented 9 years ago 
3: done
4: done
5: done
6: done
7: done

All in trunk, will deploy release to sonatype as time allows.

Original comment by p...@tuckey.org on 24 Jul 2012 at 10:44

GoogleCodeExporter commented 9 years ago 
Looks very good now. You make point 5 even skimmer:

Since you are using a default SVN repo layout, you can leave out the tagBase 
element. The release plugin will figure it out for you. What you can add is 
<tagNameFormat>@{project.version}</tagNameFormat>. This will label the tag as 
the version only. The default case is not suited for your basic case.

Looking forward to 4.0.4, still stuck on 3.2.

Original comment by 1983-01...@gmx.net on 24 Jul 2012 at 11:07

GoogleCodeExporter commented 9 years ago 
Please update the release plugin as well. Some stuff is not available in 2.1 
but in 2.3.2.

Original comment by 1983-01...@gmx.net on 24 Jul 2012 at 11:11

GoogleCodeExporter commented 9 years ago 
You can again skim your command like to this:

----- tag

mvn release:prepare release:perform -Dgpg.passphrase=XXXXX

Everything else works automagically: The release profile, install, deployment, 
signing, etc.

Original comment by 1983-01...@gmx.net on 24 Jul 2012 at 11:48