Munged opp SLF4J and log4j library building #4
Comments
|
Getting log4j going first, using the instructions in the BUILD-INFO.txt file in its source tree. Off the bat, the mvn build is failing. I'm running under Maven 3. This log4j project was written for Maven 2, per BUILD-INFO.txt. Trying Maven 2. Had to set $JAVA_HOME. Maven plugin error. Hmm. Does that mean that the repos for maven2 plugins are offline? Sigh. Going to http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/2.4.3/maven-surefire-plugin-2.4.3.pom in a browser, I get: That "more information" link says:
So hmm, I wonder where my maven2 is picking up the http link from? I don't see these maven repos listed in the pom.xml anywhere. Googling around, it doesn't seem like you can change maven2's central repo url; only add alternate repos. I tried doing this in the project pom.xml like this: But still getting download failures. Aha! I think it needs to be <pluginRepositories>
<pluginRepository>
<id>maven-central-https</id>
<url>https://repo1.maven.org/maven2</url>
</pluginRepository>
<pluginRepository>
<id>apache-maven-https</id>
<url>https://repo.maven.apache.org/maven2</url>
</pluginRepository>
</pluginRepositories>The build is still failing, but it seems to be getting through the Maven plugin download steps and getting much further now. |
apjanke
changed the title
|
The maven-repository.dev.java.net Maven repo is dead. The whole java.net site closed down in 2016 or 2017. Thanks Oracle. Looks like these JARs were removed from some of the public Maven repos due to Java/Oracle licensing issues. References:
I could try to find another place they're hosted, or do the download-and-install-locally thing. Or it looks like maybe log4j 1.2.17 fixes this problem, and I could use that version instead? The official Oracle download site for these things looks like https://www.oracle.com/java/technologies/java-archive-downloads-java-plat-downloads.html now. I can't find an authoritative SHA sum for these JAR files so I can verify copies acquired from other sources. But I think I can just take the JARs from oracle.com as authoritative if I can find all of them. This Oracle "Getting Started with JMX" page says that JMX is included with Java starting with Java 5, so maybe it's not even needed now if I build against a newer JDK? Apache log4j 1.2.15 looks like it's targeting an ancient pre-Java-5 Java version: <plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.2</source>
<target>1.1</target>
</configuration>
</plugin>Here's some download locations I've found so far:
Okay, so those download sources all look good. That http://builds.archive.org/maven2/ repo looks interesting, too. I downloaded the JMX JARs from oracle.com and installed them in my local |
|
I tried to use a mirror in my But it didn't fully work. I'm still getting this. I deleted my local mvn2 repo and reran it, to get everything fresh. Similar issues, and even more of them now. I bet this is more stuff that was removed due to Java licensing issues but I had in my local maven2 repo. Oh wait, duh: the https versions of the central repo need to be in I'm left with the com.sun.jmx:jmxri:jar:1.2.1 and com.sun.jdmk:jmxtools:jar:1.2.1 errors. I haven't been able to find any public Maven repo where they're hosted. And I don't want to fiddle with the project definition. So I think I'll just go the route of manually downloading them and installing them in my local m2 repo. |
This was referenced Sep 10, 2022
|
Also needed JMS 1.1. I don't see a download for that on Oracle's site. (There's a JMS 1.0 on the J2EE download page, but that's the wrong version.) There's a JMS 1.1 JAR available in the JBoss Maven repo, so I'm going with that. JMS is Java Message Service. Build is getting much further now! |
|
Looks like the identifiers for maven plugins have changed since the time of log4j 1.2? The artifactId for the JXR plugin is different, and they're now under group org.apache.maven.plugins instead of org.codehaus.mojo. I updated the references in the pom.xml to what I think are the current plugin identifiers, and added version specifiers to grab the latest version of each that supports Maven 2. |
|
Okay, now what's causing this? The I bumped maven-project-info-reports-plugin to version 2.9, the last version that supports Maven 2. Same error. Here's some debug output. Okay, so that's in the "Dependencies" report. I think that's requested by this in the pom.xml. I don't see much else useful to me in that debug output. And I don't want to dig in to the source code to firgure out exactly where that ArrayIndexOutOfBoundsException is happening in the plugin implementation. Let's try to clean up these warnings and see if that helps. I tried this "add I tweaked my pluginRepositories settings. Now I'm getting this: Which I think means that it is finding maven-default-skin on maven-apache-https, and that warning about central can be ignored, and this is a red herring for the dependency report. I was able to find some other coders on the web with similar maven-project-info-reports-plugin/doxia ArrayIndexOutOfBoundsException issues:
No actual solutions there, though. I tried using earlier versions of maven-project-info-reports-plugin going back to v2.2 and they all had the same error. Tried 2.1.2, and it worked! Got another dependency error, then. That looks unrelated, so I'm going to stick with the older version and work this next bug out. |
|
Next up, this build failure about a missing sun.jdk:tools:jar:1.4.2 dependency. Aha: log4j 1.2 is old enough that it was using the old Apple-distributed JDK paths in its configuration. In pom.xml, in On to the next issue. |
|
Next up: a Java linkage error in org.codehaus.plexus.component.configurator.BasicComponentConfigurator, used by org.apache.maven.plugins:maven-antrun-plugin:1.3. I bet this antrun plugin or something it's using is too out of date to work with Java 8. Setting the maven-antrun-plugin to version 1.8 got rid of that error, but now I've got this: The next maven-antrun-plugin version after 1.8 is 3.0.0, and that requires Maven 3, so can't upgrade further to try to fix this. The ant FileUtils Javadoc says getFileUtils was introduced in ant 1.6.3. The pom.xml here seems to be using ant 1.6.5. But maybe a further bump will help? Upgrading ant to version 1.7.1 seemed to fix it. Now I've got this regexp "opp/opp-munged/apache-log4j-1.2.15/target/site/apidocs does not exist" error. A Seems like that shouldn't be necessary. I'm guessing a build task dependency here is missing. But I might just overlook this for now. Here's the task definition for later reference. |
|
Next: a test failure: "MinimumTestCase failed around Ant part ...". Oh wait, I think that's a red herring: looks like that test was to make sure that log4j did produce an error when presented with a bad escape. Here's what I think is the actual junit test error: Hmm. That "10 Sep 2022 19:37:10,797 [main] FATAL ERR - Message 0" is what's being produced by log4j running under the test harness in my environment. It's the ControlFilter that's throwing the exception. It has a list of patterns: That comment makes me think that one of the TTCC_PATs was intended to match this. Hmm. Oh, look: in Filter.java: It's using "200\d" as its pattern for 4-digit years. Hahahaha; did this break a decade ago? Yep: I changed it to "20\d\d" and this test started passing. On to the next test failure. |
|
Let's get rid of this "multiple versions of ant" warning: These look relevant:
I deleted my local Maven repo with Clue: The paths are different: Aha! The ant-contrib 1.0b3 package has a dependency on ant:ant 1.5. Looks like development of ant-contrib stalled out in 2006, the 1.0b3 beta release was their last release. There's still some activity on their mailing list but it seems to consist mostly of "ant-contrib works fine as is" responses from the maintainer. So can't fix this by bumping to a newer ant-contrib release. Let's see if I can just remove the dependency. I commented it out, the "multiple versions" warnings went away and nothing seemed to break; I'm getting to the same test failure as I was before. On to the next test failure for now. |
|
PatternLayoutTestCase is erroring. That smells a lot like the earlier Y2010 failure. Maybe I don't have fresh class definitions? Had to do a And now all the tests pass. That makes sense: those pattern strings in Filter.java in the main code are Would be best if the main |
|
Okay, good.
An The |
|
Oof da. Big ol' error in the javadocs portion of 66 occurrences. I think I'll just fix them up to Java 8/HTML 4 conformance. It'll be a bit of drudgery, but they should all be easy fixes. And that'll probably work better in the long run than doing See: Stephen Colebourne's comments on the Java 8 javadoc HTML strictness. |
|
I modified the |
|
Okay, now we've got an error creating the jar. Looks like it's an issue with naming inconsistencies from my changes to make it clear that this was the Janklab-munged version of the library. Ah, yep, looks like I got over-eager here, and then decided to put the janklab indicator in the version number, not as a prefix to the JAR file name. Switched that back, and it fixed. Now I'm getting this: NTEventLogAppender.dll is in the root dir of the project. I tried adding this to the maven-antrun-executions element in pom.xml But that seemed to have no effect. Between this project's complicated use of both Maven and ant, and my own mediocre skills with Maven, I can't figure out how to make "copy file A to location B" happen as part of this Maven build. For now, I'm working around it with a manual copy to This is a tiresome enough process that I think I'm going to switch to giving log4j 1.2.17 a go; from its changelong, it seems to have a bunch of build-oriented fixes. |
apjanke
changed the title
|
WTF? I rebooted my machine, and now my maven-antrun target to copy NTEventLogAppender.dll to |
|
Got some warnings in the tar packaging step now, mostly about file name length > 100 characters. They're hitting 115 characters, and my suffics to the project name is less than 16 characters, so I don't think that's what's pushing them over the limit here. I suspect this behavior was present in the original log4j, and people lived with it because GNU tar is so common. ("Resulting tar file can only be processed successfully by GNU compatible tar commands" in the warnings.) Or maybe that message is misleading, and other modern tars can handle it, and they are "GNU compatible". And I don't actually need the |
|
A whole lot of doclint warnings in the apidoc building step. I don't like that warning spam in the build step, but it's really of no consequence, so I'm not going to worry about this now. Going to focus on building a munged log4j 1.2.17 instead. |
|
Something to think about: When doing big experimental WIP like this, maybe I should do it on a separate fork/clone of the main repo, instead of just a branch on the primary repo. I'm afraid that all these upstream library files I'm pulling in are going to end up inflating the main repo size even if I do some rebasing and branch deletion before merging to master. In git, nothing ever really goes away once it's committed, right? These Or maybe this is unrelated, and just another one of those Linux development tool and networking configuration things I need to sort out. Maybe my git-credential-manager-core (now called just "git-credential-manager" in branding terms, I think?) is out of date? That's not supplied with Git or as part of MacPorts. I'm on 2.0.567, and it's up to 2.0.785 now. I can't tell how I got this binary installed. I'm running MacPorts and not Homebrew on this Mac, because I'm still on macOS 10.14. I guess I just downloaded and ran the GitCredentialmanager I downloaded Tried doing a git push again. And this time it ran fine. There's a new |
|
The 1.2.17 build modernization is going pretty smoothly. Mostly repeating the stuff I did for 1.2.15, and I'm able to skip some stuff too, because 1.2.17 is years newer, and runs against newer Maven plugins and whatnot. Now I'm hitting a test failure in XMLLayoutTestCase: |
|
I've got log4j 1.2.17 building now, and am cleaning up javadoc doclint warnings. I've fixed a bunch of them, but they just keep coming. Oh no: Is the warning output limited to 100 warnings here, and there are actually a lot more of them hiding in the code? Rats. |
|
If you get this mvn build error about a missing Sun That might just mean that your This also means that this mechanism might be picking up the wrong version of the tools.jar file, if your Do this on macOS in the shell where you're doing your |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This ticket is for building the "munged" SLF4J and log4j libraries that will ship with SLF4M to support newer Matlab versions. Blocks janklab/SLF4M#7, janklab/SLF4M#15.
Work is on branch
WIP/log4j2. NOTE: Because this is a "WIP" branch, I may be rebasing, squashing, and rewriting history on this branch at any time. You'll need to frequently delete your local tracking branch and check it out again if you're following along here. (This branch was imported from the old branchWIP/munged-java-libs-for-R2021ain the main SLF4M repo.I'm getting log4j 1.2.15 going first.
Questions
IDEA! Can I create just a munged SLF4J 1.5 library, have it bind to the real log4j 1.x, and ship the real log4j 1.x? log4j 1.x and 2.x have different package names; maybe they can both run in the same JVM program. Hmm, let's try that. UPDATE: Rats, I think No: Matlab is shipping the log4j 1.x-to-2.x bridge JAR, which consumes the log4j 1.x package namespace.
Plans (Summary)
TODO
Subtasks
ant cleanalso clean the tests/ subdir #3The text was updated successfully, but these errors were encountered: