You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Steve Cohen <sc...@javactivity.org> on 2014/07/25 18:07:01 UTC
Best way to use closed-source jars with maven repository
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best way to use closed-source jars with maven repository
Posted by Stephen Connolly <st...@gmail.com>.
Never mind... slightly different question.
You probably will need to use something like the assembly plugin or the
dependency plugin or even antrun to rename the jar files
On 25 July 2014 17:25, Stephen Connolly <st...@gmail.com>
wrote:
>
> http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-maven.html
>
>
> On 25 July 2014 17:07, Steve Cohen <sc...@javactivity.org> 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
Re: Best way to use closed-source jars with maven repository
Posted by Stephen Connolly <st...@gmail.com>.
http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-maven.html
On 25 July 2014 17:07, Steve Cohen <sc...@javactivity.org> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Best way to use closed-source jars with maven repository
Posted by Curtis Rueden <ct...@wisc.edu>.
Hi Steve,
You could amend your classpath manually to include the necessary jars as I
suggested in my previous mail, using a maven-jar-plugin configuration
block. Then "java -jar" might still work. Although I have never used that
feature with nonrelative paths... are you sure it would work?
-Curtis
On Jul 28, 2014 9:43 AM, "Steve Cohen" <sc...@javactivity.org> 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?
>
> On 07/28/2014 09:13 AM, Steve Cohen wrote:
>
>> 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 <sc...@javactivity.org>
>>>>> 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
>>>>>>>> <sc...@javactivity.org>
>>>>>>>> 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: users-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>> ------------------------------------------------------------
>>>>>>> ---------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Best way to use closed-source jars with maven repository
Posted by Steve Cohen <sc...@javactivity.org>.
There is no bug here. I was mistaken. I inadvertently neglected to
convert one of the MQ jars to system scope and so it still appeared in
the manifest. System scope jars are NOT included in the manifest which
is the correct behavior.
Sorry for the confusion.
On 07/28/2014 09:43 AM, Steve Cohen 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best way to use closed-source jars with maven repository
Posted by Steve Cohen <sc...@javactivity.org>.
I don't think so. The path that must be provided with system scope is a
feature I very much want. I chose system over provided for this reason.
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 <sc...@javactivity.org> 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best way to use closed-source jars with maven repository
Posted by Steve Cohen <sc...@javactivity.org>.
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 <sc...@javactivity.org> 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best way to use closed-source jars with maven repository
Posted by Ron Wheeler <rw...@artifact-software.com>.
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 <sc...@javactivity.org> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best way to use closed-source jars with maven repository
Posted by Steve Cohen <sc...@javactivity.org>.
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 <sc...@javactivity.org> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best way to use closed-source jars with maven repository
Posted by Stephen Connolly <st...@gmail.com>.
<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 <sc...@javactivity.org> 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?
>
>
> On 07/28/2014 09:13 AM, Steve Cohen wrote:
>
>> 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 <sc...@javactivity.org>
>>>>> 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
>>>>>>>> <sc...@javactivity.org>
>>>>>>>> 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: users-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>> ------------------------------------------------------------
>>>>>>> ---------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Best way to use closed-source jars with maven repository
Posted by Steve Cohen <sc...@javactivity.org>.
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?
On 07/28/2014 09:13 AM, Steve Cohen wrote:
> 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 <sc...@javactivity.org>
>>>> 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
>>>>>>> <sc...@javactivity.org>
>>>>>>> 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: users-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best way to use closed-source jars with maven repository
Posted by Steve Cohen <sc...@javactivity.org>.
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 <sc...@javactivity.org>
>>> 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 <sc...@javactivity.org>
>>>>>> 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: users-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best way to use closed-source jars with maven repository
Posted by Steve Cohen <sc...@javactivity.org>.
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 <sc...@javactivity.org>
>> 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 <sc...@javactivity.org>
>>>>> 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: users-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best way to use closed-source jars with maven repository
Posted by Steve Cohen <sc...@javactivity.org>.
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 <sc...@javactivity.org>
> 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 <sc...@javactivity.org>
>>>> 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: users-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best way to use closed-source jars with maven repository
Posted by Curtis Rueden <ct...@wisc.edu>.
Hi Steve,
> The easiest way to accomplish this would be if I 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 <sc...@javactivity.org>
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 <sc...@javactivity.org>
>>> 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: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Best way to use closed-source jars with maven repository
Posted by Manfred Moser <ma...@mosabuam.com>.
You need to have the files named correctly in the application bundle. So just get them from the repository as you do now and rename them as part of packaging up.
manfred
Steve Cohen wrote on 25.07.2014 10:07:
> 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 <sc...@javactivity.org>
>>> 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: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best way to use closed-source jars with maven repository
Posted by Steve Cohen <sc...@javactivity.org>.
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 <sc...@javactivity.org>
>> 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: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best way to use closed-source jars with maven repository
Posted by Steve Cohen <sc...@javactivity.org>.
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 <sc...@javactivity.org> 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best way to use closed-source jars with maven repository
Posted by David Karr <da...@gmail.com>.
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 <sc...@javactivity.org> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>