Community
Participate
Working Groups
Created attachment 92898 [details] sample project Build ID: M20080221-1800 Steps To Reproduce: 1. Open attached project and build it 2. Check contents of the bin directory 3. C1.class should be in bin/output1 and C2.class should be in bin/output2, but they both are in bin/default More information: Using AJDT 1.5.1 (not available in Version drop-down at time of writing) on Eclipse 3.3.2. Project description: - class C1 is in src1, which builds to bin/output1 - class C2 is in src2, which builds to bin/output2 - project default output folder is bin/default If you can't reproduce at first, try manually deleting the bin directory, then refreshing/cleaning in Eclipse.
peculiar.... I recreated this at AJDT 1.5.1 - then I installed the latest dev build of 1.5.2 and it still happened. Then I tried it with HEAD ajdt (which should be the same as 1.5.2 dev build) and it works fine, correctly respecting both output locations. I have triggered another dev build of 1.5.2 to see if that addresses this. you might want to try 1.5.2 to see if behaves for you
HI! I see the same issue with eclipse 3.4M5 and ajdt 1.5.2.200803131753. We see this issue for the classes in src/test/java which is built into target/classes even though we have the following in out .classpath (generated with mvn eclipse:eclipse): <classpathentry kind="src" path="src/test/java" output="target/test-classes"/> I have put a screenshot of the plugins I have installed in eclipse at http://folk.uio.no/kajh/tmp/ajdt-223184.png I'm on MacOS X 10.5.2 and java 1.5.0_13. -Kaj :)
double check this with latest
I have now testet with ajdt 1.5.3.200805101430 on eclipse 3.3.2 and cannot reproduce this issue with the sample project attached to this issue 2008-03-19. But... I still see this issue in one of my real life projects. I'm trying to isolate the problem and create a testcase to reproduce the problem. I havn't had any luck so far but I'm not giving up :) I found a similar issue at https://bugs.eclipse.org/bugs/show_bug.cgi?id=160846 It would be very interesting to know if anyone else have a similar problem to the one described in this issue or in issue #160846.
(In reply to comment #4) > But... I still see this issue in one of my real life projects. I'm trying to > isolate the problem and create a testcase to reproduce the problem. I havn't > had any luck so far but I'm not giving up :) The .classpath file I'm using (generated by maven2) is available at http://folk.uio.no/kajh/tmp/ajdt-223184-classpath.txt
I can't reproduce this either. Kaj, if you can be a little more specific with the problem you are having, I'll take a look at it.
(In reply to comment #2) > I see the same issue with eclipse 3.4M5 and ajdt 1.5.2.200803131753. Unfortunately, AJDT 1.5 is not compatible with Eclipse 3.4. AJDT 1.6 is required, but it is not yet in a stable state.
I see "my" issue with eclipse 3.3.2 and AJDT 1.5.3.200805101430 too. In short it is the the output attribute for a src folder in the .classpath file isn't honored and eclipse use the default output folder spesificed in the .classpth file when it builds. You can see my .classpath file at http://folk.uio.no/kajh/tmp/ajdt-223184-classpath.txt. This .classpath file is generated by mvn eclipse:eclipse. I would expect files in src/test/java to be built to target/test-classes but they are built to target/classes. Thank you for looking into this issue!
Weird... I can still reproduce the original bug (sample project) with the following: Eclipse Version: 3.3.2 Build id: M20080221-1800 AJDT Version: 1.5.3.200805131655 AspectJ version: 1.6.1.20080513130000 Remember, if you cannot reproduce the issue, try deleting the bin directory from Windows Explorer, then refresh in Eclipse and clean project. I just did and both .class files ended up in bin/default.
Tried this once again and I still can't reproduce. The compilation is completing properly, even if I delete the bin folder from outside eclipse. I am on a mac and so this may be (although unlikely) the issue. I will check on a PC. Some suggestions/questions: 1. does this work if you specify only one non-default output folder? 2. does this work properly if you remove the AspectJ nature? 3. could there be interference with some other plugins/projects? Perhaps try closing all other projects and disabling any 3rd party plugins (except AJDT).
Tested again, sample project uploaded by me now works (no idea what was going wrong or when the problem got fixed, sorry). But I still have the same problem as Kaj reported (which was the original problem I was trying to build a minimal test case for). I'm not using eclipse:eclipse but m2eclipse, which generates a similar .classpath.
Hmmm...it could be a Maven issue. Are you able to reproduce this with your maven plugin turned off?
Hi! I can reproduce this issue in my "real life" :) project with eclipse 3.4RC4 and org.eclipse.ajdt_1.6.0.200806131230. After I remove the target folder from shell (outside eclipse), do a refresh in eclipse and then a clean in eclipse to trigger a build, all classes ends up in classes. test-classes is not even created. My .classpath is generated by mvn eclipse:eclipse and contains the following line: <classpathentry kind="src" path="src/test/java" output="target/test-classes"/> I can make the source for this project privatly available if someone want to take a look at it. Just give me an email address if someone want a url for the zip-ed sourecode. -Kaj :)
(In reply to comment #13) > I can reproduce this issue in my "real life" :) project with eclipse 3.4RC4 and > org.eclipse.ajdt_1.6.0.200806131230. I see this issue with eclipse 3.4 (relase) and ajdt 1.6.0.200806271302. -Kaj :)
*** Bug 166291 has been marked as a duplicate of this bug. ***
Sébastien, can you too reproduce this issue with eclipse 3.4? Have you tried to reproduce it without m2eclipse?
(In reply to comment #16) Sorry, I have now switched back to using eclipse:eclipse and the same Eclipse output folder for main and test classes, so I can't comment on this bug right now. The original bug is fixed, but more "real life" cases might still be broken.
Thanks for answering! Do you use the same folder for both classes and test-classes when you build a warfile too? If not, how do you make maven use a test-class folder when building a warfile and not when doing other thing link running tests? I use a property for setting the name of the output folder and have the following in my pom.xml: <testOutputDirectory>${project.build.directory}/${testOutputDirectory}</testOutputDirectory> ...but I'm looking for better solutions for this issue.
(In reply to comment #18) I use mvn eclipse:eclipse -DoutputDirectory=target-eclipse, which causes all classes compiled by Eclipse (both main and test) to go to the target-eclipse directory. This is ok because I only run unit tests from Eclipse, not the war (which is built my Maven the standard way and manually started in Tomcat). Definitely not perfect, but a workaround I can live with until we figure out a minimal test case for this bug.
Seems like this is still happening. A common theme is that you are both using a maven plugin for eclipse. Which one is it? Can you reproduce the bug if the maven plugin is disabled? Let me know which plugin it is. I can try to reproduce it myself.
Thanks for looking into this issue! I'm not using any maven plugin in eclipse. The only two things maven does for me regrding eclipse is 1) generating .project and .classpath with "mvn eclipse:eclipse" 2) filtering some resources like db.properties with username and password for the database with "mvn process-test-resources" so I can run my tests from eclipse. I think the plugin Sébastien is using is http://m2eclipse.codehaus.org/.
I have reproduced this issue with AJDT 1.6.1 and eclipse 3.4.1.
I have the same problem: Eclipse: Version: 3.4.1 Build id: M20080911-1700 O/S: Windows XP SP3 Java version: Sun JDK 1.6.0_11 AJDT: 1.6.3.20090122141228 M2Eclipse: 0.9.6.20080905-0917 I have a Java project with a Maven Project Nature and a pretty much standard Maven .classpath that looks like this: <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" output="target/classes" path="src/main/java"/> <classpathentry kind="src" output="target/test-classes" path="src/test/resources"/> <classpathentry kind="src" output="target/test-classes" path="src/test/java"/> <classpathentry kind="src" output="target/classes" path="src/main/resources"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> <classpathentry kind="con" path="org.eclipse.jdt.junit.JUNIT_CONTAINER/4"/> <classpathentry kind="con" path="org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER"/> <classpathentry kind="output" path="target/classes"/> </classpath> With this setup, Eclipse compiles classes in src/test/java to target/test-classes. If I then add the AspectJ Project Nature ("Convert to AspectJ project"), it rebuilds my project, placing test classes in target/classes. Removing the AspectJ nature recompiles the test classes back where they should be in target/test-classes.
Created attachment 124994 [details] AJDT Maven Project that does not exhibit this behavior (for me) I took another look at this problem. I have tried many times to recreate it, but have not been able to so far. I am attaching my latest attempt at recreation here. This project is behaving properly in my installation. I am using the same version of Eclipse and M2Eclipse, but a new AJ version. Can someone please import this attached project into their workspace and see if this bug is occurring for this project? If it is not occurring, then can you please try to modify it so that you can reproduce the problem? Attach it and I will look into it. thank you.
I would very much like to fix this problem as it has been around for a long time. Can someone who is still experiencing this problem download the second attachment and try it in their workspace? Let me know if this simple project also causes the same problem.
I can't reproduce this issue with your testproject. I took the project in which I have this issue and removed almost everyting :) I still see this issue in the stripped down version but I can't see any significant differences between your testproject and mine. I attach my project to this issue so you can give it a try.
Created attachment 128900 [details] Testproject to reproduce this issue
btw... in my testproject I both have tried mvn eclipse:eclipse and tried to copy .project and .classpath from your testproject with the same result.
Still can't reproduce (tried with and without m2eclipse). There must be some way that our configurations are different. Based on your previous comments, I see that you are also on Mac, so OS shouldn't be a factor here. Can you send me a list of all your plugins in your workspace? If you feel this is sensitive information, then you can send it to me directly. I do see the screenshot of the features that you have installed. You can try to disable all of them plugins except for AJDT (and maybe m2eclipse). It *could* be that one of these extras are somehow interfering with AJDT's build. Also please attach your .project file. Or check that it does *not* have the java builder in it (should only have ajBuilder). You can also play around with manually editing your .classpath file. If you add an output location for src/main/java, is it respected? What if you change the default output location? I'm really just grasping at straws here. And just trying to find any information that can help.
I could reproduce this bug with 3.5-M7 and the newest 1.7.0 ajdt build. Just checking if it is associated with an other bug of mine (see 275568) but this one is a different one. In my case every thing which should go to target/classes goes to target/test-classes and the other way round. I debugged the code and come to the following place: class CoreOutputLocationManager { ... File getOutputLocationForResource(File resource) { ... if (ind != -1) { String rest = fileName.substring(ind + projectName.length() + 1); for (Iterator iter = srcFolderToOutput.keySet().iterator(); iter.hasNext();) { String src = (String) iter.next(); if (rest.startsWith(src)) { // at this point every thing is ok, e.g src/main/java File out = (File) srcFolderToOutput.get(src); // at this point we get the wrong output folder, because under // the key src/main/java we found target/test-classes return out; } } } Please keep in mind this was teste on the newest 3.5-M7 and 1.7.0 without any maven stuff enabled/installed.
The CoreOutputLocationManager.StringLengthComparator makes the trouble. In the cases all output folders have a different lenth, it is ok. If there are output folders with same length, it returns 0, even if the two folders are not equal. We use the Comparator for the srcFolderToOutput. Therefore a source folder, which has the same length, as a previous added source folder, will overwrite the older one.
Thank you for finding the cause of a bug, but unfortunately, I do not believe this to be the cause of bug 223184. The bug that you describe has already been fixed in AJDT 1.6. I have just not yet ported it over to the 1.7 stream. Releasing another 1.7 is long overdue. I take care of it this week and the problem described in comments c30 and c31 should be fixed. I'll let you know when it is available.
Oh, I had a look on the code with 3.4.1 and the latest development build from 1.6.4 and I see the fix. By the way if you do a toString in the first case it would do a toString in the second case to -- just to do things in the same way during comparation. } else if (len1 == len2) { // then compare by text: return o1.toString().compareTo((String) o2); } I checked the problem with the given project. - both project in the workspace ==> ok - both project in a separated folder, then imported (not copied) ==> ok The problem comes up in the case I changed the name of one project in the .project file. It was now different than the folder. Now things are getting interesting. In this case the method getOutputLocationForResource in CoreOutputLocationManager has to do some tricky things to get the output folder from the complete path of the resource, currently processed. First it check if it could find the project name. If the project name in the .project file is different than the folder (where the project is located in the disk) it will fail to find the name and will check if there the resource has a relative path, starting with one of the source folder. This check will fail to and all classes and resources will go to the default folder. Next situation: in some maven projects one of the parent folders has the same name as the project folder. In this case the first search for the project name will find the first occurrence of the project name. then the look up for the source folder will fail, because we found the first name. In this case all classes and resources will go to the default output folder. This one could be the reason for the maven problem. At this point we can't search for the project name, because we do not know how many times it occurs in the path, nor we can search for the source folder substring for the same reason. At this point (with the currently available information) we have no chance to get the output folder for the given resource without defining some (nasty) constraints for the path structure of ADJT projects. My feeling is, that the resource (which we process) lost the information, to which source folder it belongs, on the way it is processed by ADJT. Interesting in this situation is, that the directories (packages) got to the correct output folder (and to the default folder). How do they find the way to the correct output folder, probably the classes and resources should go the same way. My used versions: Eclipse: 3.4.2 Build id: M20090211-1700 AJDT: 1.6.5.20090507194818 AspectJ version: 1.6.5.20090430151200
Last week I used some folders, which where in a linked resource as sources folder. This works fine with a 3.4.2 and JDT. Currently I do not know the getOutputLocationForResource will figure out the output folder of source folders which are in a linked resource.
I raised bug 275903 to deal with c33. Please add all further comments on the problem discussed in c33 in the new bug report.
Is it possible that bug 275903 really covers the same issue as this one? I went back and tried the third attachment. It seems that the project name is different from its location on disk. As described in bug 275903, this causes erratic behavior similar to what is described here. I am downgrading the severity of this bug here because it is believed to be addressed. However, since I have not been able to confirm this yet, I will not close it. I would appreciate it if someone would be able to try a recent dev build of AJDT on a maven project that has this problem in the past and see if the problem still manifests itself. Once again, I believe that the fix for bug 275903 addresses this issue, but I cannot prove it.
Hi! My initial testing with ajdt 2.0.0.e34x-20090603-0900 seems to show that I can NOT reproduce this issue with this version. I'm on osx 10.5.7, java 1.6 and eclipse 3.5 (I20090528-2000). Thanks! :)
Thanks Kaj, for taking a look at this. This bug has been bugging me for a year now. :) But I believe it is fixed. I will close this bug. Please reopen if you do experience.
