Community
Participate
Working Groups
Env: Rational Application Developer v6.0 AJDT build: 1.2.1.20050623150852 FYI: We have the "build automatically" feature off (we build our projects whenever we think is appropriate). I am including an EAR file that you guys can import into the RAD workspace to reproduce the problem. It contains two projects: BuildEAR and BuildWEB. You can use the BuildWEB project to reproduce the problems described below. This problem is related to another bug I just reported (bug id=101481). The following works as expected when the project has just a WEB nature (does not have ASPECTJ nature): If you build BuildWEB (select the project and then 'Project->Build Project'), and it results in Java compilation error(s), the build process still copies all of the the resource files in the source folder (e.g., .properties, .xml) to the WEB-INF/classes folder. Resource files are copied to the output folder (in this case, the classes folder under the web-inf folder) whenever you select to build a project (regardless of having compilation errors). However, if you convert the BuildWEB project to ASPECT nature, then above functionality is lost: If you build a project and it results in Java compilation errors, then resource files (e.g., .properties, .xml) are not copied over to the output folder. To reproduce the problem, you can do a "clean" (select the project and then 'Project->Clean...'), and then build the project. You have to do the "clean" while the project does not have the APSECTJ nature ("clean" does not work as it should if the project has ASPECTJ nature, see bug id=101481). Once the project has the ASPECTJ nature, introduce a syntax error in the TestServlet.java class. Then build the project and then 'Refresh' the project (you have to "Refresh" the project in order to see the files that were copied over to the WEB-INF/classes folder, see bug id=101481). Once the project is bulit, you should see that in the WEB-INF/classes folder, the resource files (test.properties) are not found. However, if the project does not have the ASPECTJ nature, you can do a clean, build the project, and then you will find the resource files in the WEB-INF/classes folder.
Created attachment 23874 [details] web project to reproduce problem
Hi Ricardo, The reason the resources are not being copied over is that in our build method we have the following: IResourceDelta dta = getDelta(getProject()); // copy over any new resources (bug 78579) if(dta != null) { copyResources(javaProject,dta); } to copy over the resources. However, in the case you describe, the delta is null so we don't copy them over. If we want to mirror how the javabuilder works, then we should remove this check. Thanks, Helen
Hi Helen, Thanks for the information and for providing fixes for the problems I have run into. As for this one, do you know if the decision is to mirror how the javabuilder works or is this something you guys haven't talked about it yet? I would think mirroring how the javabuilder works is what most users would expect but maybe there are other reasons for not doing so that I have not thought about.
Hi Ricardo, Yes, I've been thinking about this bug.......and there are two differences between java and aspectj. Firstly, like you say in this bug, we (AJDT) do not copy over the resources (.txt, .properties files etc) to the output directory when there are compilation errors. Secondly, when faced with compilation errors, java (or the jdt) tries to make the best of it and creates a .class file, whereas aspectj doesn't. The second is a compiler issue, but not one I believe is a high priority because if there are compilation problems you need to fix these before you can run the program/application anyway. The first is an AJDT issue, however, I again don't believe it is a high priority (unless there's a use case I'm missing :-)). It's a non trivial task to copy over the resources regardless of whether there are compilation errors (my comment #2 was a bit hasty :-) as the non-null delta is used in the copyResources(..) method). However, I do agree that mirroring the way the javabuilder works is a good model to follow, and consequently this bug should be fixed. I've therefore downgraded the severity of this bug to be normal (as opposed to major). Please let me know if there is a reason you need the resources copied over to the output directory if there is are compilation errors and I'll change the focus on this bug accordingly. Thanks, Helen
Hello Helen, Thanks for sharing your thoughts. Actually, as I was submitting this bug report I thought it could be reasonable to say that the developer should fix the compilation errors before moving on. However, this is our situation, which I think is not that particular. We are currently developing a quick prototype that has two main components: component A calls methods on the interface of component B. Two different people are developing each one of these components. The person working on component B made a few changes to its interface, which, of course, then “broke” component A (the signature of the methods in the interface of component B changed). However, to perform testing on component B (e.g., using junit and cactus), component A is not required. In order to perform these tests, we need to compile the project (which contains both components, A and B) even though component A is “broken”. This would require both: resource files are copied over to the output folder and .class files are created for those classes that do not have compilation errors. Having this would allow the person working on component B to build the project and test the changes even though there are compilation errors in component A.
Hi Ricardo, There's now a bug against AspectJ (bug 102733) to cover the differences in compiler (that the jdt produces classes even though there are compilation errors whereas ajc doesn't). The AJDT side will be covered by this bug. Given your scenario - what severity would you place on this bug? Are you happy with it being "normal"? Thanks, Helen
Hi Helen, That’s good news. So, bug 102733 covers only the generation of the .class files while bug 101489 covers copying resource files over (since this is not compiler issue but an AJDT issue) to the output folder, correct? Given the scenario I’ve described, I would have the severity of these two bugs as ‘major’. I would not consider them as a blocking defect since we have “work arounds” for the issue. However, one concern is that most people out there, I would think, are going to expect ajc and ajdt behave as the java compiler does. It took us a few hours to figure out what was going on when we started getting exceptions when testing component B (initially we thought we had broken our code after making the changes to component B). Also, it lowers our productivity having to do “work arounds” in order to make it work instead of just letting ajc and ajdt take care of it.
returning this to AJDT-inbox - still waiting on the resolution of AJ bug 102733.
Created attachment 29694 [details] patch containing testcase apply this patch to the org.aspectj.ajdt.core.tests project. This patch contains a testcase which produces the problem.
apply testcase and take it from there
Applied test and it is still not working. I think the problem is that the files are not marked as "derived". If all files generated during build were marked as derived, then it would be very easy to go through and delete them when necessary.
Created attachment 106734 [details] Remove resources marked as derived on project clean Attaching a patch that gets the AJBuilder to remove all resources marked as derived in the out folder when a clean is requested. Also including the test case.
Oh and this bug has nothing to do with AspectJ bug 102733.
patches committed. iplog. not going to be backported to an AJDT for RAD 7.0 or earlier though.
