core plugins to be modified:
I moved this list over to the wiki article [0] in Confluence, think it's
easier to maintain there instead of being splattered through this mailing
thread.
> This in place, plugin parameters could be written like
>
> /**
> * @parameter expression="${encoding}"
> * default-value="${project.build.sourceEncoding}"
> */
> private String encoding;
>
> i.e. still provide some short expression name for overrides from the
> cli.
should we provide ${encoding} or ${sourceEncoding}?
Don't know, it's the question of ease of typing vs. expressiveness. The
tools javac and javadoc have their corresponding cli parameters named
"encoding", too. On the other hand, how often do we expect users to really
specify this parameter via the cli instead of permanently configuring the
POM?
> Of course, this would require the plugin to add a manual check whether
> the
> default-value expression actually was existent or whether an older Maven
> version is running.
I'm not convinced here: just let null=platform encoding, as it has been
the case previously
If I understand you correctly, this would make the encoding behavior
dependent on the currently used Maven version, wouldn't it? Let's assume
Maven 2.0.10+ defines the propery ${project.build.sourceEncoding} in the
super POM to a specific value like Latin-1 as agreed so far. Then, any
plugin that populates its encoding parameter via this property by means of
the default-value annotation will use that specific encoding. However, if
the same plugin version is run by Maven 2.0.9-, it will receive null for the
encoding property and as you suggested falls back to a platform-dependent
encoding. I would rather prefer that the behavior of a plugin depends only
on its own version and not also on the executing Maven version to ease
reproducibility.
So I believe there are two choices:
If your initial concerns about backwards compatibility meet general
consensus, the super POM should simply not define a specific property for
${project.build.sourceEncoding} such that users get platform-dependent
behavior as now by default (not my favorite).
Otherwise, plugins should by convention agree to handle a null value for the
encoding parameter to denote some fixed encoding. This way, upgrading Maven
will not affect the default encoding behavior.
Benjamin
[0]
http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
