On Nov 19, 2008, at 1:44 PM, Martin von Gagern wrote:
I would much prefer some kind of lib directory, where I
could simply drop the library and start using it, to see if it is fit
for the job I want to use it for in the first place.
You can accomplish that by specifying the dependency with a "system"
scope. You'd tell Maven about your lib directory using <systemPath>.
The maven POM seems to lack a clear concept of task order. This seems
especially important in the packaging phase. Suppose I produce a jar
which I want to pack200, jarsign, gpgsign, include in an assembly, and
gpgsign that assembly again. Clearly order matters a lot.
I've had the exact same concern. Anyone have an answer for this?
Another aspect of this security issue is the fact that there seems
to be
no way to ask the user for a password for e.g. jarsigner and hand that
to jarsigner by some means other than a command line argument. On a
multi-user *nix machine, users can see what commands other users are
running, and I don't like them seeing my keystore passphrase.
One way to handle this is with the antrun plugin. You can use the
input task to prompt for a password and assign it to a property:
<input message="Password?" addproperty="jarsigner.password" />
Why do I need
to configure it again and again for every plugin that operates on
source
files, instead of specifying it once and for all, with the possibility
to override it on a per-file and per-plugin basis if need be? Yes, I
can
have some common ancestor configure the plugins and use a common
property name for the encoding, but this kind of hacks seems to go
against the whole idea of POMs describing projects.
I'm a little confused. You say you want to specify file encoding in
one place, but you don't want to specify it in a common ancestor. How
do you envision this working?
And interdependence
between artifacts (like one containing the other) are not expressed
either.
Isn't that what modules express?
I guess I would prefer clean instructions, like these source
files are processed by these build tools in order to produce these
artifacts.
But that is precisely what a POM is. It defines what source files are
to be processed, what build tools to use, and the artifacts that will
be produced. It may not be explicit, instead defined in a parent POM
or the Super POM, but that's only to eliminate redundancy. You just
have to learn how to read a POM file.
So I'd like to compile
all my code using the latest javac, but substutute the bootclasspath
of
a different Java API version when compiling the main project code,
along
with providing the appropriate -source and -target switches. Not
possible in Maven, afaik.
How about using the compiler plugin's bootclasspath compiler argument?
Trevor
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
