maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hervé BOUTEMY <herve.bout...@free.fr>
Subject Re: [VOTE] Release Maven Javadoc Plugin version 2.5
Date Sat, 02 Aug 2008 14:10:49 GMT
Le samedi 02 août 2008, Benjamin Bentmann a écrit :
> The Javadoc plugin is currently breaking with the proposal. As a matter
> of consistency, we might need to adjust the proposal if the community
> doesn't accept it's current form. But I wonder how the alternative would
> look like? Have all report plugins mimic the Javadoc plugin?
from a user point of view, why not: it will require more code from us to mimic 
this, but the logic seems ok for me

> What do 
> those plugins that require no "encoding" parameter but only have a
> "docencodign" thingy? What would be their default output encoding,
> platform encoding while the Javadoc plugin defaults to the
> user-specified source encoding?
>
> Again, I feel consistency among our plugins is more important than
> mimicing the underlying tool since I believe this has impact on the way
> users perceive Maven: Is it a dumb wrapper over external tools with some
> glue in between or a build system on its own where all parts fit nicely
> together without first going through clutterly configurations?
clearly, this would be our job to code what is necesssary to have a consistent 
behaviour among every plugin. The idea is not to retain underlying tools' 
native logic in every plugin, but to consolidate on one unique behaviour. The 
fact is that javadoc's one is interesting from a user perspective.
But:
1. more complex =  more code to maintain
2. not natively reproducible = this can lead to platform encoding use if 
source encoding has not been set

but I suppose that the warning when source encoding has not been set will help 
people to rapidly define their source encoding.
Then both choices for default output encoding will be equivalent on 
this "build reproducibility" side.
The remaining difference is code complexity: fixed UTF-8 is simpler to code 
than calculated source encoding.

I'll call a new vote on dev list (sorry Vincent for the delay with javadoc 
plugin)

> Disclaimer: I don't want to upset anybody. There are just some ideas
> that I read somewhere on the Maven site that really caught me. Whereever
> I feel these ideals are violated, I try to get prevent that, maybe
> sometimes to passionately.
didn't know a topic like encoding could lead to such passionate debates :)

the actual discussion is perfectly positive: thre pros and cons are now IMHO 
really known. The result of the vote will have more value than previous one.

regards,

Hervé

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message