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

Alexander Kriegisch edited comment on XALANJ-2710 at 11/19/23 6:10 AM:
-----------------------------------------------------------------------

[~vladimirsitnikov], while you are raising a valid concern here regarding 
default Maven-generated _META-INF/maven/xalan/xalan/pom.properties_ files - 
some users might indeed think that those files are superfluous and can be 
removed from shaded JARs - this is not a reason to decline the issue, but 
rather to think about how to improve the PR. For example, instead of 
_META-INF/maven/..._ a dedicated resource file with a clearer name could be 
created in _META-INF/xalan/version.properties_ or even in a package directory, 
e.g. _org/apache/xalan/version.properties_. I tend to the latter location, 
because there users are more unlikely to delete properties files.

It is perfectly normal that JARs contain more than just class files, and users 
repackaging libraries need to be aware of that fact.

The way it is currently solved in Ant - {{\*.src}} filed converted to 
{{\*.java}} files in a scripted build - is quite ugly. I would like to avoid 
porting that to Maven. One reason is that the Java source files would not even 
exist after checking out the project, i.e. an IDE also would not compile them, 
only Maven would after they have been generated. While certainly possible, I do 
not like that approach at all. That kind of information belongs into a resource 
file and should not be not hard-coded in a Java source file. I am even thinking 
about factoring out the product name into a resource file, if we decide to have 
dedicated resource files instead of default Maven ones anyway.


was (Author: kriegaex):
[~vladimirsitnikov], while you are raising a valid concern here regarding 
default Maven-generated _META-INF/maven/xalan/xalan/pom.properties_ files - 
some users might indeed think that those files are superfluous and can be 
removed from shaded JARs - this is not a reason to decline the issue, but 
rather to think about how to improve the PR. For example, instead of 
_META-INF/maven/..._ a dedicated resource file with a clearer name could be 
created in _META-INF/xalan/version.properties_ or even in a package directory, 
e.g. _org/apache/xalan/version.properties_. I tend to the latter location, 
because there users are more unlikely to delete properties 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 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