[
https://issues.apache.org/jira/browse/XALANJ-2710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787568#comment-17787568
]
Alexander Kriegisch edited comment on XALANJ-2710 at 11/19/23 7:39 AM:
-----------------------------------------------------------------------
Leaving files as-is is *not* fine, because currently in the Maven branch the
version numbers are hard-coded and not generated from template or resource
files. The templating approach Ant uses would have to be recreated for Maven,
which would not be hard to do, but IMO it just has too many disadvantages.
{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}
Why would they?
{quote}The class was there, and it was public. People might depend on it,{quote}
It *is* still there and *is* still public. Maybe take a look at the PR. Even
the methods are, which is why another developer uttered concerns about them
being removed, which of course I neither intended nor did.
You know, [~vladimirsitnikov], there are two types of people: One type finds a
solution for every problem, the other one finds a problem in every solution. I
am one of the former. What do you want to be?
FYI, I was asked by Joe to help with this issue, because I was helping with a
few other Maven issues lately. I came up with this quick and easy solution,
because it works. Everything can be improved, but the progress my PR makes that
it is working and no longer hard-coded. If you have a perfect solution, feel
free to suggest your own PR. I am not even a Xalan user, I never used it before
in my whole life. I simply meant to volunteer and lend a hand with some
structural Maven issues. If that is unwelcome or not good enough, I can do
something else instead. I have no desire whatsoever to defend something you
condemn, even though it is working, and defend an improved suggestion I made
after your feedback, because again you do not like it, because it is not
exactly how you envision it to be.
was (Author: kriegaex):
Leaving files as-is is *not* fine, because currently in the Maven branch the
version numbers are hard-coded and not generated from template or resource
files. The templating approach Ant uses would have to be recreated for Maven,
which would not be hard to do, but IMO it just has too many disadvantages.
{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}
Why would they?
{quote}The class was there, and it was public. People might depend on it,{quote}
It *is* public. Even the methods are, which is why another developer uttered
concerns about them being removed, which of course I neither intended nor did.
You know, [~vladimirsitnikov], there are two types of people: One type finds a
solution for every problem, the other one finds a problem in every solution. I
am one of the former. What do you want to be?
FYI, I was asked by Joe to help with this issue, because I was helping with a
few other Maven issues lately. I came up with this quick and easy solution,
because it works. Everything can be improved, but the progress my PR makes that
it is working and no longer hard-coded. If you have a perfect solution, feel
free to suggest your own PR. I am not even a Xalan user, I never used it before
in my whole life. I simply meant to volunteer and lend a hand with some
structural Maven issues. If that is unwelcome or not good enough, I can do
something else instead. I have no desire whatsoever to defend something you
condemn, even though it is working, and defend an improved suggestion I made
after your feedback, because again you do not like it, because it is not
exactly how you envision it to be.
> 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
