This line was what misled me
"if I create an artefact for it in my nexus, the file name is
changed to jarfile-3.x.x"
You might want to add an installer to your deployment process.
I use IzPack to build an installer that puts all the right jars and
resource files in the right places.
You could add the jarfil3.jar as a resource to be included in the
deployment.
You could make a dummy class with all of the method signatures that you
need at compile time as "jarfile3-1.0.0" and mark that as "provided" in
your POM's dependencies section and provide the "jarfile3.jar" at run-time.
This would at least make life easy during the software development
stage. Need to make jarfile3.jar available for running tests.
A bit more work than it would be for your vendor to release a proper jar.
You might ask them to package 2 versions of the jar, one "as is-
jarfile3.jar" and one with a pom and jar that could be used by Maven.
This should be pretty simple and would not impact people who use the
current jarfile3.jar
Alternatively, they could test the name by ignoring everything after the
"3" (ie stop at the "-") so that jarfile3.jar and jarfile3-x.x.x.jar are
treated as the same name.
Neither of these changes would affect their other users.
Ron
On 09/06/2015 1:51 AM, Thomas Klöber 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]
