Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
52 changes: 41 additions & 11 deletions pom.xml
Original file line number Diff line number Diff line change
Expand Up @@ -27,7 +27,6 @@
<module>serializer</module>
<module>xalan</module>
<module>samples</module>
<module>xalan2jtaglet</module>
<!-- The binary mode of maven-assembly-plugin needs to run after all the
other modules have created their artifacts. Standard solution to
achieve this sequencing is to make it a separate module which
Expand All @@ -37,6 +36,32 @@
<module>distribution</module>
</modules>

<profiles>
<profile>
<id>jdk8</id>
<activation>
<jdk>[,9)</jdk>
</activation>
<properties>
<xalan.taglet.artifactId>xalan2jtaglet</xalan.taglet.artifactId>
</properties>
<modules>
<module>xalan2jtaglet</module>
</modules>
</profile>
<profile>
<id>jdk9+</id>
<activation>
<jdk>[9,)</jdk>
</activation>
<properties>
<xalan.taglet.artifactId>xalan2jtaglet_jdk9</xalan.taglet.artifactId>
</properties>
<modules>
<module>xalan2jtaglet_jdk9</module>
</modules>
</profile>
</profiles>
Comment on lines +39 to +64
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even though adding two profiles is not much code, I suggest just requiring Java 17 for build, and use --release 8, --target 8 to target Java 8 bytecode. It would not require profiles, it would be easier to understand.

It would be way easier to support, and it would be way fewer bugs since javac 17 should be tested way better than javac 8.

Copy link
Contributor Author

@kriegaex kriegaex Nov 18, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had discussed that with @kubycsolutions in #120 (comment).

I said:

Another question is if you really want to force every developer to run the build on JDK 8 just because of the taglet dependencies on old com.sun JDK packages, which have been superseded by others on JDK 9+. Basically, you have 3 options:

  • Continue as is.
  • Require JDK 9+ for the build and migrate the taglet thingy to the new API standard.
  • Add a JDK 9+ variant of the taglet code on top of the JDK 8 version and configure the build to use one on JDK 8 and the other on JDK 9+.

To which Joseph replied:

Xalan currently promises to run on JRE 8. That doesn't absolutely require that we build on JDK 8, I suppose, but I want to retain the ability to do so. For now, that rules out requiring 9+. But we'll move forward someday.

As a first-time contributor to this project, I complied, which is the reason why the solution looks like this and no different. Vladimir @vlsi, can you please discuss with Joseph? My suggestion is to keep the build on JDK 8 for now, i.e. accept my solution, because all the work is done already, and I would be quite disappointed to have invested my time just to revert most of it again now.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My take is that dropping JDK8 build compatibility is a separate discussion, worth considering but a bit of a distraction at this moment.

Changing the Java 8 compilation requirement -- if I'm not hallucinating that the policy still exists; remember I'm just getting back to Xalan 15 years later and still catching up -- is something I'd want to warn our users of. If nothing else, supporting both gives us a deprecation window.

So my take is: Valid question, open it separately as technical debt, discuss, and deal with it as its own issue rather than here.

Other Committers may have other opinions. But I'm going to accept this into my branch; it can always be simplified after that discussion, or folks can throw rocks at it before merge into main if they really feel we need to delay the already-large mvn proposal further.

(FWIW, I'm inclined to withdraw my PR to Master/Main again. It was originally posted for discussion; it wasn't ever ready for merge and in hindsight I should have just asked folks to review it unsquashed on the fork. And in fact once we have it ready to consider merging, I'm tempted to reconstruct it in proper incremental change form, thus undoing the squash and making the actual concepts clearer in the history, at the admitted cost of losing some history of my mistakes. Downside is my being distracted by it that much longer. I freely admit I mis-sized the effort to learn the Maven Way.)

Copy link
Contributor Author

@kriegaex kriegaex Nov 18, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My take is that dropping JDK8 build compatibility is a separate discussion

Agreed.

Changing the Java 8 compilation requirement -- if I'm not hallucinating that the policy still exists

If it still exists, it is a bit weird. Java 8 is no longer supported, even as an LTS release. I understand that Xalan should run on Java 8, but where is the value in building it on Java 8? Anyway, I implemented it that way and hope you can merge it soon. Sorry for the pressure, but I always try to minimise the difference between touch time and cycle time in everything I do. Frequent context changes lead to loss of efficiency. Moreover, code rots.

If nothing else, supporting both gives us a deprecation window.

True.

(FWIW, I'm inclined to withdraw my PR to Master/Main again. It was originally posted for discussion; it wasn't ever ready for merge

Simply mark it as a draft PR.

image

once we have it ready to consider merging, I'm tempted to reconstruct it in proper incremental change form

That would be a total waste of time. It's what it is. (Sorry, I watched "The Irishman", could not resist.) That PR was open too long already. I suggest focusing on getting it done, reviewed and merged. It does not need to be perfect, just good enough. Besides, perfection would be in stark contrast to the rest of the code in Xalan-J. 😉 IMO, the sooner we can leave Ant behind, the better.

Moreover, I would not like to see my commits being redone by someone else who is then listed as an author.


<build>
<pluginManagement>
Expand Down Expand Up @@ -85,6 +110,15 @@
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.11.0</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
</plugins>
</pluginManagement>

Expand All @@ -105,14 +139,6 @@
</resource>
</resources>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>

<plugin>
<groupId>org.apache.maven.plugins</groupId>
Expand Down Expand Up @@ -327,15 +353,17 @@
</group>
</groups>

<!-- Locally provided taglet; see xalan2jtaglet module -->
<!-- Locally provided taglet; see xalan2jtaglet and
xalan2jtaglet_jdk9 modules
-->
<taglets>
<taglet>
<tagletClass>xalan2jtaglet.XSLUsageTag</tagletClass>
</taglet>
</taglets>
<tagletArtifact>
<groupId>xalan</groupId>
<artifactId>xalan2jtaglet</artifactId>
<artifactId>${xalan.taglet.artifactId}</artifactId>
<version>${project.version}</version>
</tagletArtifact>

Expand All @@ -347,6 +375,8 @@
build when the local Maven repo is clean.
-->
<excludePackageNames>xalan2jtaglet</excludePackageNames>
<!-- Necessary when building on JDK 9+ -->
<source>1.8</source>
</configuration>

<reportSets>
Expand Down
11 changes: 0 additions & 11 deletions serializer/pom.xml
Original file line number Diff line number Diff line change
Expand Up @@ -59,23 +59,12 @@

<build>
<plugins>

<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>

<!-- Copy generated jarfile up to xalan-java/build/,
for backward compatibility with Ant builds. -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
</plugin>

</plugins>
</build>

Expand Down
10 changes: 1 addition & 9 deletions xalan/pom.xml
Original file line number Diff line number Diff line change
Expand Up @@ -32,15 +32,6 @@
</resource>
</resources>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>

<!-- https://github.com/vbmacher/cup-maven-plugin

NOTE: There is an XPathParser.java in both xalan/xsltc/compiler/ and
Expand Down Expand Up @@ -135,6 +126,7 @@
</plugin>
<!-- And -source.jar -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
</plugin>

Expand Down
27 changes: 12 additions & 15 deletions xalan2jtaglet/pom.xml
Original file line number Diff line number Diff line change
Expand Up @@ -9,24 +9,21 @@
</parent>

<artifactId>xalan2jtaglet</artifactId>
<name>@xsl.usage taglet</name>
<description>Implementation of the @xsl.usage taglet, used in the Xalan package's javadoc to indicate classes which, while public for cross-module access, are not intended to be called by end-users.</description>
<name>@xsl.usage taglet JDK 8</name>
<description>
Implementation of the @xsl.usage taglet, used in the Xalan package's javadoc
to indicate classes which, while public for cross-module access, are not
intended to be called by end-users.
</description>

<!-- Needs com.sun.javadoc.*, of course. WARNING: The rules for
finding the tools.jar equivalent can get a bit hairy. This
*should* work on Linux and Windows; Mac may want the resolving
plugin instead.
-->
<properties>
<toolsjar>${java.home}/../lib/tools.jar</toolsjar>
</properties>
<dependencies>
<!-- Automatically depends on tools.jar up to JDK 8, but not on JDK 9+.
This way, we do not need to manually define profiles for this task.
-->
<dependency>
<groupId>com.sun</groupId>
<artifactId>tools</artifactId>
<version>1.6.0</version>
<scope>system</scope>
<systemPath>${toolsjar}</systemPath>
<groupId>com.github.olivergondza</groupId>
<artifactId>maven-jdk-tools-wrapper</artifactId>
<version>0.1</version>
</dependency>
</dependencies>

Expand Down
56 changes: 29 additions & 27 deletions xalan2jtaglet/src/main/java/xalan2jtaglet/XSLUsage.java
Original file line number Diff line number Diff line change
@@ -1,49 +1,51 @@
/** Taglet for Xalan-Java documentation, giving us a standard way to
indicate when classes are public only because they are shared
across packages within Xalan code, not because they are intended for use
by others. Typical: "@xsl.usage internal"

Technically it might be better to OSGIfy the Xalan code, which
would also permit demand-loading of only the classes actually being
used by this execution... but that's an idea for the future.

This code renders the tag keywords (internal, advanced, experimental)
into their expanded renderings in the Javadoc.
*/
//
// Source code recreated from xalan2jtaglet.jar by IntelliJ IDEA
// (powered by FernFlower decompiler)
//

package xalan2jtaglet;

import com.sun.javadoc.Tag;

/**
* Taglet for Xalan-Java documentation, giving us a standard way to
* indicate when classes are public only because they are shared
* across packages within Xalan code, not because they are intended for use
* by others. Typical: "@xsl.usage internal"
* <p>
* Technically it might be better to OSGIfy the Xalan code, which
* would also permit demand-loading of only the classes actually being
* used by this execution... but that's an idea for the future.
* <p>
* This code renders the tag keywords (internal, advanced, experimental)
* into their expanded renderings in the Javadoc.
* <p>
* Source code recreated from xalan2jtaglet.jar by IntelliJ IDEA (powered by
* FernFlower decompiler), then adjusted to JDK 8 taglet API.
*/
public class XSLUsage {
public static final String TAG = "xsl.usage";
private static final int INTERNAL = 0;
private static final int ADVANCED = 1;
private static final int EXPERIMENTAL = 2;
private static final int UNSPECIFIED = -1;
private static final String[] names = new String[]{"internal", "advanced", "experimental"};
private static final String[] colours = new String[]{"FF0000", "00FF00", "0000FF"};
private static final String[] messages = new String[]{"**For internal use only**", "**For advanced use only**", "**Experimental**"};

public XSLUsage() {
}
private static final String[] names = new String[]{
"internal", "advanced", "experimental"
};
private static final String[] colours = new String[]{
"FF0000", "00FF00", "0000FF"
};
private static final String[] messages = new String[]{
"**For internal use only**", "**For advanced use only**", "**Experimental**"
};

public static String getHTML(Tag usageTag) {
int key = getKey(usageTag);
return key == -1 ? "" : "<i><font size=\"-1\" color=\"#" + colours[key] + "\"> " + messages[key] + "</font></i></DD>\n";
return key == -1
? ""
: "<i><font size=\"-1\" color=\"#" + colours[key] + "\"> " + messages[key] + "</font></i></DD>\n";
}

private static int getKey(Tag usageTag) {
for (int i = 0; i < names.length; ++i) {
if (names[i].equals(usageTag.text())) {
if (names[i].equals(usageTag.text()))
return i;
}
}

return -1;
}
}
75 changes: 39 additions & 36 deletions xalan2jtaglet/src/main/java/xalan2jtaglet/XSLUsageTag.java
Original file line number Diff line number Diff line change
@@ -1,89 +1,92 @@
/** Taglet for Xalan-Java documentation, giving us a standard way to
indicate when classes are public only because they are shared
across packages within Xalan code, not because they are intended for use
by others. Typical: "@xsl.usage internal"

Technically it might be better to OSGIfy the Xalan code, which
would also permit demand-loading of only the classes actually being
used by this execution... but that's an idea for the future.
*/
//
// Source code recreated from xalan2jtaglet.jar by IntelliJ IDEA
// (powered by FernFlower decompiler)
//

package xalan2jtaglet;

import com.sun.javadoc.Tag;
import com.sun.tools.doclets.Taglet;

import java.util.Map;

/**
* Taglet for Xalan-Java documentation, giving us a standard way to
* indicate when classes are public only because they are shared
* across packages within Xalan code, not because they are intended for use
* by others. Typical: "@xsl.usage internal"
* <p>
* Technically it might be better to OSGIfy the Xalan code, which
* would also permit demand-loading of only the classes actually being
* used by this execution... but that's an idea for the future.
* <p>
* This code renders the tag keywords (internal, advanced, experimental)
* into their expanded renderings in the Javadoc.
* <p>
* Source code recreated from xalan2jtaglet.jar by IntelliJ IDEA (powered by
* FernFlower decompiler), then adjusted to JDK 8 taglet API.
*/
public class XSLUsageTag implements Taglet {
private static final String HEADER = "Usage:";

public XSLUsageTag() {}

@Override
public boolean inConstructor() {
return true;
}

@Override
public boolean inField() {
return true;
}

@Override
public boolean inMethod() {
return true;
}

@Override
public boolean inOverview() {
return true;
}

@Override
public boolean inPackage() {
return true;
}

@Override
public boolean inType() {
return true;
}

@Override
public boolean isInlineTag() {
return false;
}

@Override
public String getName() {
return "xsl.usage";
}

public String toString(Tag arg0) {
return "\n<DT><b>Usage:</b><DD>" + XSLUsage.getHTML(arg0) + "</DD>\n";
@Override
public String toString(Tag tag) {
return "\n<DT><b>Usage:</b><DD>" + XSLUsage.getHTML(tag) + "</DD>\n";
}

public String toString(Tag[] arg0) {
String string = "";
if (arg0 != null && arg0.length != 0) {
string = "\n<DT><b>Usage:</b><DD>";

for (int i = 0; i < arg0.length - 1; ++i) {
string = string + XSLUsage.getHTML(arg0[i]) + ", ";
}

string = string + XSLUsage.getHTML(arg0[arg0.length - 1]);
string = string + "</DD>\n";
return string;
} else {
return string;
}
@Override
public String toString(Tag[] tags) {
if (tags == null || tags.length == 0)
return "";

String string = "\n<DT><b>Usage:</b><DD>";
for (Tag tag : tags)
string = string + XSLUsage.getHTML(tag) + ", ";

// Remove trailing ", ", add end tag
return string.substring(0, string.length() - 2) + "</DD>\n";
}

public static void register(Map tagletMap) {
XSLUsageTag tag = new XSLUsageTag();
Taglet t = (Taglet) tagletMap.get(tag.getName());
if (t != null) {
if (t != null)
tagletMap.remove(tag.getName());
}

tagletMap.put(tag.getName(), tag);
}
}
Loading