The POM files of the companions project have problems: * they state they are using 1.2 as the compile version, but they are using classes from 1.4+ (e.g. XML DOM classes); * the "assembly" goal is not connected to a phase (I suppose that it is "package" * project "apache-log4j-receivers" depend on log4j 1.2.16-SNAPSHOT, while version 1.2.15 is enough.
Created attachment 24050 [details] Patch for the "apache-log4j-component" project
Created attachment 24051 [details] Patch for the "apache-log4j-extras" project
Created attachment 24052 [details] Patch for the "apache-log4j-receivers" project
Fix committed to svn trunk in r821364
Sorry, I thought I had commented on this on the mailing list. javax.xml.parsers was available for earlier JDK's as an additional component. The source and target parameters on a Java compiler do not indicate the version of JDK necessary to build the component, they specify the version of the Java language specification accepted and the version of the Java byte-code emitted. There are specific reasons why 1.1 was chose for byte-code and 1.2 was selected for source. Those choices were made a long time ago and maybe the should be review but the post did indicate any specific problem that occurred due to that choice or advantage that would be gained by changing the versions. As deep in the maintenance cycle as log4j 1.2 is, it seems unwise to make changes for no defined benefit.
I must admit that the compilation problem appears only in Eclipse, because, when choosing a runtime environment, it enforces restrictions in class use. In this case, if I have a 1.2 version of JDK, I cannot use XML classes. Usually this is not an issue, but probably, since Eclipse is OSGi based, this can cause a problem under OSGi-based applications (never tested it, though). Anyway I don't see why it is a problem to "upgrade" the companions, Java 1.2 is abandoned, Java 5 is at the end-of-life, Java 1.4 seems "reasonably old" :-D
Good to know the problem you were trying to fix. Is this observed with Eclipse projects that are generated with "mvn eclipse:eclipse", with projects that Eclipse reads directly or is it using Maven with the Eclipse java compiler? Leaving the byte-code at 1.1 allows us to binary diff the generated classes with earlier versions of log4j 1.2 to determine that we didn't make inadvertent changes between versions. That is an auditing step that we could still do by rolling back the target, but it is an extra annoyance and it is a nice check for something as widely deployed as log4j. The assert keyword was added in the Java language at 1.4. I'm not sure if that required upgrading the byte-code version to 1.4 also. Could you try just upgrading the source to 1.4 and see if that eliminates your issue with Eclipse. Updating source to 1.5 definitely requires updating the byte-code to 1.5 since there are productions that can not be generated using 1.1 byte code.
I use m2eclipse plugin, so it's a Maven inside Eclipse. It's a strange situation, now everything works fine, with the exception of an error in the properties of the project, as Eclipse (Galileo) does not list 1.2 version as possible value of the Java source :-O Anyway, it compiles. So, I think the source/target levels can be restored to original values. About the asserts, what are you referring to? I don't see any assert inside the companion code.
We are using the Apache parent pom meanwhile and have merged the components to a single jar. Therefore I am closing this issue as described problems should not longer occur. Thanks!