[ 
https://issues.apache.org/jira/browse/XALANJ-2710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787847#comment-17787847
 ] 

Alexander Kriegisch commented on XALANJ-2710:
---------------------------------------------

Try the demo repository again. Due to a glitch in IntelliJ IDEA, when sharing a 
project on GitHub from the IDE instead of creating it online and cloning, for 
some stupid reason it defaults to a private repo. I just fixed that, makin g it 
public. Sorry for that.

> 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

Reply via email to