I'm now being told by IBM that they provide OSGI-compliant jars which
may make all this moot.
On 07/28/2014 12:14 PM, Ron Wheeler wrote:
Scope - "provided" might do the job.
On 28/07/2014 12:52 PM, Steve Cohen wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
