Hey,
On Mon, May 28, 2012 at 6:53 PM, Harald Wellmann
<hwellmann...@googlemail.com> wrote:
some remarks and questions:
- Deleting plugins.javadoc.version leaves a dangling reference in the
reporting section.
This shouldn't happen since the version is from the sonatype parent
(but I'll check).
- Deleting the javadoc plugin from the POM effectively downgrades
the plugin from 2.8 to 2.7 used in the OSS parent POM. Don't think we want
to go back, do we? The latest version listed in [1] is 2.8.1
not sure if this really hurts; that way we at least don't have to care about it.
- Why pushChanges = false for maven-release-plugin? I'd say we do
want to push the changes.
Well, basically it's best practice to do directly releases. That way
you can check the release first before doing the release;
nevertheless, I can remove it.
- I'm not so sure about skipping tests in the release build. Does that only
affect release:prepare or also release:perform?
You're right; release prepare should use tests, running them again for
perform sounds a little bit useless to me (I'll adapt this).
- What's the effect of<tagNameFormat>v@{project.version}</tagNameFormat>?
Does that suppress the prompt for a tag name when running a release or only
change the default suggested by the prompt?
Only changes the default suggestion
I think @{artifactId}-@{project.version} is a more reasonable default, but
I'm not sure if this matches current usage in _all_ OPS4J projects.
Every project is different; artifact-version is fine for me too; tbh
no preferences; just a good default value since releases only happen
per git repo anyhow making the tags shorter...
So if this setting disables the prompt and might break existing naming
conventions in individual projects without people noticing, then I'd prefer
_not_ to have a default in the parent POM.
Nothing is overwritten; only defaults are suggested
- maven-surefire-plugin is at 2.12, maven-clean-plugin and
maven-compiler-plugin are at 2.5 in [1]. I haven't tested these yet...
same argument as above: one thing less we've to care about;
nevertheless, if there are any specific reasons why we absolutely need
those higher versions we can also overwrite them explicitely.
Kind regards,
Andreas
[1] http://maven.apache.org/plugins/index.html
Regards,
Harald
Am 28.05.2012 15:19, schrieb Andreas Pieber:
If there are no further comments on my changes I'll merge them by
tomorrow midday into the master and cut a 3.0.0 release of the ops4j
master.
Kind regards,
Andreas
_______________________________________________
general mailing list
general@lists.ops4j.org
http://lists.ops4j.org/mailman/listinfo/general
