[
https://issues.apache.org/jira/browse/XALANJ-2710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787846#comment-17787846
]
Alexander Kriegisch commented on XALANJ-2710:
---------------------------------------------
[~vladimirsitnikov], feel free to also review the PR again. Based on your
feedback, I have updated it to now be relocation-friendly, using the resource
filtering approach from the example repository. I.e., we do not need any source
code generation steps, the project just builds in the IDE after {{mvn clean}},
even though then a default version 0.0.0 is displayed by each version class.
But as soon as {{mvn compile}} is run, resource filtering will have generated
the properties files in the target directory, and the correct version is
displayed. The same is true inside the JAR with {{mvn package}}. For testing
purposes, I also added Maven Shade with a relocation step in both modules and
successfully tested that is still works after relocation, just like in my
little example PoC project.
> Use resource files for version numbers
> --------------------------------------
>
> Key: XALANJ-2710
> URL: https://issues.apache.org/jira/browse/XALANJ-2710
> Project: XalanJ2
> Issue Type: New Feature
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
> Reporter: Alexander Kriegisch
> Assignee: Gary D. Gregory
> Priority: Major
> Attachments: screenshot-1.png
>
>
> The current Ant build uses {{\*.src}} files, replaces placeholders with
> version numbers there, then renames them to {{\*.java}} and copies them to
> their respective destination directories.
> In the current Maven build in branch {{{}xalan-java-mvn-refactored{}}}, this
> should be replaced by simple, standardised Maven resource filtering. The
> values would be written into a properties file, which then in turn will be
> read as normal classpath resources from Java classes that need version
> information.
> Even easier than that would be to simply use the standard
> {{META-INF/maven/[groupId]/[artifactId]/pom.properties}} file generated into
> JARs by Maven anyway. They look like this:
> {code:java}
> artifactId=xalan
> groupId=xalan
> version=2.7.3
> {code}
> The only drawback here is that each corresponding Java file per module would
> need to know its own group and artifact ID in order to locate the resource
> file. But those usually do not change often, and it would be the cheapest
> solution to just hard-code them into the corresponding {{*Version.java}}
> file. Creating extra resource files with a fixed paths would be more work and
> the exact location would also have to be hard-coded into the Java files.
> Outside the JAR file context, e.g. when running tests from an IDE, the file
> would be located in {{{}target/maven-archiver/pom.properties{}}}, i.e. the
> Java classes reading the version numbers would need to try that path as a
> fallback.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
