[
https://issues.apache.org/jira/browse/XALANJ-2710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17788608#comment-17788608
]
Alexander Kriegisch commented on XALANJ-2710:
---------------------------------------------
I said integration test. Of course, unit tests always make sense. But for this
kind of thing - can the version class successfully read the resources from a
JAR or classpath? - you also want an IT in order to check for regressions in
the build process. As soon as this Maven cutover is done and the tests from the
separate test project have been migrated into Xalan-J, it makes sense to add
more tests, both unit and integration tests.
> 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: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
