[
https://issues.apache.org/jira/browse/XALANJ-2710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Kriegisch updated XALANJ-2710:
----------------------------------------
Description:
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 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}
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.
was:
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 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}
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.
> 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
>
> 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 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}
> 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: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
