Announcement Announcement Module
No announcement yet.
Compile Errors in Airline Sample If No User Libraries Created Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Compile Errors in Airline Sample If No User Libraries Created

    Hi, everyone.

    Although I have the airline sample running ok in Eclipse, in order to get it to compile without error, I had to create "User Libraries" (Eclipse terminology).
    These were the same jars that Ivy moves into the global "cache" (i.e. ${build.dir}/lib/global, i.e. they are redundant, and I hope unnecessary.

    I would like now, to be able to compile using just the supplied ant/ivy build files, i.e. without having to create the redundant Eclipse User Libraries. However, if I remove the User Libraries from my Eclipse Airline project, the build (compile.source target in common-targets.xml) fails with compile errors, indicating that it can't find the third-party jars (such as those from Spring, Apache, etc.). Actually, it's the Eclipse Problems screen that complains more than the build output, saying things like:

    "The project was not built since its build path is incomplete. Cannot find the class file for org.apache.commons.logging.Log. Fix the build path then try building this project"

    I suspect that the javac can't see the compile.classpath refid, but it seems like it should, i.e. the common-targets.xml compile.source looks ok to me.

    Is there some trick to get this build to work without having to create the redundant User Libraries in Eclipse?


  • #2
    More info/discovery:

    I think the problem is in Eclipse's internal "build" mechanism, i.e. I was legitimately missing a jar that the ant build needed in the classpath. With that fixed, I now get a clean ANT build....but Eclipse still thinks the project has build errors, probably left over from when I did an Eclipse project "build" one time.

    I've tried the Eclipse "Refresh" on the project, but that had no effect.

    How do I get Eclipse to recognized the results of the ant build? I mean, after all, I ran the ant build in Eclipse, not outside of it.

    Obviously, this is turning into an Eclipse/ant problem, not a Spring problem, but I'll bet that most Spring developers are using Eclipse in one form or another...If not, maybe I should be evaluating yet another IDE



    • #3

      Hey Ben - is your eclipse output directory the same as the directory ant is building too? If not, that could be your problem.
      ... Rich


      • #4
        Good thought, but this one's about the third-party jars, so I think the answer lies elsewhere.



        • #5
          More info/discovery:

          Ok, even though ant SAYS the javac and the build went ok (i.e. "BUILD SUCCESSFUL" and no obvious in "Don't worry, Charlie Brown, I won't pull the football away this time ) when I deployed to tomcat, tomcat choked on it with essentially the same errors as Eclipse...yes, Eclipse, not ant build:

          Constructor threw
           exception; nested exception is java.lang.Error: Unresolved compilation problems
                  The import javax.xml.bind cannot be resolved
                  The import javax.xml.bind cannot be resolved
                  The import org.joda cannot be resolved
                  The import org.joda cannot be resolved
                  The import org.springframework cannot be resolved
                  AbstractMarshallingPayloadEndpoint cannot be resolved to a type
                  JAXBContext cannot be resolved to a type
                  JAXBContext cannot be resolved
                  Marshaller cannot be resolved to a type
                  ...and so on...
          Somehow ant is still not correctly building in Eclipse unless I create the Eclipse-specific "User Libraries" and add then to the project's build path...which is wierd. I mean, why would ant/tomcat care about anything that Eclipse-specific? I must be missing something else about the classpath. (Yes, the build put the jars in the war in the correct spot, as it has done all along, i.e. even back when it was working ok, so this is not about the jars just not being in the war lib dir.)