Put a proxy in front of Nexus. On Tue, Jun 9, 2015 at 1:51 AM, Thomas Klöber <[email protected]> wrote: > Hi Ron, > > might have not explained it right: jarfile3.jar gets turned into > jarfile3-x.x.x.jar due to the version number i have to supply when creating > the artefact in nexus. > > I agree it would be easier to either get rid of the version number at build > time or at least change the naming to jarfile-3.jar. > But unfortunately the vendor refuses to change that. > > Hi Curtis, > > I fully agree that this is a terrible way of programming. But I asked the > vendor why they check the file name and thay say "that some other apps would > fail if they didn't have a fixed jarfile name'. Escapes me why, but again > they refuse to cahnge that... > > Bytecode patching is a no go here :) > > Thanks for all your suggestions... > > > -----Ursprüngliche Nachricht----- > Von: Ron Wheeler [mailto:[email protected]] > Gesendet: Montag, 8. Juni 2015 19:03 > An: [email protected] > Betreff: Re: Help needed with a strange fixed filename > > Can you explain how jarfile3.jar gets turned into jarfile-3.x.x? > > Lots of jar file names have numbers as the last character without that > character getting turned into a version in Nexus. > > I can see how it would get loaded into Nexus as jarfile3-1.0.0 but not > jarfile-3.1.0.0 > > Getting rid of the version number at the end of the file name at build > time is an easier task that changing the name. > > Ron > > > > On 08/06/2015 12:44 PM, Curtis Rueden wrote: >> Hi Thomas, >> >>> it's name cannot be changed because during runtime it is checked and >>> if changed a runtime exception is thrown >> IMHO, the fact that your third party JAR does that is incredibly terrible. >> >>> Yes, we could change the code with the filename check. But I'm loath >>> to do it since it is a 3rd party jar file and we had to do this every >>> time a new version is released... >> One "big hammer" way to work around this, and other horrible third party >> behaviors, is bytecode manipulation using a library such as Javassist or >> ASM. Also called "runtime patching," you can make a surgical change to the >> stupid exception thrown by the 3rd party library, which will be resistant >> to future upgrades of that library. It does require careful use of >> ClassLoaders, though. It would be much more ideal to work with the upstream >> vendor/developers to fix the problem there. >> >> Regards, >> Curtis >> >> On Mon, Jun 8, 2015 at 8:10 AM, Thomas Klöber < >> [email protected]> wrote: >> >>> Hi Karl Heinz, >>> >>> thanks for your answer. >>> >>> Yes, we could change the code with the filename check. But I'm loath to do >>> it since it is a 3rd party jar file and we had to do this every time a new >>> version is released... >>> >>> I'm just surprised that there is no other way or means to tell Maven that >>> a different naming scheme should be used... >>> >>> Deployment at customer site is no problem, the nexus and naming issue only >>> affects us during development. >>> >>> >>> -----Ursprüngliche Nachricht----- >>> Von: Karl Heinz Marbaise [mailto:[email protected]] >>> Gesendet: Freitag, 5. Juni 2015 14:34 >>> An: Maven Users List >>> Betreff: Re: Help needed with a strange fixed filename >>> >>> Hi Thomas, >>> >>> >>> That the file is names in Nexus is the default naming schema within a >>> maven repository so there is no chance to change it. >>> >>> So first question: Why not changing the code which checks the filename >>> and follow the naming convention..? >>> >>> What you can do is to get the appropriate artifact via plugin (like >>> maven-dependency-plugin) and rename it during the packaging of your >>> distribution archive (which i assume you have?) Or are we talking about >>> an EAR file? >>> >>> >>> >>> >>> On 6/5/15 1:58 PM, Thomas Klöber wrote: >>>> Hi folks'es, >>>> >>>> I am having some problems, getting an external jar-file into my Maven >>> project. >>>> Here is the issue: >>>> >>>> · the jar file has a fixed name, lets say jarfile3.jar (digit 3 >>> is important!) >>>> · it's name cannot be changed because during runtime it is >>> checked and if changed a runtime exception is thrown >>>> · if I create an artefact for it in my nexus, the file name is >>> changed to jarfile-3.x.x >>>> · adding this to my pom.xml as a dependency everything builds >>> just fine >>>> · however, if I run my application now, it falls over with the >>> above runtime exception >>>> What would be the best way of incoorporating an external jar into my >>> project without having hard-coded pathnames? >>>> We are using Eclipse Kepler as IDE and Maven 3 >>>> >>>> Thanks, >>>> _________________________________ >>>> SecurIntegration >>>> Thomas Klöber >>>> Software Engineer >>>> Rösrather Str. 702 >>>> 51107 Köln >>>> Fon: +49 (221) 71 99 00-0 >>>> Fax: +49 (221) 71 99 00-23 >>>> >>>> www.SecurIntegration.com<http://www.SecurIntegration.com> >>>> >>>> Amtsgericht Köln HRB 35063 >>>> Geschäftsführer: Guido Schneider >>>> >>>> Determine your actual SAP license needs< >>> http://www.securintegration.com/slc> >>>> >>> Kind regards >>> Karl Heinz Marbaise >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> > > > -- > Ron Wheeler > President > Artifact Software Inc > email: [email protected] > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > > > --------------------------------------------------------------------- > 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]
