I think the most painless and maven-like way to proceed given the
non-maven requirements of IBM here is to install the IBM Websphere MQ
client package on each development or production machine that needs it
and alter pom xml to make these system-scope dependencies, which lets me
specify the non-standard location.
Then, I'm hoping that the manifest generator of the application jar will
pick up these locations and put them on the classpath.
On 07/25/2014 01:05 PM, Steve Cohen wrote:
Yecch. I'm already using the assembly plugin. But it appears that with
that approach instead of using the lovely dependency set, I must use
<file>s (handle each jar individually) because this is the highest level
that allows renaming of the files.
Ugh.
On 07/25/2014 12:44 PM, Steve Cohen wrote:
Ok, thanks, Curtis. I will have to address it on the packaging side, I
suppose. It will force me to get tricky and not just use a dependency
set (which was lovely and simple).
IBM's requirement is ironclad. They won't even talk to me in spite of
having a support contract if we repackage the jars.
On 07/25/2014 12:22 PM, Curtis Rueden wrote:
Hi Steve,
The easiest way to accomplish this would be if k could get these jars
into the nexus repository named as IBM named them.
Overriding the default naming scheme of JARs in a Maven repository has
been
requested on this list many times, and the answer is always that the
naming
scheme cannot be overridden. It is a requirement of the Maven repository
that the name be "artifactId-version.extension" (or
"artifactId-version-classifier.extension" if there is a classifier).
Remember that the main purpose of Maven repositories is to provide
dependencies for consumption by downstream code in a standard form --
not
to cater to application-specific deployment needs.
But you can address the issue on the packaging side, when you build your
application archive. As suggested by others, the maven-assembly-plugin
can
do this sort of thing. And you can also override the JAR manifests'
Class-Path entries according to your needs by configuring the
maven-jar-plugin: see e.g. http://stackoverflow.com/a/5893391.
Alternately, if you can somehow override or work around how the IBM
trace
feature works, that would avoid the issue too. Is it just that the JARs
have to be on the classpath at runtime? Because there are many ways of
addressing that. Subclassing one or more offending classes to fix their
behavior? Or use a custom ClassLoader? Or, worst-case scenario, bytecode
manipulation (e.g., http://www.javassist.org/) to "fix" IBM's limited
logic?
Regards,
Curtis
On Fri, Jul 25, 2014 at 12:07 PM, Steve Cohen <[email protected]>
wrote:
To elaborate further on what I'd like to do, I think I need to create a
POM file that simply lists all these jars and supply that to the Nexus
archive uploader. But I have no idea what must be included in such a
POM.
The GUI archive uploader does not allow me to override default
naming of
these files.
On 07/25/2014 11:50 AM, Steve Cohen wrote:
Container? Guess I need to supply more details.
This is a standalone J2SE app. The server side is legacy. There
is no
container. it isn't a web app.
Instead it's run as a jar with the classpath generated from maven's
dependency set and listed in the jar's manifest. Maven generates the
manifest. The easiest way to accomplish this would be if I could get
these jars into the nexus repository named as IBM named them. Then I
can get them to a single directory so that the IBM trace facility can
find them.
On 07/25/2014 11:39 AM, David Karr wrote:
It's conceivable you don't have to mess with any sort of repackaging.
The problem is that the MQ classes that your container loads have to
be in
a specific location, with a specific name. Simply deploy your
unmodified
application into a container with an altered classpath, where those
"special" jars are in front of everything else on the classpath.
On Fri, Jul 25, 2014 at 9:07 AM, Steve Cohen <[email protected]>
wrote:
I have a client application that was developed with Websphere
MQ. Our
company has a Maven nexus repository. In this repository, we have a
place
to store third party jars. In here I stored the MQ jars. Since the
repository demanded a version number I provided one (7.0.1.8,
7.0.1.9, etc)
and in each case these version numbers were appended to the jar
name. This
led to a clean build and deploy process and everyone was happy.
Now we have need of turning on MQ traces. It turns out that IBM
offers no
way of doing this unless the jar files are in a single directory
named
exactly as IBM named them in their release. So we have to
repackage the
application so as to accomplish this.
Before I jump into hacking this mess into place, is there a
recommended
way of handling this so that the maven repository, maven, and ibm
are
all
happy?
Thanks,
Steve Cohen
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
