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]
