Results:
Binding +11: Brian, Wendy, Arnaud, Brett, Vincent, Lukas, Stepane,
Jason, Jesse, John, Olivier
-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED]
Sent: Monday, April 07, 2008 12:42 PM
To: Maven Developers List
Subject: [VOTE] Maven 2.0.9
Time to vote on the final Ma
On 09/04/2008, Mark Hobson <[EMAIL PROTECTED]> wrote:
> I had this when I attempted to use the enforcer plugin, I assumed it
> was http://jira.codehaus.org/browse/MENFORCER-25. It works okay with
> the trunk, but that's no good if your project can't rely on snapshots.
P.S. That was with 2.0.8,
I had this when I attempted to use the enforcer plugin, I assumed it
was http://jira.codehaus.org/browse/MENFORCER-25. It works okay with
the trunk, but that's no good if your project can't rely on snapshots.
Mark
On 09/04/2008, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> Can you show the debug ou
I'm also interested if we can try to fix this one :
http://jira.codehaus.org/browse/MECLIPSE-394
If we can validate it by reproducing it with another plugin we can
suppose that it i related to the core (I don't see how i can be a bug
in the plugin).
(I already had this bug but I didn't yet take the
Le mercredi 09 avril 2008, Jason van Zyl a écrit :
> All sounds fine. Just wanted you to think about the bigger picture in
> mind.
>
> Please do the work on a branch and go through the rigor of Brian's
> example and make sure it works before you merge it into something we
> would release to users.
Le mercredi 09 avril 2008, Benjamin Bentmann a écrit :
> > I see your point. Worth another vote? Or should this switch be postponed
> > to 2.1, trading consistency in minor version upgrades for a longer time
> > for these Latin1 defaults to be established?
> > [...]
> > So while I agree that a chan
>It essentially renders maven useless behind a corporate firewall
because
>proxying is applied globally in maven - and nonProxyHosts are not taken
>into account.
Someplace with a corporate firewall most likely needs a repo manager
anyway, which should handle this without blinking.
>Even by usin
Brian E. Fox skrev:
Now that 2.0.9 is essentially behind us, I think the focus for the next
release needs to continue on preventing new regressions and stomping out
the old ones. This should take precedence over new features and other
"nice to haves" as we still have a significant user base stuck
On Wed, Apr 9, 2008 at 7:36 PM, Benjamin Bentmann
<[EMAIL PROTECTED]> wrote:
>
> > Make sure you consider the case where you have people developing the same
> code base all over the world, and the possible reasoning of falling back to
> platform default encoding. Consider the team spread across
I see your point. Worth another vote? Or should this switch be postponed
to 2.1, trading consistency in minor version upgrades for a longer time
for these Latin1 defaults to be established?
[...]
So while I agree that a change in default either now or in the future is
ugly, it is not taboo, and I
All sounds fine. Just wanted you to think about the bigger picture in
mind.
Please do the work on a branch and go through the rigor of Brian's
example and make sure it works before you merge it into something we
would release to users. This is not an insignificant change.
On 9-Apr-08, at
Make sure you consider the case where you have people developing the same
code base all over the world, and the possible reasoning of falling back
to platform default encoding. Consider the team spread across the US,
Russia, and China and what do they do normally?
This international spread
Benjamin Bentmann wrote:
In general, I completely agree with your preference to Unicode and
fail-fast
behavior. If I had been involved when the Maven story started, I would have
proposed UTF-8 as the default value, no doubt.
As for today, I tried to consider consistency with existing behavior.
That could be a potentially massive undertaking but I agree it's worth
pursuing. The existing Its and infrastructure seems to be pretty stable
now so it's at least manageable.
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 09, 2008 1:13 PM
To: Maven
Sounds good.
I think we should consider MNG-3160 - to get all the integration tests
that have been disabled for one reason or another working again.
- Brett
On 10/04/2008, at 2:51 AM, Brian E. Fox wrote:
Now that 2.0.9 is essentially behind us, I think the focus for the
next
release need
Can you show the debug output to see the real stack trace? We've run
through several tests with people using the enforcer so this is
interesting.
-Original Message-
From: Arnaud HERITIER [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 09, 2008 12:41 PM
To: Maven Developers List
Subject:
>As for today, I tried to consider consistency with existing behavior.
The
>Maven Site Plugin was already using Latin-1 as the default value for
>inputEncoding and outputEncoding and so I proposed this for other
plugins,
>too. Indeed, one of the patches (MJAVADOC-165) was just released such
that
>
Now that 2.0.9 is essentially behind us, I think the focus for the next
release needs to continue on preventing new regressions and stomping out
the old ones. This should take precedence over new features and other
"nice to haves" as we still have a significant user base stuck on
various releases d
Using maven 2.0.9 and the enforcer plugin I receive this error :
mvn install
[INFO] Scanning for projects...
WAGON_VERSION: 1.0-beta-2
[INFO]
[INFO] Building POM Parent Generali
[INFO]task-segment: [install]
[INFO] --
Taking this together, one might argue to have UTF-8 the default, not
ISO-8859-1.
In general, I completely agree with your preference to Unicode and fail-fast
behavior. If I had been involved when the Maven story started, I would have
proposed UTF-8 as the default value, no doubt.
As for today,
On 10/04/2008, at 2:11 AM, John Casey wrote:
We cannot change the modelVersion without a fairly major refactor of
one of the most complex classes in Maven - DefaultMavenProjectBuilder.
http://svn.apache.org/viewvc/maven/components/branches/maven-2.0.x-terse/maven-project/src/main/java/org/ap
-1
We cannot change the modelVersion without a fairly major refactor of
one of the most complex classes in Maven -
DefaultMavenProjectBuilder. So to make this declaration, we're
basically pinning users to these plugin versions until sometime after
2.1 most likely (I haven't even started o
Benjamin Bentmann wrote:
With regard to user errors, my general
suggestion is to fail the build. This unforgiving attitude should not be
that unfamilar to users: It has been chosen for a popular format like
XML which is also employed by Maven for a few files.
The problems depend on the encodi
Paul Benedict wrote:
Just a proposal: Maven could loosen its parsing rules when it detects
versions greater than it is configured to accept.
Forward compatibility would be nice.
For anyone seriously interested in interoperability , I suggest a look
at http://www.w3.org/2005/05/xsd-versioning-
Start by explaining the problem and the expected / actual result on the user
list. If it really is a bug, a lot of dev'ers are also reading there and will
redirect you to the jira system[1] and tell you which component it affects. The
dev list is more for the developers to communicate.
Hth,
Ni
There is a context value called "SystemProperties" that the
DefaultProfileManager is maintaining. That's how the system-property
profile activator is working. Just make the activator
Contextualizable, and you can pull that properties instance for use
in place of System.getProperties().
-j
Yes. The intent was never to lock everyone in place indefinitely.
Although I like the appeal of forcing people to choose to upgrade the
plugin versions and start managing them, this isn't what the users have
asked for nor expect.
-Original Message-
From: Christian Edward Gruber [mailto:
Benjamin Bentmann wrote:
You could of course write an encoding detection plugin which could
examine the code and set the required property accordingly.
Personally, I don't see the use case for that. If there are really users
out there that don't know what file encoding they are using when writ
for the bug on javadoc, those projects are using 2.3.
I couldn't test 2.4 on them.
I have some projects on 2.4 but they have many less code.
Arnaud
On Wed, Apr 9, 2008 at 2:32 PM, Brett Porter <[EMAIL PROTECTED]> wrote:
> What version of the javadoc plugin? The only thing I can think it'd be
> r
Yes, I tried several weeks ago and I didn't have them.
Arnaud
On Wed, Apr 9, 2008 at 2:56 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> Did you check if these occur in 2.0.8?
>
>
> -Original Message-
> From: Arnaud HERITIER [mailto:[EMAIL PROTECTED]
>
> Sent: Wednesday, April 09, 2008 8
So just to clarify (with pretend numbers), would this sort of scenario
be fair:
maven-2.0.9 includes:
maven-install-plugin-1.9,
maven-test-plugin-2.2
maven-compile-plugin-2.7
but
maven-2.0.10 includes:
maven-install-plugin-1.9,
maven-test-plugin-2.3
m
Did you check if these occur in 2.0.8?
-Original Message-
From: Arnaud HERITIER [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 09, 2008 8:09 AM
To: Maven Developers List
Cc: [EMAIL PROTECTED]
Subject: Re: [VOTE] Maven 2.0.9
Just to let you know, I made more tests I noticed two problems
I previously put forth a set of guidelines when we voted on doing this
initially. Essentially we would update the plugins only to non alpha or
beta versions and versions of plugins that had been released longer than
a month unless there was a good reason to do otherwise. I don't see any
benefit in
On 09/04/2008, at 9:49 PM, Vincent Siveton wrote:
Hi Brett,
2008/4/8, Brett Porter <[EMAIL PROTECTED]>:
Hi Vincent,
I was reviewing the commits for 2.0.9 and saw this one:
http://svn.apache.org/viewvc/maven/components/branches/maven-2.0.x/maven-project/src/main/java/org/apache/maven/profiles
What version of the javadoc plugin? The only thing I can think it'd be
related to is the change to the lifecycle forking.
- Brett
On 09/04/2008, at 10:09 PM, Arnaud HERITIER wrote:
Just to let you know, I made more tests I noticed two problems :
- I have several javadocs errors I hadn't befo
As far as I know, the recommended method is not to rsync, as you don't need a
full copy. Try running a maven proxy, like Archiva, Nexus or Artifactory, which
work like a mirroring proxy. When they don't have a requested artifact, they
will collect it from central or any other repository you set
Hi,
We are thinking about setting up an internal maven 2 repository mirror here at
the European Commission.
How much space is currently required for the central repository? The maven
website mentions "16GB and growing".
Can we just rsync every couple of hours using one of the following commands
Just to let you know, I made more tests I noticed two problems :
- I have several javadocs errors I hadn't before with 2.0.7 on our
continuous integration server. Those errors are related to the jdk :
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6442982
http://bugs.sun.com/bugdatabase/view_bu
Hi Brett,
2008/4/8, Brett Porter <[EMAIL PROTECTED]>:
> Hi Vincent,
>
> I was reviewing the commits for 2.0.9 and saw this one:
> http://svn.apache.org/viewvc/maven/components/branches/maven-2.0.x/maven-project/src/main/java/org/apache/maven/profiles/activation/FileProfileActivator.java?r1=495147
On Mon, Apr 7, 2008 at 6:42 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> Time to vote on the final Maven 2.0.9 Release. We went through 8 Release
> Candidates and fixed all know regressions from 2.0.8 to 2.0.9 during
> that time. Note that there were no source changes between RC8 and this
> fin
On 08/04/2008, Brian E. Fox <[EMAIL PROTECTED]> wrote:
>
> Time to vote on the final Maven 2.0.9 Release. We went through 8 Release
> Candidates and fixed all know regressions from 2.0.8 to 2.0.9 during
> that time. Note that there were no source changes between RC8 and this
> final build.
+1 (no
41 matches
Mail list logo