[
https://issues.apache.org/jira/browse/XALANJ-2710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787566#comment-17787566
]
Vladimir Sitnikov commented on XALANJ-2710:
-------------------------------------------
{quote}can be removed from shaded JARs - this is not a reason to decline the
issue{quote}
Leaving files with there is just fine. My concern is that users would **have
to** rename the files, and it would likely to be **manual** process which would
be extra pain when xalan is a transitive dependency only.
In other words, if XalanVersion.java (or whatever) searches for resource
`META-INF/xalan/version.properties`, then the shading/repackaging code would
need to know to rename the file.
{quote} e.g. org/apache/xalan/version.properties. I tend to the latter
location{quote}
The key issue I highlight here is that users would have to rename the file and
adjust its usage when they repackage Xalan.
{quote} The way it is currently solved in Ant - *.src filed converted to *.java
files in a scripted build - is quite ugly{quote}
What is exactly ugly with that?
For example, in pgjdbc/pgjdbc we have DriverVersion.java which looks like a
regular Java file, except it is replaced at build time with a proper version
references:
https://github.com/pgjdbc/pgjdbc/blob/master/pgjdbc/src/main/version/org/postgresql/util/DriverInfo.java
{quote}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{quote}
If the IDE does not compile them, it sounds like a build tool deficiency and/or
misconfiguration to me.
I know this is not an issue with Gradle: DriverInfo.java is fully workable in
IDE, and it does not require us to implement a separate fallback.
{quote} That kind of information belongs into a resource file and should not be
not hard-coded in a Java source file{quote}
The class was there, and it was public. People might depend on it, so the class
should be maintained for backward compatibility reasons.
If you still have Version.java class, then, well, the users do not care if you
like to expose "library version with a property file" since Java API already
exists.
Of course, if Xalan versions was never exposed before, there might be several
ways to implement that. However, since Version.java already existed, I doubt
there's much value in adding properties.
What do you think of generating java file? I think it should not be complicated.
Imagine user repackages xalan from org.xalan... to
com.example.shaded.org.xalan.. If xalan uses resource files, the users would
have to rename them and ensure the repackaged code uses proper references.
Frankly, I fully agree Ant-based build might have used all sets of bad
practices, and I am nowhere of asking you to keep them as is. However, I
believe generating a java file with build version should be easy with any
modern build system, and having a simple java class would be esier for the
consumers
---
{quote} users repackaging libraries need to be aware of that fact{quote}
If the file is "ok, just include the file into the shaded artifact", then it is
not an issue.
However, if the file name or contents must be adapted when repackaing, then
users and the developers of the shading libraries must support an extra case
which might break people's builds.
---
Sorry for asking that, however, could you please re-iterate on the motivation
for the change?
What problem are you trying to solve?
I see you mention "this should be replaced by simple, standardised Maven
resource filtering", however, then you mention IDE support would need to have a
dedicated fallback: "the Java classes reading the version numbers would need to
try that path as a fallback". Having different code paths (regular and
fallback) might lead to unclear bugs like "property file did not get into the
release".
At the same time, the usage of resources would make it harder for the end users
to shade/repackage Xalan as I clarify above.
Even thought I support your intention that deviations from the standard way
should be minimized, I am sure "Version.java" is something that should better
be generated as a Java file at the build time.
I am sure the modern build tools should be able to support generation of a java
file with a version.
> 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
