1

I have a peculiar situation.

At one instant, I needed to branch, so I made a copy of my eclipse workspace and began working on two (2) parallel versions of the same project.

Development is done on a Windows workstation. For testing purposes, the application is deployed onto a Linux server.

If I run mvn jetty:run or mvn clean compile for either project on the Windows workstation, everything works fine. The projects use identical pom.xml so there is no difference.

However, if I transfer the source code onto the Linux server, only old branch compiles 100% and the new branch compiles something like 45% meaning if I run it, it will give quite many complaints of ClassNotFoundException...

The strange part is that:

  • both projects are practically identical, copies of each other, 98%
  • encoding UTF8 for Java, no strange non-alphabet filenames
  • mvn compiles without error, it says "BUILD SUCCESSFUL" on both projects
  • however, after compilation looking into the target/classes of the newer project, there are .class files missing for which there are .java files in its respective src/main/java/ path
  • I have tried javac with verbose and nowarn and such parameters, no difference
  • jdk 1.6_33

Is very confusing. Now what I have to do is compile the source on Windows workstation and copy the target/classes contents onto the Linux server, but seems really unnecessary. The only thing that comes into my mind is that the newer version is using some heavy bleeding-edge-generics, but if that would hurt I would assume that a) same result on Windows as Linux, b) some error message. But nothing, just "BUILD SUCCESSFUL" with lots of missing .class files.

Any ideas? Woodoo?

Here is some update to the issue: It began to occur on Windows also (magically not compiling significant portion of java files without any error indication) and then I simply took a DIFF between the recently compiling version and the later non compiling version. Diff was easy because only a few changes. I found out that I had a java file of size approx 600k (lots of inline data initialization etc.) which seemed to make the difference. I split this particular java file into 2 pieces (original into 109k and helper into 567k). Now it compiles again for Windows and I will probably continue looking for other such big files or splitting this one further to see if it will start to compile on Linux also!

Martin
  • 1,385
  • 15
  • 21
  • 2
    Can you add the maven output? Maybe with `-e` and `-X` switched on. You might need to trim the output to be relevant to your post. – Paul Grime Jun 13 '12 at 09:24
  • 1
    bleeding-edge-generics - in Java 6? – artbristol Jun 13 '12 at 09:31
  • 1
    Compare the maven output - especially look for lines `compiling xx java files` and see if they are different. Possibly you have java classes in the second version outside `src/main/java`. – Raghuram Jun 13 '12 at 09:46
  • 1
    Run `mvn clean install -e -X > build.log` for each of the projects then go through both outputs and try spotting the differences. There's going to be an indicator somewhere in the projects that doesn't compile properly. Generics would have little to do with this. So would the encoding (although it's excellent that you've set it). – carlspring Jun 13 '12 at 13:18
  • Your mention of generics reminded me of something that got me once. When compiling on the Windows box, are you using the Eclipse compiler? If yes then [this stackoverflow Q&A](http://stackoverflow.com/questions/314572/bug-in-eclipse-compiler-or-in-javac) may apply. – user944849 Jun 13 '12 at 13:46
  • @PaulGrime There is nothing of interest in the maven output. The project is huge so I will not post it here... I have tried all debug -e and -x etc. it is simply listing the classes being loaded/parsed but no error messages. – Martin Jun 13 '12 at 17:17
  • @DaveNewton That's exactly my problem ;) There seems to be nothing to tackle... except if someone has had similar experience and found the magic wand? – Martin Jun 13 '12 at 17:18
  • @Martin, you don't find magic wands here I'm afraid. Just people who are willing to help *if* they have some evidence to work with. Not just 'my project doesn't work' :) Need traces! – Paul Grime Jun 13 '12 at 17:19
  • @Raghuram No, I don't have files outside src/main/java because it compiles fine on Windows and zipping the same set of files and unzipping it on Linux gives different results for two almost identical projects. Note 98% files are same but only 45% compiles in the new project. No error messages. – Martin Jun 13 '12 at 17:20
  • @carlspring Yes I have done this, the only difference is the files but there is no indicator of WHY a different set of files is compiled. It seems that the javac simply ignores some files... without error message even with javac debug mode. – Martin Jun 13 '12 at 17:21
  • @user944849 On windows I can compile both WITH and WITHOUT Eclipse no problem. I have cast many Generics like follows: ((T) ((Object) o)).invokeMethodFromT(); because it does not accept casting directly to T. Would allow in eclipse but not javac. But on windows this works ok. – Martin Jun 13 '12 at 17:22
  • Does your POM include hardcoded pathnames somewhere, such that .class files are being added to the other project's (old branch) target/classes directory? Quick way to check is to do a `mvn clean compile` for the newer branch and look at the timestamps in the older branch. – user944849 Jun 13 '12 at 17:28
  • @user944849 No hardcoded pathnames in pom. `Pom` is a schoolbook example, dependencies, repo, nothing more. – Martin Jun 13 '12 at 19:53
  • Well, if would post your pom files and show us how your directories are structured, we could probably help you better. – carlspring Jun 14 '12 at 08:01
  • Yeah, I'd like to see the pom, especially the `maven-compiler-plugin` config. – artbristol Jun 14 '12 at 11:37
  • @carlspring @artbristol Luckily, `pom` was not the issue as it was identical in both cases ;) – Martin Jun 15 '12 at 00:28
  • ` maven-compiler-plugin 1.6 1.6 utf8 -implicit:class ` Those additional arguments are something I have tried out in hope to make it work... standard arguments would be `source, target, encoding`. – Martin Jun 17 '12 at 23:30
  • Most of the times when I take code from Windows and put it on Unix, the reason for crazy errors is ^M characters in some of my files... Just something to try out, run dos2unix on all files and then try compiling – gresdiplitude Jun 14 '12 at 11:24

1 Answers1

1

The problem was eventually fixed by itself when we upgraded to JDK 7.

Mysterious.

Martin
  • 1,385
  • 15
  • 21