You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Hervé BOUTEMY <he...@free.fr> on 2008/04/15 22:48:50 UTC
POM Element for Source File Encoding
another try...
the proposal is here:
http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
I did the work on 2 plugins in a branch:
- jxr: http://svn.apache.org/viewvc?rev=645260&view=rev
- javadoc: http://svn.apache.org/viewvc?rev=645262&view=rev
As you can see, the change on plugins themselves is really tiny: it's much
about convention, little about code.
Sample use is in the branch too, to let Maven developers see the concrete
positive impact on users:
- actually every plugin has to be configured separately (pom is bigger), each
one having its own parameter name for encoding (confusion):
http://svn.apache.org/viewvc/maven/sandbox/branches/MNG-2216/before/pom.xml?view=markup
- after the plugin change, there is one property that every plugin uses as a
default value, hiding the fact that the parameter name is different for each
plugin:
http://svn.apache.org/viewvc/maven/sandbox/branches/MNG-2216/after/pom.xml?view=markup
There is still exactly the same work to be done on at least 7 other Apache
plugins and 4 Codehaus ones. The change on some plugins will represent more
code, since they don't even support an encoding parameter yet, but the
proposal on which we need to agree is about the convention to unify the
parameter's value. IMHO the actual work on 2 plugins shows everything.
I think it is sufficient to adopt, or reject, or transform, any aspect of the
proposal.
Any objection before I begin the changes on plugin trunks?
Hervé
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM Element for Source File Encoding
Posted by Hervé BOUTEMY <he...@free.fr>.
Thanks Milos for this review.
I'm starting to merge changes into plugins trunks.
Hervé
Le mercredi 16 avril 2008, Milos Kleint a écrit :
> +1 on integrating it.
> it's non intrusive and does what I would expect by default while
> allowing me to override the behaviour for some plugins.
> it makes my life easier as a maven user and also as a maven tools
> developer (the netbeans ide itegration)
>
> Milos
>
> On Tue, Apr 15, 2008 at 10:48 PM, Hervé BOUTEMY <he...@free.fr>
wrote:
> > another try...
> >
> > the proposal is here:
> >
> > http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+En
> >coding
> >
> > I did the work on 2 plugins in a branch:
> > - jxr: http://svn.apache.org/viewvc?rev=645260&view=rev
> > - javadoc: http://svn.apache.org/viewvc?rev=645262&view=rev
> > As you can see, the change on plugins themselves is really tiny: it's
> > much about convention, little about code.
> >
> > Sample use is in the branch too, to let Maven developers see the
> > concrete positive impact on users:
> >
> > - actually every plugin has to be configured separately (pom is bigger),
> > each one having its own parameter name for encoding (confusion):
> >
> > http://svn.apache.org/viewvc/maven/sandbox/branches/MNG-2216/before/pom.x
> >ml?view=markup
> >
> > - after the plugin change, there is one property that every plugin uses
> > as a default value, hiding the fact that the parameter name is different
> > for each plugin:
> >
> > http://svn.apache.org/viewvc/maven/sandbox/branches/MNG-2216/after/pom.xm
> >l?view=markup
> >
> > There is still exactly the same work to be done on at least 7 other
> > Apache plugins and 4 Codehaus ones. The change on some plugins will
> > represent more code, since they don't even support an encoding parameter
> > yet, but the proposal on which we need to agree is about the convention
> > to unify the parameter's value. IMHO the actual work on 2 plugins shows
> > everything.
> >
> > I think it is sufficient to adopt, or reject, or transform, any aspect
> > of the proposal.
> >
> > Any objection before I begin the changes on plugin trunks?
> >
> > Hervé
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM Element for Source File Encoding
Posted by Milos Kleint <mk...@gmail.com>.
+1 on integrating it.
it's non intrusive and does what I would expect by default while
allowing me to override the behaviour for some plugins.
it makes my life easier as a maven user and also as a maven tools
developer (the netbeans ide itegration)
Milos
On Tue, Apr 15, 2008 at 10:48 PM, Hervé BOUTEMY <he...@free.fr> wrote:
> another try...
>
> the proposal is here:
> http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
>
> I did the work on 2 plugins in a branch:
> - jxr: http://svn.apache.org/viewvc?rev=645260&view=rev
> - javadoc: http://svn.apache.org/viewvc?rev=645262&view=rev
> As you can see, the change on plugins themselves is really tiny: it's much
> about convention, little about code.
>
> Sample use is in the branch too, to let Maven developers see the concrete
> positive impact on users:
>
> - actually every plugin has to be configured separately (pom is bigger), each
> one having its own parameter name for encoding (confusion):
> http://svn.apache.org/viewvc/maven/sandbox/branches/MNG-2216/before/pom.xml?view=markup
>
> - after the plugin change, there is one property that every plugin uses as a
> default value, hiding the fact that the parameter name is different for each
> plugin:
> http://svn.apache.org/viewvc/maven/sandbox/branches/MNG-2216/after/pom.xml?view=markup
>
> There is still exactly the same work to be done on at least 7 other Apache
> plugins and 4 Codehaus ones. The change on some plugins will represent more
> code, since they don't even support an encoding parameter yet, but the
> proposal on which we need to agree is about the convention to unify the
> parameter's value. IMHO the actual work on 2 plugins shows everything.
>
> I think it is sufficient to adopt, or reject, or transform, any aspect of the
> proposal.
>
> Any objection before I begin the changes on plugin trunks?
>
> Hervé
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: POM Element for Source File Encoding
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
I'm fine with the warning, you convinced me.
-----Original Message-----
From: Wayne Fay [mailto:waynefay@gmail.com]
Sent: Wednesday, April 30, 2008 2:22 PM
To: Maven Developers List
Subject: Re: POM Element for Source File Encoding
> I agree and we can do this for 2.1. We can't break the existing
contract
> which can potentially screw a lot of people.
No one is proposing changing things for 2.0. If no encoding is
declared, it will use the system default, as it has always done.
We're just talking about INFO vs WARNING for informing users that they
have not declared the file encoding as we would (strongly) prefer. A
pretty small point in the grand scheme of things.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM Element for Source File Encoding
Posted by Wayne Fay <wa...@gmail.com>.
> I agree and we can do this for 2.1. We can't break the existing contract
> which can potentially screw a lot of people.
No one is proposing changing things for 2.0. If no encoding is
declared, it will use the system default, as it has always done.
We're just talking about INFO vs WARNING for informing users that they
have not declared the file encoding as we would (strongly) prefer. A
pretty small point in the grand scheme of things.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM Element for Source File Encoding
Posted by Jason van Zyl <ja...@maven.org>.
On 1-May-08, at 2:13 AM, Benjamin Bentmann wrote:
> Jason van Zyl wrote:
>
>> > and as such warning is most appropriate
>> > rather than simply info. I could be talked into accepting an info
>> that
>> > has "build not fully reproducible etc" text in it, but this is
>> > splitting hairs.
>> >
>>
>> It can in no way effect what currently happens even if it's not
>> 100% opinionated :-)
>
> I'm not entirely sure my English translator got your message. Was
> that to say you don't want the warning message? If so, I would
> appreciate at least one further PMC voice to break the draw.
>
I meant the behavior of the core and the plugins operating with it.
I'm fine with a warning.
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
A man enjoys his work when he understands the whole and when he
is responsible for the quality of the whole
-- Christopher Alexander, A Pattern Language
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM Element for Source File Encoding
Posted by Benjamin Bentmann <be...@udo.edu>.
Jason van Zyl wrote:
> > and as such warning is most appropriate
> > rather than simply info. I could be talked into accepting an info that
> > has "build not fully reproducible etc" text in it, but this is
> > splitting hairs.
> >
>
> It can in no way effect what currently happens even if it's not 100%
> opinionated :-)
I'm not entirely sure my English translator got your message. Was that to
say you don't want the warning message? If so, I would appreciate at least
one further PMC voice to break the draw.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM Element for Source File Encoding
Posted by Jason van Zyl <ja...@maven.org>.
On 30-Apr-08, at 11:02 AM, Wayne Fay wrote:
>> This idea with the warning was also proposed by two or three users
>> on the
>> list, especially Hervé put it nicely [0]. I took this happily up
>> because I
>> (still) believe that having builds out there which implicitly rely
>> on the
>> platform encoding and as such just break with the ideals of
>> platform-independence and build reproducibility is nothing that
>> should be
>> promoted, not in general and in particular not by Maven. And I
>> consider
>> silent acceptance as a mild form of promotion.
>
> Maven is an opinionated piece of software. Let the PMC decide what
> their opinion is on this matter and then let it be implemented. My
> personal opinion is that file encoding should be consciously
> considered and declared,
I agree and we can do this for 2.1. We can't break the existing
contract which can potentially screw a lot of people.
> and as such warning is most appropriate
> rather than simply info. I could be talked into accepting an info that
> has "build not fully reproducible etc" text in it, but this is
> splitting hairs.
>
It can in no way effect what currently happens even if it's not 100%
opinionated :-)
> Wayne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.
-- Eric Hoffer, Reflections on the Human Condition
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM Element for Source File Encoding
Posted by Wayne Fay <wa...@gmail.com>.
> This idea with the warning was also proposed by two or three users on the
> list, especially Hervé put it nicely [0]. I took this happily up because I
> (still) believe that having builds out there which implicitly rely on the
> platform encoding and as such just break with the ideals of
> platform-independence and build reproducibility is nothing that should be
> promoted, not in general and in particular not by Maven. And I consider
> silent acceptance as a mild form of promotion.
Maven is an opinionated piece of software. Let the PMC decide what
their opinion is on this matter and then let it be implemented. My
personal opinion is that file encoding should be consciously
considered and declared, and as such warning is most appropriate
rather than simply info. I could be talked into accepting an info that
has "build not fully reproducible etc" text in it, but this is
splitting hairs.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM Element for Source File Encoding
Posted by Benjamin Bentmann <be...@udo.edu>.
Dennis Lundberg wrote:
> As long as there is an easy way for users to get rid of the warning, which
> seems to be the case here.
Yes, simply setting the POM property ${project.build.sourceEncoding} to some
value, either XYZ or if users really want ${file.encoding}, will disable the
warning.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM Element for Source File Encoding
Posted by Dennis Lundberg <de...@apache.org>.
Benjamin Bentmann wrote:
> Brian E. Fox wrote:
>
>> Is a warning really needed? Perhaps just an INFO that says "using
>> platform
>> default encoding: [value]". Again going under the theory that someone
>> that
>> needs to worry about the encoding will be looking for it, shoving a
>> warning in everyone's face that doesn't care isn't a great choice.
>
> OK, if we wanted, we could just start another poll for this, seems to have
> enough controversial spirit ;-)
>
> This idea with the warning was also proposed by two or three users on the
> list, especially Hervé put it nicely [0]. I took this happily up because I
> (still) believe that having builds out there which implicitly rely on the
> platform encoding and as such just break with the ideals of
> platform-independence and build reproducibility is nothing that should be
> promoted, not in general and in particular not by Maven. And I consider
> silent acceptance as a mild form of promotion.
>
> I mean the important difference between a warning and an info is that
> you at
> least express that something is not quite right, it may work but should be
> reviewed. Compare the following
>
> [INFO] Compling 42 source files
> [INFO] Using platform default encoding UTF-8
>
> with
>
> [INFO] Compling 42 source files
> [WARNING] Using platform default encoding UTF-8, build is not fully
> reproducible, please verify its output, yadayada
>
> Somebody who is not aware of the encoding issue will be absolutely happy
> with the first output whereas a reader of the later output will start to
> wonder "What is this damn warning all about?". Answering his question will
> hopefully lead him to the insight that he wants to specify an encoding, to
> follow best practices.
+1 to having a warning for this, instead of just an info. As long as
there is an easy way for users to get rid of the warning, which seems to
be the case here.
>
> Last but not least, having this warning everywhere will bring me into a
> good
> position when re-asking what the agreed encoding for the Maven sources
> themselves is ;-)
>
> I promise, this will be my last passionate mail about encoding. Just have
> the PMC say one word and it's going to become true.
>
>
> Benjamin
>
>
> [0]
> http://www.nabble.com/Re%3A--POLL--Default-Value-for-File-Encoding-p16968718.html
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM Element for Source File Encoding
Posted by Benjamin Bentmann <be...@udo.edu>.
Brian E. Fox wrote:
> Is a warning really needed? Perhaps just an INFO that says "using platform
> default encoding: [value]". Again going under the theory that someone that
> needs to worry about the encoding will be looking for it, shoving a
> warning in everyone's face that doesn't care isn't a great choice.
OK, if we wanted, we could just start another poll for this, seems to have
enough controversial spirit ;-)
This idea with the warning was also proposed by two or three users on the
list, especially Hervé put it nicely [0]. I took this happily up because I
(still) believe that having builds out there which implicitly rely on the
platform encoding and as such just break with the ideals of
platform-independence and build reproducibility is nothing that should be
promoted, not in general and in particular not by Maven. And I consider
silent acceptance as a mild form of promotion.
I mean the important difference between a warning and an info is that you at
least express that something is not quite right, it may work but should be
reviewed. Compare the following
[INFO] Compling 42 source files
[INFO] Using platform default encoding UTF-8
with
[INFO] Compling 42 source files
[WARNING] Using platform default encoding UTF-8, build is not fully
reproducible, please verify its output, yadayada
Somebody who is not aware of the encoding issue will be absolutely happy
with the first output whereas a reader of the later output will start to
wonder "What is this damn warning all about?". Answering his question will
hopefully lead him to the insight that he wants to specify an encoding, to
follow best practices.
Last but not least, having this warning everywhere will bring me into a good
position when re-asking what the agreed encoding for the Maven sources
themselves is ;-)
I promise, this will be my last passionate mail about encoding. Just have
the PMC say one word and it's going to become true.
Benjamin
[0]
http://www.nabble.com/Re%3A--POLL--Default-Value-for-File-Encoding-p16968718.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: POM Element for Source File Encoding
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>I would like to start adopting the plugin sources to
>- have their encoding parameter default to null, meaning platform encoding
> as before
Yep.
>- output a warning message if the encoding is unspecified
Is a warning really needed? Perhaps just an INFO that says "using platform default encoding: [value]". Again going under the theory that someone that needs to worry about the encoding will be looking for it, shoving a warning in everyone's face that doesn't care isn't a great choice.
Re: POM Element for Source File Encoding
Posted by Benjamin Bentmann <be...@udo.edu>.
Brian E. Fox wrote:
> I'd say based on the various points brought up by the users that platform
> encoding as the default makes the most sense.
Yes, that's the majority's sense. I counted roughly but so far the ratio of
votes is about 3:1 for keeping platform encoding as default vs. Latin-1,
taking together the votes on the user list and over on the wiki.
Given that the thread on the user list is already quite idle, I believe
their is no need in waiting much longer for further votes, in particular I
don't expect a complete turnaround of the already clear direction. So
tomorrow (or the day after, depending whether SVN will be alive), I would
like to start adopting the plugin sources to
- have their encoding parameter default to null, meaning platform encoding
as before
- output a warning message if the encoding is unspecified
This warning would simply check whether the encoding parameter is null. As a
side-effect, people that absolutely don't care about encoding and don't want
Maven to output a warning can simply set the parameter to ${file.encoding}
which is non-null but still has the same effect of using the platform
encoding.
Agreed?
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: POM Element for Source File Encoding
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
I've been following the responses on the user list. I'd say based on the various points brought up by the users that platform encoding as the default makes the most sense. Most people aren't having issues with this currently and teams that are dealing with encoding issues across their developers will have to deal with it anyway (outside of Maven) and setting an encoding value in the pom won't be a big deal. Once the plugins pay attention to this new encoding value, it should work for everyone.
-----Original Message-----
From: Brian E. Fox [mailto:brianf@reply.infinity.nu]
Sent: Tuesday, April 29, 2008 9:08 AM
To: Maven Developers List
Subject: RE: POM Element for Source File Encoding
>> Is there an issue with a huge number of votes attached to it?
>To my knowledge, no. We have MNG-2216 that is quite similar to our proposal
>but has (excluding myself) only three other votes which is not that much.
>Let my point out that the encoding issue is subtle and I expect a fair
>amount of people that are simply not aware of it, i.e. their builds work
>just by coincidence.
This is fine, but if we make a change that suddenly breaks everyone's builds, then they will be out screaming.
>> This is certainly relevant when asking for a change as fundamental as
>> this. If a handful of people have issues with this, but everyone else is
>> ok with platform default, then this is an important deciding factor.
>Of course user's sense is important but there is also the question where the
>PMC would like its baby to go. For example, I see parallels to the question
>whether the Maven 2.1 POM should require explicit versions for plugins. It
>would guarantee stable builds but no doubt there will be users complaining
>about the need to touch their POMs.
There's a huge difference between this and the plugin versions....specifically the groundswell of user feedback asking for a solution to plugins changing at random times.
> Anything we do that causes behavior changes will have to wait until 2.1,
> we simply cannot allow this kind of change in 2.0.x.
<snip>
>So it's not about switching from Maven 2.0.x to
>Maven 2.1 but from Plugin x.y to x.y+1 which I feel is the same step.
This makes me even more concerned. Given the chance to do it right and make things stable, I'll pick that choice every time, but if it's going to break lots of people's builds and no one is really asking for it, then that's a big risk without much reward.
RE: POM Element for Source File Encoding
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>> Is there an issue with a huge number of votes attached to it?
>To my knowledge, no. We have MNG-2216 that is quite similar to our proposal
>but has (excluding myself) only three other votes which is not that much.
>Let my point out that the encoding issue is subtle and I expect a fair
>amount of people that are simply not aware of it, i.e. their builds work
>just by coincidence.
This is fine, but if we make a change that suddenly breaks everyone's builds, then they will be out screaming.
>> This is certainly relevant when asking for a change as fundamental as
>> this. If a handful of people have issues with this, but everyone else is
>> ok with platform default, then this is an important deciding factor.
>Of course user's sense is important but there is also the question where the
>PMC would like its baby to go. For example, I see parallels to the question
>whether the Maven 2.1 POM should require explicit versions for plugins. It
>would guarantee stable builds but no doubt there will be users complaining
>about the need to touch their POMs.
There's a huge difference between this and the plugin versions....specifically the groundswell of user feedback asking for a solution to plugins changing at random times.
> Anything we do that causes behavior changes will have to wait until 2.1,
> we simply cannot allow this kind of change in 2.0.x.
<snip>
>So it's not about switching from Maven 2.0.x to
>Maven 2.1 but from Plugin x.y to x.y+1 which I feel is the same step.
This makes me even more concerned. Given the chance to do it right and make things stable, I'll pick that choice every time, but if it's going to break lots of people's builds and no one is really asking for it, then that's a big risk without much reward.
Re: POM Element for Source File Encoding
Posted by Benjamin Bentmann <be...@udo.edu>.
Brian E. Fox wrote:
> Who exactly is asking for this change?
Basically only me, in an attempt to guarantee reproducible builds by
eliminating a dependency on an environmental property.
> Is there an issue with a huge number of votes attached to it?
To my knowledge, no. We have MNG-2216 that is quite similar to our proposal
but has (excluding myself) only three other votes which is not that much.
Let my point out that the encoding issue is subtle and I expect a fair
amount of people that are simply not aware of it, i.e. their builds work
just by coincidence.
> This is certainly relevant when asking for a change as fundamental as
> this. If a handful of people have issues with this, but everyone else is
> ok with platform default, then this is an important deciding factor.
Of course user's sense is important but there is also the question where the
PMC would like its baby to go. For example, I see parallels to the question
whether the Maven 2.1 POM should require explicit versions for plugins. It
would guarantee stable builds but no doubt there will be users complaining
about the need to touch their POMs.
> Anything we do that causes behavior changes will have to wait until 2.1,
> we simply cannot allow this kind of change in 2.0.x.
Please keep in mind that the default value for the file encoding is not only
targetted at the Maven core. First of all, the change in behavior occurs on
per-plugin basis, based on the version selected by the user. For example,
the release 2.4 of the Javadoc Plugin already included MJAVADOC-165,
breaking with its previous release 2.3 (btw, are there objections from users
regarding this change?). So it's not about switching from Maven 2.0.x to
Maven 2.1 but from Plugin x.y to x.y+1 which I feel is the same step.
> I would like to see the results of a user list poll before we go much
> futher.
Alright, thanks for confirmation, I will then send a vote to users@maven to
get us a more founded impression of community desire.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: POM Element for Source File Encoding
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Lets step back for a bit. Who exactly is asking for this change? Is there an issue with a huge number of votes attached to it? This is certainly relevant when asking for a change as fundamental as this. If a handful of people have issues with this, but everyone else is ok with platform default, then this is an important deciding factor.
Anything we do that causes behavior changes will have to wait until 2.1, we simply cannot allow this kind of change in 2.0.x.
I would like to see the results of a user list poll before we go much futher.
-----Original Message-----
From: Benjamin Bentmann [mailto:benjamin.bentmann@udo.edu]
Sent: Monday, April 28, 2008 4:51 PM
To: Maven Developers List
Subject: Re: POM Element for Source File Encoding
Hervé Boutemy wrote.
> the proposal is here:
> http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
Recently, we have received two comments from users on the wiki that are
against the proposed default encoding of Latin-1 but would rather like it to
stay as is, i.e. platform default encoding.
I am aware that this a controversial issue, backward-compat on the hand,
out-of-the-box build reproducibility on the other. Personally, I still
believe that some progressions need to break with historical flaws but I
also don't want to silently ignore the reported objections. In the end it
might boil down to the democratic question what is the opinion of the
majority. Therefore, I think it might be a good idea to simply run a vote
for this on the user list, too. Would that be reasonable, other ideas?
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM Element for Source File Encoding
Posted by Benjamin Bentmann <be...@udo.edu>.
Hervé Boutemy wrote.
> the proposal is here:
> http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
Recently, we have received two comments from users on the wiki that are
against the proposed default encoding of Latin-1 but would rather like it to
stay as is, i.e. platform default encoding.
I am aware that this a controversial issue, backward-compat on the hand,
out-of-the-box build reproducibility on the other. Personally, I still
believe that some progressions need to break with historical flaws but I
also don't want to silently ignore the reported objections. In the end it
might boil down to the democratic question what is the opinion of the
majority. Therefore, I think it might be a good idea to simply run a vote
for this on the user list, too. Would that be reasonable, other ideas?
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org