Answering one of my own questions (for the archive), the files are
unpacked because MavenUtils.getProject() expects a java.io.File
argument for a Betwixt parser. I haven't used Betwixt, but I
would expect there to be another method that takes an InputStream.
This suggests that the classloader
Florin Vancea wrote:
Hello Bear, hello all,
IMHO, the final continuous build machine should be anyway a root-only
machine (OK, root and the-same-root-person-as-a-common-user). The developer
machine is also pretty much a developer-only machine, so there is little
concern about some other user fiddl
Hello Bear, hello all,
IMHO, the final continuous build machine should be anyway a root-only
machine (OK, root and the-same-root-person-as-a-common-user). The developer
machine is also pretty much a developer-only machine, so there is little
concern about some other user fiddling with the files.
Attached is a quickie implementation of a class loader, if it will
help. I didn't touch resource URLs, but an approach I've used
with a lot of success in the past is to use a form like
jar:/path/to/jarfile?file/within/jarfile
That's easy to construct, easy to parse, unique, and not easily
c
The first issue is the practice of physically unpacking plugin jar
files in the $MAVEN_HOME/plugins directly. This requires the
directory to be writable by the least privileged user who will run
maven - in practice this directory will almost always be
world-writable, perhaps with the sticky bit se
I've been struggling for the better part of the day to get maven
to work... and have identified several critical security issues in
the process. N.B., these are so critical that many sysadmins will
not only allow maven, they'll disallow anything built with it!
(Standard stuff: maven 1.0.b9, binary
