[EMAIL PROTECTED] wrote:
Author: jvanzyl
Date: Sun Aug 3 23:39:35 2008
New Revision: 682270
URL: http://svn.apache.org/viewvc?rev=682270view=rev
Log:
o starting collecting the wiki, apt, and oo3 doco that has been floating around
and align it all and present a workable plan
Added:
Yes!
+1
On Sun, Aug 3, 2008 at 10:43 PM, Dennis Lundberg [EMAIL PROTECTED] wrote:
Hi,
This release is to prepare for the release of Maven WAR Plugin.
This is a new shared component, based on code from Maven Resources Plugin,
so there are no issues fixed or left in JIRA. The goal of this
a)
Hervé BOUTEMY wrote:
Hi,
While working on Report Encoding Configuration proposal [0], 2
options were discussed lately for default value [1]:
a) use fixed UTF-8 encoding
b) use same encoding as source files
Both options seem viable: choosing between them will be a question of
Jason van Zyl ha scritto:
On 3-Aug-08, at 9:05 PM, Brett Porter wrote:
On 04/08/2008, at 1:46 PM, Jason van Zyl wrote:
Look at the analytics, zero traffic.
I didn't expect them to be high on traffic, but you should put them
somewhere else before dumping them outright.
They are not low,
2008/8/4 Mark Hobson [EMAIL PROTECTED]:
Looks like this is not going to get resolved any time soon. In the
meantime, I'll submit an upload request with the above changes if I
hear no objections.
I decided not to rock the boat, so kept the group id as 'bouncycastle'
and the incorrect
I'll upgrade parents in the trunk to see if we don't have issues with those
new versions.
The major part of our plugins are always using maven-plugins 11
cheers
Arnaud
On Sun, Aug 3, 2008 at 2:59 PM, Dennis Lundberg [EMAIL PROTECTED] wrote:
Hi
It's time to start releasing our parent POMs:
2008/7/31 Mark Hobson [EMAIL PROTECTED]:
Was any consensus reached regarding uploading bouncycastle 140 to
central? I was about to submit an upload request and then recalled
this discussion. Whilst we're doing this, shall we fix the
following?:
- use org.bouncycastle group id rather than
+1
2008/8/3 Wendy Smoak [EMAIL PROTECTED]:
It's time to release the Deploy plugin.
We solved 3 issues and added 1 new feature:
http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13110styleName=TextprojectId=11131Create=Create
* [MDEPLOY-45] - Classifier not supported by
+1
Emmanuel
On Sun, Aug 3, 2008 at 2:37 AM, Wendy Smoak [EMAIL PROTECTED] wrote:
It's time to release the Deploy plugin.
We solved 3 issues and added 1 new feature:
http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13110styleName=TextprojectId=11131Create=Create
* [MDEPLOY-45]
Hi,
John Casey wrote:
Hi,
Here's your daily dose of Maven 2.0.10! I've fixed the regressions
pointed out in RC4, and added integration tests to guard
against their
reintroduction. The new release candidate can be found here:
http://people.apache.org/~jdcasey/stage/apache-maven/2.0.10-RC
This is my objection to basing it on the source encoding.
My preference is to pick output encoding as UTF-8 with a simple means to
change it. Source encoding is a different matter. Some source files should
never be UTF-8 encoded and yet the output should not be encoded in the same
encoding...
This may have to do with some very inefficient code I had to put in to
solve MNG-3530. It's doing interpolation of the build section of the POM
per-plugin now, and restoring it to the dynamic state just after each
plugin executes. This was necessary to allow modifications to the
project
Hi there,
Is there any good reason why dependencyManagement blocks can't consist
of just groupId, artifactId and scope? It seems that version is
mandatory, even though I just want to manage the scope and don't care
about the actual version being used.
Cheers,
Mark
Is it failing in the maven-plugins tree too? It looks like the plugin
isn't inheriting from the proper parent so that I can override the
distMgt section to deploy to Nexus. It's currently going against
apache.snapshots.
-Original Message-
From: Arnaud HERITIER [mailto:[EMAIL PROTECTED]
On Mon, Aug 4, 2008 at 3:40 PM, Brian E. Fox [EMAIL PROTECTED]wrote:
Is it failing in the maven-plugins tree too? It looks like the plugin
isn't inheriting from the proper parent so that I can override the
distMgt section to deploy to Nexus. It's currently going against
apache.snapshots.
ok
That's probably historical since I don't know if it originally managed
scopes.
Cheers,
Brett
On 04/08/2008, at 11:31 PM, Mark Hobson wrote:
Hi there,
Is there any good reason why dependencyManagement blocks can't consist
of just groupId, artifactId and scope? It seems that version is
Hey John,
Is it necessary for the project on every execution? I thought this was
just for ${reactorProjects} - which could be handled on demand in the
PPEE?
It might be worth running the profiler over it too to see if there are
any particular hotspots that could improved regardless.
-
Brett,
This change was in place long before the javadoc plugin problem of the
last RC. The problem happens when forking at times, too, since those
forked lifecycles sometimes require alternative target directory, etc.
If that information has already been interpolated, changeing target
2008/8/4 Brett Porter [EMAIL PROTECTED]:
That's probably historical since I don't know if it originally managed
scopes.
Thanks, I've raised MNG-3695 to track this:
http://jira.codehaus.org/browse/MNG-3695
Mark
-
To
Where it was, or not there at all yielded the same net result. There's
nothing to understand about the links, it's clear what their purpose
is which is to promote the ASF. I have no problem with that. I started
reclaiming real estate on the site that was yielding no results. I
wasn't
2008/7/28 Mark Hobson [EMAIL PROTECTED]:
You're right that provided is not transitive, although this example
relates to scope resolution which occurs when an artifacts has two
different scopes. See:
I agree it should be right, but a 3x hit in build times isn't acceptable. Given
the alternative, I would probably boot those issues to 2.1 where they can be
handled correctly. The majority of users probably aren't getting hit by these
bugs, so forcing the performance hit on them will appear as
+1
On 4-Aug-08, at 5:49 AM, John Casey wrote:
+1
Dennis Lundberg wrote:
Hi,
This release is to prepare for the release of Maven Invoker Plugin,
which is needed by many projects.
We solved 1 issue:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=14369
In 2.1 practically I think it means supporting multiple versions of
the POM. Otherwise or we'll have some serious adoption problems.
People need to be able to switch over to 2.1 without changing their
POMs or there will be a hue and a cry of such enormous volume we'll
get eviscerated.
The problem is, this was a regression issue, based on real improvements
we made to the interpolation code in 2.0.9.
To boot these issues to 2.1, we'd need to find a way to reintroduce
buggy handling of build paths into the interpolator.
Brian E. Fox wrote:
I agree it should be right, but
If we had more options WRT parsing POM fragments using the generated
modello code, it might be possible to do on-demand interpolation during
expression evaluation for plugin instance configuration...though I'm not
sure how much that would help.
BTW, I don't know for a fact this is the hot
Jason van Zyl wrote:
In 2.1 practically I think it means supporting multiple versions of
the POM. Otherwise or we'll have some serious adoption problems.
People need to be able to switch over to 2.1 without changing their
POMs or there will be a hue and a cry of such enormous volume we'll
I've checked the maven core and plugins builds, and they're both running
around 30s longer than with 2.0.9, with slightly less memory
consumption. Other builds I've tried are running nearer to +15s over 2.0.9.
Granted, these aren't huge builds, but neither are they the 3X time
increase over
I agree with John Casey that a predictable fix is more important than
a speedy build time. However, I am surprised that the one guy's build
went from 45m to 3 hours! That's a huge leap. The only thing I can
suggest is to pull something out of the Microsoft Windows development
book: the use of
Ok if it's a modest change then that's ok. I was scared by that 3x change but
since we aren't seeing that elsewhere, then lets go forward with the RC and see
if anyone else has issues.
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Monday, August 04, 2008 12:49 PM
I think it's something to put in the RC post, focus on testing:
- interpolation
- deployment and proxies
- any reproducible, consistent speed degradation
It would probably still be worth inspecting the performance with a
tool sucha s yourkit... Jörg is there any chance you could do that on
Hi,
As I shift back to looking at 2.1-alpha-1 regressions in JIRA and the
changes on trunk so far, I was hoping we could have a once off meeting
in IRC to gather up who's working on what, where we are going next,
and where we stand for a release. I don't want to waste a bunch of
time
I can be there, I think.
Brett Porter wrote:
Hi,
As I shift back to looking at 2.1-alpha-1 regressions in JIRA and the
changes on trunk so far, I was hoping we could have a once off meeting
in IRC to gather up who's working on what, where we are going next, and
where we stand for a release.
33 matches
Mail list logo
