2

I'm working with a situation where we are using the LATEST and RELEASE keywords in our POM for a certain dependency (both the dependency and the project are owned by us, so we control what is LATEST and RELEASE...and we only support one version at a time). Using these keywords allows us to minimize maintenance needed after a release.

There is a step in the build process that must copy DLLs from the unpacked dependency, but since we don't specify a specific version we have the version number of the unpacked dependency hard-coded and have to update it after every release. Is there a way get the version of this dependency at run-time from a Maven property?

The properties goal of the maven-dependency-plugin (http://maven.apache.org/plugins/maven-dependency-plugin/index.html) gets the location of the artifact in the local repository (which is not what I'm looking for). The depends-maven-plugin (shown here: http://team.ops4j.org/wiki/display/paxexam/Pax+Exam+-+Tutorial+1) can generate a file that contains the various dependencies and their versions, but using that would require having a process read the file and utilize that information. I'm wondering if there is a more "Maven way", such as accessing a property for the dependency version.

EDIT: For clarification, we need the version number so we can get to the directory of the unpacked dependency to copy files.

Michael
  • 21
  • 2
  • 1
    This might help... according to [this](http://stackoverflow.com/questions/2359872/can-i-use-the-path-to-a-maven-dependency-as-a-property) you can reference the path to a jar in your local repository using this: ${maven.dependency.com.foo.Bar.jar.path} – BenjaminLinus Aug 09 '12 at 21:30
  • If you make a dependency defined by a property which is injected from outside you will make your build not reproducible which will not work. – khmarbaise Aug 10 '12 at 08:05
  • @khmarbaise Using SNAPSHOT's doesn't help because the version number itself changes from release to release. The scope of the issue described is beyond development for a specific version. I also realize that using LATEST and RELEASE makes previous builds not reproducible, but we only support the most recently released versions of our project. It is an internal library used for a web site, so we won't have more than one version actively used. Using the LATEST and RELEASE keywords cuts down on manual maintenance (we release often). Thanks for the suggestions, though. – Michael Aug 14 '12 at 13:26
  • @BenjaminLinus Thanks for the suggestion, but we need to access the unpacked artifact...which Maven does for us. We just don't have the full path to the unpacked artifact available in Maven because we use LATEST and RELEASE for the version. – Michael Aug 14 '12 at 13:28

1 Answers1

0

I'm not sure what you mean with 'maven way' but I did something like this after looking at the same plugins you already mention: 

  <build>
<plugins>
  <plugin>
    <groupId>org.codehaus.gmaven</groupId>
    <artifactId>gmaven-plugin</artifactId>
    <version>1.5</version>
    <executions>
      <execution>
        <phase>initialize</phase>
        <goals>
          <goal>execute</goal>
        </goals>
        <configuration>
          <source>                                                                                                                                                                                                                                                   
            project.properties.put('firstdependencyinthepom', project.dependencies[0]['version'])                                                                                                                                                                              
            project.properties.put('seconddependencyinthepom', project.dependencies[1]['version'])                                                                                                                                                                            
          </source>
        </configuration>
      </execution>
    </executions>
  </plugin>

and then I was able to refer to versions of these dependencies with ${firstdependencyinthepom} and ${seconddependencyinthepom} respectively.

aron
  • 1,317
  • 1
  • 12
  • 11
  • Sorry it took a bit to respond to this. That's an interesting idea, but I get either "RELEASE" or "LATEST" in the ${firstdependencyinthepom} you mentioned. It doesn't actually resolve the real version. FYI...By "Maven way" I essentially mean working within Maven and not doing something that feels odd. For example, when I mentioned a work around of using Maven to generate a file with the info and then reading it's contents back into Maven to utilize. – Michael Nov 10 '14 at 13:27