Actually, given my requirements, I think scope system is exactly what I
need and your blanket statement that I shouldn't use this seems too rigid.
To review, these are my requirements.
1) Project already built with Maven and don't want to change that. We
want to continue using Maven both within eclipse for development and to
build the deployable artifacts for production.
2) We need to turn on a feature of IBM Websphere MQ (trace logging) that
requires that all mq jars and libraries be in the same directory and
named as IBM names them, and not with version numbers appended. (I
don't know if this is actually required, but IBM technical support will
not provide support if they know that jars are packaged differently than
how they supply them.)
3) In view of 2, the easiest way to get this layout is simply to install
websphere MQ on the client machine using IBM's install package and that
is what we need to do. Much easier than some scheme of renaming them
back to their original name in the assembly plugin as some have suggested.
4) Websphere MQ further requires that -Djava.library.path be included in
of the initial java command and defined to point to the directory where
the jars and a few DLLs are deployed in order to turn on logging traces.
Using system scope in this manner quickly enables the compiler both in
the build and with eclipse to build the project and run it.
It seems ideal for this situation.
Maven documentation says this:
"Dependencies with the scope system are always available and are not
looked up in repository. They are usually used to tell Maven about
dependencies which are provided by the JDK or the VM." (
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#System_Dependencies
).
The key point is that they are not looked up in the repository and don't
require renaming of the jar files. And "usually" doesn't sound like an
absolute prohibition.
The only problem, and it's relatively minor, is this bug(?) that system
dependencies are treated in the archiver's manifest generator as if they
were not system dependencies. Either they should not be included at all
on the manifest classpath or they should use the correct system path.
On 07/28/2014 11:05 AM, Stephen Connolly wrote:
<scope>system</scope> is for JAR files that are supposed to be put in the
JVM's ext directory or equivalent.
You do not want to use <scope>system</scope>
On 28 July 2014 15:43, Steve Cohen <[email protected]> wrote:
Sadly, my hopes were not completely fulfilled.
In spite of specifying the MQ jars as system dependencies with their own
paths, the maven manifest generator ignored these paths. This means that I
must no longer run my application with java -jar, relying on the classpath
manifest, but must specify the classpath on the command line. Doable, but
annoying.
This is arguably a bug. If system dependencies are required to list their
path, should not the manifest classpath generator respect these?
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
