jkesselm commented on code in PR #125:
URL: https://github.com/apache/xalan-java/pull/125#discussion_r1400367758
##########
serializer/src/main/java/org/apache/xml/serializer/Version.java:
##########
@@ -20,33 +20,97 @@
*/
package org.apache.xml.serializer;
+
+import java.io.FileInputStream;
+import java.io.IOException;
+import java.io.InputStream;
+import java.util.Properties;
+import java.util.regex.Matcher;
+import java.util.regex.Pattern;
+
/**
* Administrative class to keep track of the version number of
* the Serializer release.
* <P>This class implements the upcoming standard of having
- * org.apache.project-name.Version.getVersion() be a standard way
- * to get version information.</P>
+ * org.apache.project-name.Version.getVersion() be a standard way
+ * to get version information.</P>
* @xsl.usage general
*/
public final class Version
{
+ private static final String POM_PROPERTIES_JAR =
"org/apache/xml/serializer/version.properties";
+ private static final String POM_PROPERTIES_FILE_SYSTEM =
"serializer/target/classes" + POM_PROPERTIES_JAR;
+ private static final String VERSION_NUMBER_PATTERN =
"^(\\d+)[.](\\d+)[.](D)?(\\d+)(-SNAPSHOT)?$";
+ private static final String NO_VERSION = "0.0.0";
+
+ private static String version = NO_VERSION;
+ private static int majorVersionNum;
+ private static int releaseVersionNum;
+ private static int maintenanceVersionNum;
+ private static int developmentVersionNum;
+
+ private static boolean snapshot;
Review Comment:
Unfortunately, separate Version classes are necessary for the processor and
Serializer. These are separate jarfiles because they are sometimes used
independently. Hence we have to be able to ask each for it's version when the
other is not available, which makes factoring out a common superclass across
them undoable unless it's in a third jarfile. There's also the possibility of
an out-of-sync pair, which we want to make visible. I can't see introducing a
jarfile just for this, and I don't know of a Version in our dependencies which
we could subclass productively.
But if there's a separate Version for the xsltc compiler (I'm away from my
desk and can't check easily, but I think there was/is), _that_ can just proxy
or subclass Xalan's Version, since they're the same jarfile and now report the
same release version. That separation would exist only for historical reasons;
the compiler started as a separate project before we adapted it to share
Xalan's front end. I'd vote for deprecating this in favor of the Xalan Version,
if it does exist.
Of course the fine-tuning can be done as a separate PR, if folks are
amenable to that. I've just been holding off merge because I haven't found
cycles to review it myself (I'll try to do that today) and because there's
still some productive discussion here. Alex, if you'd prefer further
noncritical changes to be a separate PR, we can open a Jira item for that and
freeze this PR except for actual problems within its intended scope; I don't
want to keep you hanging on this longer than necessary.
--
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: dev-unsubscr...@xalan.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
