Sure we can coordinate that, I have an OSGi like classloader in a
branch of ClassWorlds so I can cut a release and upgrade.
But I would still like to work on the Hudson bundle to improve support
for Window, and then I would like to add
1) platform support, and by that I mean building everything that we
depend on from source in preparation for
2) trunk/branch support where we can easily try any changes on a the
trunk of a dependency or a branch of a dependency
This would enable folks (exactly what Shane is doing now) to make
changes somewhere in a dependency like ClassWorlds, Plexus, or Maven
itself and easily run through all the standard tests to make sure
everything works. Once this is done you could easily try this yourself
and validate it. Then making the suggestion, we agree and it should be
as easy as pressing a button to upgrade everything and commit the
changes.
If you want to make the change locally and validate with the Hudson
bundle I'm fine with the change. Go for it.
On 13-Jul-08, at 7:41 AM, Benjamin Bentmann wrote:
Hi,
if possible, I suggest to update Maven 2.1 to use the latest version
of Classworlds instead of 1.2-alpha-12. The recent Hudson package is
still failing for an encoding like UTF-16, among others due to
PLX-367 which prevents Maven from booting.
In this context: Brian has once setup some ITs to run Maven with
file.encoding=UTF-16. Since Maven 2.0.x is to my knowledge locked to
an old Classworlds version (i.e. there is no chance for the ITs to
ever pass), it might be best to focus on the future and upgrade
these ITs to run for Maven 2.1 instead.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more
examples
you look at, the more general your framework will be.
-- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
