On 29/02/2008, at 10:47 AM, Jason van Zyl wrote:
On 28-Feb-08, at 2:06 PM, Brett Porter wrote:
On 29/02/2008, at 8:45 AM, Jason van Zyl wrote:
Dynamic collections have been there for a while. And why is
deploy:deploy-file a concern, and for webdav. This will be the
case for all providers. FTP deploy doesn't work out of the box
either, should be start adding everything because they need a POM
to use deploy file with FTP. Probably not.
It's just purely demand based thing. As you said last year "Sure,
why not drop it in. I think people use it quite a bit. "
I did try it for a client and created other huge problems due to the
commons-* chain. Not so good all that stuff that is so commonly used
getting tossed in there.
Can you be more specific?
In 2.0.x, they are all shaded so don't interfere with plugins using
commons-logging or anything else.
In trunk, as you say the classloader isolation is better so it is also
fine?
I'm not really sure what you mean. It's all properly isolated now
and there was no code changes to make this happen other than the
few lines to add them to the filter, so I don't really see what the
problem is?
It's the dependency chain that caused problems. But you had 5
different commits changing pieces all over the place and we need to
move in the other direction having this all in one place.
I made two commits to the branch:
- http://mail-archives.apache.org/mod_mbox/maven-commits/200802.mbox/[EMAIL
PROTECTED]
- http://mail-archives.apache.org/mod_mbox/maven-commits/200802.mbox/[EMAIL
PROTECTED]
And one to trunk:
- http://mail-archives.apache.org/mod_mbox/maven-commits/200802.mbox/[EMAIL
PROTECTED]
They are essentially the same change, but are necessarily implemented
differently because trunk doesn't (and shouldn't) use shading as you
pointed out.
Help me out, I'm just a bit lost about exactly what you're objecting
to. Are you now objecting to it in both 2.0.x or just in trunk?
Better classloader isolation like what is possible in 2.1 and
ditching as much from the core as possible in the default
distribution.
I'm fine removing whatever you want from core once you can show me the
same use case working without it.
Cheers,
Brett
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
