I don't know if it's worth trying to upgrade the container. I tried
for a couple days and gave up. I'm not really sure it's worth the
effort. I think classworlds would be a few hours work and very doable.
On 24-Sep-08, at 7:15 PM, John Casey wrote:
If you're talking about migrating that chan
If you're talking about migrating that change back to an older version
of plexus/classworlds for the 2.2.x branch, I've been thinking of doing
a write-up to migrate off of plexus 1.0-alpha-9 and make it up to date
with the current plexus work.
Given that, would you still have to backport thing
Should work but I've been testing it with trunk ... I would have to
restore some classes to make it work on the branch but I'll look.
On 24-Sep-08, at 5:41 PM, John Casey wrote:
Awesome! Let's put it up with doco, etc. on the 2.2.x release plan,
wdyt?
Jason van Zyl wrote:
I have simple "i
Awesome! Let's put it up with doco, etc. on the 2.2.x release plan, wdyt?
Jason van Zyl wrote:
I have simple "i don't want to export this" working in ClassWorlds now
so I will attempt to integrate that after doing some testing with Oleg
in integrating Mercury.
On 23-Sep-08, at 3:57 PM, Igor F
I have simple "i don't want to export this" working in ClassWorlds now
so I will attempt to integrate that after doing some testing with Oleg
in integrating Mercury.
On 23-Sep-08, at 3:57 PM, Igor Fedorenko wrote:
Would not it be better to move wagons and anything else not intended
to be v
On 23/09/2008, at 11:57 PM, Igor Fedorenko wrote:
Would not it be better to move wagons and anything else not intended
to be visible by plugins into a separate classloader?
I believe that is essentially what the container changes on trunk did.
Whether it's something along those lines or a s
Would not it be better to move wagons and anything else not intended to
be visible by plugins into a separate classloader?
Brett Porter wrote:
/me cheers
Yep, go for it.
This will also mean producing shaded versions of the wagons though I
think, or creating a shaded "built-in wagons" JAR, to
/me cheers
Yep, go for it.
This will also mean producing shaded versions of the wagons though I
think, or creating a shaded "built-in wagons" JAR, to prevent some of
their dependencies being forced on plugins. The ITs for MNG-3581/3599
might pick this up, but it would be worth an extra IT
Just means we use a shaded version of plexus instead of shading the
entire Maven runtime.
Wouldn't change anything. Plugins could still use their own version of
p-u.
On 22-Sep-08, at 7:12 PM, Benjamin Bentmann wrote:
Jason van Zyl wrote:
I would like to remove the uber jar in 2.1 and do
Sounds good to me, as long as we test to make sure it doesn't affect
plugins using things like a different version of plexus-utils.
-j
---
John Casey
Developer and PMC Member, Apache Maven (http://maven.apache.org)
Member, Apache Software Foundation
Blog: http://www.ejlife.net/blogs/buildchimp
AM cc
Subject
Please respond to No more uber jar
"Maven
Hey, so how's the vacation going?
Will Mark still be contacting us after Oct 1?
Gil
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Monday, September 22, 2008 10:01 AM
To: Maven Developers List
Subject: No more uber jar
I made the uber jar and I think it
Jason van Zyl wrote:
I would like to remove the uber jar in 2.1 and do it on the 2.2 branch
as well.
Any objections?
How does this relate to MNG-2892? Are there other means that allow
plugins to use different versions of the libs that are used by the core
like plexus-utils?
Benjamin
--
I made the uber jar and I think it was a mistake. It's a complete PITA
to swap in new jars and test and the shading can work on the JARs
necessary.
I would like to remove the uber jar in 2.1 and do it on the 2.2 branch
as well.
Any objections?
Thanks,
Jason
14 matches
Mail list logo
