On Wed, Apr 9, 2008 at 11:07 AM, Brett Porter [EMAIL PROTECTED] wrote:
this sounds like a good optimisation, does it also take into account
additions via upload (which triggers the consumers, just not the full scan)?
It just relies on the full scan. Hmm, I wasn't aware that artifact uploads
On 09/04/2008, at 4:10 PM, Maria Odea Ching wrote:
Is it persisted to disk so it is still correct after a restart?
Yep, it's being written into the disk with different filenames and is
updated everytime new artifacts are discovered in the repo. Now that
you've
mentioned this, I think I
Not sure I understand what you are asking. :-(
There was a suggestion in the #archiva irc channel that we should offer
the code in archiva-checksum to the commons-codec project. An idea I
fully support, but have no idea how to proceed with. ;-)
Also, Brett asked a passing question about how
-1.
if I recall the discussion about plugin versions in super pom
correctly, the solution was accepted not as a way to have 100%
reprodicible build, but have reproducible builds with one version of
maven for a duration longer than a few weeks (exagerating here a bit).
So it's basically just a way
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
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
final
Hi Brett,
2008/4/8, Brett Porter [EMAIL PROTECTED]:
Hi Vincent,
I was reviewing the commits for 2.0.9 and saw this one:
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
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
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
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
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:
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
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
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
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:09 AM
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
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
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
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().
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,
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
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
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.
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,
-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
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
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
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:
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]
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
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:
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.
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
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
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 the
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
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 using a
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 change in
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. This
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
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
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, not
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
45 matches
Mail list logo
