kriegaex opened a new pull request, #125:
URL: https://github.com/apache/xalan-java/pull/125
Version numbers are now read from Maven-generated `pom.properties` files fo
-
- Xalan Processor
- Xalan Serializer
The 3 existing `*Version.java` classes have been adjusted correspondingly,
the related `*.src` files deleted, because they are no longer necessary.
BTW, the properties files are found both in JARs and in the file system, if
the Maven build has created them. Otherwise, a version number 0.0.0 will be the
fallback.
@kubycsolutions, sorry for being lazy again. This PR was branched off of the
one for XALANJ-2709, even though I could also have branched it off the Maven
branch. But I hope that you can review and merge them sequentially in short
order.
Please note one breaking change: Both Xalan and Xalan Processor used to
return the same version string. Then why do we need two version classes in a
single Maven module for them in the first place? Serializer did not mention the
product name Xalan at all, so it could be any serializer. I changed it as
follows:
Product | Old version string | New version string
--|---|--
Xalan | Xalan Java 2.7.3 | Xalan Java 2.7.3
Processor | Xalan Java 2.7.3 | Xalan Processor Java 2.7.3
Serializer | Serializer Java 2.7.3 | Xalan Serializer Java 2.7.3
---
Personal note: There are several things I do not like about the current
state of affairs, but I did not want to change too much:
1. There are 3 version classes. I think that, if designed correctly, a
single such class in a shared module would suffice. Now, there is code and
Javadoc duplication.
2. The 3 existing classes used different ways to solve the same problem
(constants vs. getter methods) and different javadoc styles. I harmonised the
former (now all of them use getters), but did not touch the javadocs, because
they are ugly anyway and need an overhaul. Not even the `@return` tag is used
correctly or not at all. The formatting is weird and looks like a mess in HTML.
It only caters to source code formatting, but even there I do not understand
the weird indentation within the javadoc comments.
3. The version classes could be quite small with just a helper method to
read the properties file and find the version number there. But because the
getters for parts of the version numberlike major/minor are public - why? does
anyone use them? - it would have been a breaking change to delete them. To
retain them, I had to parse the version number from Maven into its constituent
parts using a regex, only to concatenate the parts later in the method used to
retrieve the version number. This is all too convoluted for my taste.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
