pom.xml doesn't read my properties about properties-maven-plugin HOT 14 CLOSED

This does not work nor is it the intention of properties maven plugin and furthermore what would be the advantage to read properties from a file to define versions of dependencies?

from properties-maven-plugin.

So this plugin doesn't replace entirely the properties tag. I think it should be clarified in the plugin description because there are some questions open on stack overflow regarding this usage. Thank you for the prompt response

from properties-maven-plugin.

Usecase in git(flow) for the feature suggested in this issue:
We have some dependency-versions defined as properties in our pom.xml. When we create a release-branch, these properties are changed both on the release branch and on develop. That means we get a conflict every time we automerge release => develop.

Possible fix is to set merge=ours on the pom.xml, but this means we don't get any changes at all from the release-branch for this file. There might be other relevant changes than the dependency-versions.

It would be really convenient if we could specify the relevant dependency-versions in an isolated property-file and only do the merge-strategy=ours on this specific file.

Any workarounds for isolating dependency-versions outside pom.xml?

from properties-maven-plugin.

Don't agree at all: properties should properties indeed dependent of their representation and not some what maybe properties under some trivial circumstances. So basically this should be build into Maven.
Usage szenario's see also : https://axelfontaine.com/blog/dead-burried.html. So large scale builds reducing the necessary build version information to the absolute minimum. And not having to wade through +100 lines dependenncyManagement in boms and also track their versions....

from properties-maven-plugin.

@shilpa1989 the only reliable way I found is to have a "pom-template.xml" and the other build system create "pom.xml" from it. It's terrible, but any attempt of parametrizing version in pom lead to subtle and non immediate breaking in plugins.

from properties-maven-plugin.

A template is good for project creation, not for the whole lifecycle.
We have a similar situation. There are about a hundred of projects in its own repositories. Some 20-30 of them are the source of dependency of the rest of the projects. When one project makes a change and increases its version number, we need to search many down stream dependent projects to update its version number. With more and more micro-services coming, this is not manageable. A properties include or just simple xml file include to include version number strings for all dependencies will solve all the version upgrade issues.

from properties-maven-plugin.

This does not work nor is it the intention of properties maven plugin and furthermore what would be the advantage to read properties from a file to define versions of dependencies?

What is the point of the properties maven plugin? How do we read properties from it?

I can understand that it does not make sense to inject properties into the version tag - but what about injecting properties else where in the pom.xml file ?

from properties-maven-plugin.

This does not work nor is it the intention of properties maven plugin and furthermore what would be the advantage to read properties from a file to define versions of dependencies?

The plugin's own landing page defines the use case of reading properties from a file:

The Properties Maven Plugin is here to make life a little easier when dealing with properties. It provides goals to read properties from files and URLs and write properties to files, and also to set system properties.

It's main use-case is loading properties from files or URLs instead of declaring them in pom.xml, something that comes in handy when dealing with different environments.

And in the read-project-properties goal page it states:

The read-project-properties goal reads property files and URLs and stores the properties as project properties. It serves as an alternate to specifying properties in pom.xml. It is especially useful when making properties defined in a runtime resource available at build time.

So with verbiage like

It serves as an alternate to specifying properties in pom.xml

It's fair to assume it can be used the in the same ways pom properties are afforded since it's an alternate to a pom property

What would be the advantage of not allowing this? Just because it wasn't the 'intention' doesn't mean things can't evolve?

Clearly the community at large has a unified assumption that this would be possible due to the documentation verbiage and goal descriptors. I would recommend to either update the documentation to support what this is intended for more concisely or just give the people what they want?

from properties-maven-plugin.

It does not replace the properties tag correct. The best way to define dependencies which should be maintained in a central location the dependencyManagement tag is the one to use....

from properties-maven-plugin.

@khmarbaise you want to share these versions between maven and and one other build system and you want to centralize the information at one place. And obviously, in the middle of a big XML file, it is not the best interoperable way to do it.

from properties-maven-plugin.

@AlexGreg AlexGreg i am also facing the same problem. Could you please share the solution.

from properties-maven-plugin.

Looks like it's technically the same issue as in #39 and #20... Different scenarios, same behavior.

from properties-maven-plugin.

Hello my pom file is the following:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

    <groupId>com.example</groupId>
    <artifactId>master</artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <name>Master test</name>

    <build>
      <plugins>
        <plugin>
          <groupId>org.codehaus.mojo</groupId>
          <artifactId>properties-maven-plugin</artifactId>
          <version>1.0.0</version>
          <executions>
              <execution>
                  <phase>initialize</phase>
                  <goals>
                      <goal>read-project-properties</goal>
                  </goals>
                  <configuration>
                      <files>
                          <file>my.properties</file>
                      </files>
                  </configuration>
              </execution>
          </executions>
        </plugin>
      </plugins>
    </build>

    <dependencies>
      <dependency>
        <groupId>org.apache.logging.log4j</groupId>
        <artifactId>log4j</artifactId>
        <version>${log4j.version}</version>
      </dependency>
    </dependencies>
</project>

and inside the my.properties file, located at the same level as the pom, only log4j.version=2.5.

Now, when I do a mvn install I get

'dependencies.dependency.version' for org.apache.logging.log4j:log4j:jar must be a valid version but is '${log4j.version}'. @ line 37, column 18

This kind of use case is useful for user acceptance ( selenium ) testing in my opinion. A separate pom drags a dependency from a repository to test it - the actual release / snapshot number is important for deciding on how to recreate the db using incremental release sql. Being able to load properties for a given environment and specify version numbers of dependencies can help in automated user acceptance testing (Selenium).

from properties-maven-plugin.

For this particular use-case (defining dependency versions), it might not be possible with a plugin at all, since it seems that Maven resolves the dependencies before executing any plugin (even the validate phase).

This may also be of interest: https://stackoverflow.com/questions/28565091/how-to-get-a-maven-plugin-to-run-before-dependency-resolution

from properties-maven-plugin.