<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 <sco...@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 <sco...@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 >>>>>>>> <sco...@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-unsubscr...@maven.apache.org >>>>>>>>> For additional commands, e-mail: users-h...@maven.apache.org >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> ------------------------------------------------------------ >>>>>>> --------- >>>>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>>>>>> For additional commands, e-mail: users-h...@maven.apache.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>>>>> For additional commands, e-mail: users-h...@maven.apache.org >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: users-h...@maven.apache.org >>>> >>>> >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
