Community
Participate
Working Groups
Problem occurs in the headless F3 workbench. I know that projects with cyclic dependencies are not normally supported, so I set the java builder options // Ignore 'invalid' classpaths, so we can deploy beans with cyclic dependencies javaOptions.put(JavaCore.CORE_JAVA_BUILD_INVALID_CLASSPATH, JavaCore.IGNORE); The structure works in most cases, but I have a test case that fails. The error messages are: Building project: /RetireEJB. [*Error] /RetireEJB: The project was not built since its classpath is incomplete. Can not find the class file for com.ibm.wssvt.tc.pli.data.PersonData. Fix the classpath then try rebuilding this project [*Error] ejbModule/com/ibm/wssvt/tc/pli/ejb/EJSCMPBasePersonHomeBean.java(0): This compilation unit indirectly references the missing type com.ibm.wssvt.tc.pli.data.PersonData (typically some required class file is referencing a type outside the classpath) Shutting down workbench. Execution Halted: Compilation Errors Reported 2 Errors, 56 Warnings, 0 Informational Messages > >Note that PersonData.class does exist, in the PersonEJB project > >dir PersonData.class /s/b PersonEJB\ejbModule\com\ibm\wssvt\tc\pli\data\PersonData.class > >And that the PersonEJB project is in the classpath of the RetireEJB project > >type RetireEJB\.classpath <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path="ejbModule"/> <classpathentry exported="true" kind="lib" path="imported_classes"/> <classpathentry exported="true" kind="src" path="/PersonEJB"/> <classpathentry exported="true" kind="src" path="/PolicyEJB"/> ...
About the same time as we added support for aborting the build in presence of classpath inconsistencies, we also changed the builder behavior so that it refuses building projects for which any of its prereq projects failed to build before. The reason for this is that in presence of such issues, we used to be reported about 30.000 errors for an Eclipse full source workspace, which is just too many errors for anybody to handle (first being the task list). With the new behavior, the error count is fairly small. Mutual dependencies are clearly causing you some grief, since they induce unbound references in classfiles. Note that the check for presence of a built state isn't configurable. We could make it optional so as to allow building your test case, but Eclipse in general is not meant to deal with build cycles. Indeed, each project builder gets activated exactly once in a build iteration. I recommend changing the test, to use one project and 2 source folders instead. If you need this setting to be configurable, then please let us know, this also require some UI action (for surfacing this information to the end user in the compiler preferences). CC'ing Erich since he may be involved. Alternatively, we could make this simply a JDT/Core option, which could be set only programmatically.
May consider for F4
One possible solution for minimizing changes would be to only check for presence of built state when the classpath check is done (if abort on classpath issue is enabled).
Actually, the current implementation only checks for prereq built states, if abort build setting is enabled. So this must be something else. Tim - can you please provide a test case for investigation ? The missing classfile may be existing in the end, but not at the time /RetireEJB is built. Does an incremental build at the end fixes the problem ? Did this scenario work in F3 ?
Did it work with F2 ?
Removing F4 milestone until further information is provided.
Deferring until more info is provided.
When I looked at the .classpath file for the PersonEJB project in the example I noticed that "ejbModule" folder was marked as the output folder for the project. However, there is no source folder for PersonEJB, so if the compiler ever decides that it wants to scrub the output folder (which it can do any time) it will delete PersonData.class. Later if it needs PersonData.class, it has no way of regenerating it from source. I believe that the example provided should mark ejbModule as a lib classpath entry (i.e. <classpathentry kind="lib" path="ejbModule"/>) instead of marking it as the output folder. This should allievate the problem. Tim, could you please test this? Philippe, does this make sense to you? Also, could this example be exposing an ImageBuilder + cyclic dependencies bug which causes the compiler to scrub the output folders too many times?
Reopening
*** Bug 27770 has been marked as a duplicate of this bug. ***
*** Bug 24832 has been marked as a duplicate of this bug. ***
Fixed, thanks to build manager looping behavior addition (combined with our Java builder explicitely asking for another build iteration, in presence of cycles. Subsequent iterations are always incremental).
Verified.
