Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to include dependencies into an EAR without version in the file name

I am creating .ear using maven

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-ear-plugin</artifactId>
  <version>2.6</version>
  <configuration>
    <finalName>wsformatter-ear</finalName>
    <includeLibInApplicationXml>true</includeLibInApplicationXml>
    <version>1.4</version>
  </configuration>
</plugin>  

All dependencies in the .ear look like joda-time-1.6.2.jar, commons-io-1.4.jar etc.

But also, I have dependencies, that I want have without version. For example, how can I do, that dependency slf4j-api-1.5.6.jar will look like slf4j-api.jar in my .ear

like image 453
Ilya Avatar asked Apr 10 '12 08:04

Ilya


2 Answers

I totally agree with Michal Kalinowski. But I fell into the same situation, well, actually an inverse situation - someone have configured the project to exclude the versions in the final EAR and I was looking for a way to cancel this, because it was against the maven's lifestyle, so I've searched in the web and found this very question, but the answer I found in the code itself. You can use:

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-ear-plugin</artifactId>
   <configuration>
        <version>5</version>
    <defaultLibBundleDir>lib</defaultLibBundleDir>
    <fileNameMapping>no-version</fileNameMapping>
   </configuration>
</plugin>

The line with the tag fileNameMapping is what you want. I hope this can help.

like image 111
Jean Madson Avatar answered Nov 19 '22 18:11

Jean Madson


Basically, you can't (without some kind of hacking on Maven's plugins' configuration) and even if you could - just don't. Maven approach and philosophy about dependencies is being strict and straight about them, including default convention of having version as file name suffix. It just immediately say which version of the artifact is used. If you depend on some artifact that is often released, you have to update its version in your EAR's POM anyway, so its "propagation" isn't somehow self-acting. Therefore, I don't see any problem with this file name suffix.

If this need for frequent change is problematic for you, maybe you should consider to modify somehow this frequently released artifact's development cycle? Probably you can extend a little a time it spend during same SNAPSHOT version? Even if you do frequent "internal" releases (like nightbuilds), Maven doesn't force you to bump your version every release (in sense of Maven Release Plugin). You can stay with some SNAPSHOT version as long as you want. Even in really quick Agile processes (or Kanban) this kind of "real" release usually happens every few weeks and it's long enough to be manageable.

At the end, it's not like this I won't help you (or something like this) or don't want to. I just think you're trying to go against Maven. Maven is really powerful if you accept and go with its approach and conventions. From my experience, trying to get around this means problems (sooner or later). I've already seen many projects that had Maven-like-Ant configuration and many developers around complaining that Maven sucks. After figuring out the stuff there I said them: "Maven doesn't suck, your POMs do".

like image 21
Michał Kalinowski Avatar answered Nov 19 '22 18:11

Michał Kalinowski