Community
Participate
Working Groups
Since AJDT 1.5 the Inpath and Aspect Path settings are stored in .classpath. Before they were stored in a AJDT-specific file. When migrating from 1.4.x to 1.6.x it would be helpful if one could have both kinds of settings for the migration period so that some team members can upgrade and test the new environment and others can stay on what is stable until all migrate to the new environment. Unfortunately, AJDT 1.6.x removes the old settings once they are migrated to .classpath The request here is to allow the old files still to exist for the reasons mentioned above. See discussion on aspectj-users mailing list. Thomas
Currently, AJDT looks for old style project path settings and if they exist, converts them to the new style project path settings. It then deletes the old style settings. From the mailing list, Thomas suggested a different way of doing this ====== 1. Look for the new settings. If found, just use them. 2. Otherwise look for old settings an migrate them and delete the old settings (just like the code does today) With this additional step it would be possible to keep both the old and the new settings (I could manually restore the old files) and also keep the new ones. This would make the migration from AJDT 1.5.x to 1.6.x much easier because some of the developers could switch to 1.6 and test the new environment extensively before the complete dev team needs to migrate. Of course, one would need to update both files in case changes need to be made to the aspect build settings but this would only be until all developers have migrated. ====== There is a problem with your proposed change in that there is no way of knowing if step 1 already happened. Since all information is stored in the .classpath file, it might just be that the new settings are being used and there is nothing on the aspect/in path. There needs to be some kind of marker somewhere that says that AJDT has already processed the old project path settings and that any project path settings still in existence are only for backwards compatibility. This kind of marker can be part of the project properties (in the same way the old project paths were stored).
Is there any chance getting this into 1.6.5?
I'll take a look at this. Here is what will happen: 1. old style project aspect/inpath entries will not be deleted 2. instead, add a marker to the project properties that says that the old style has been processed. 3. when AJDT looks to create the aspect/inpath, if the marker exists then do not check for old style. If the marker does not exist, then check for old style and create the marker The ramifications of this is if the new style aspect/inpath changes after the marker has been set, the old style will not pick it up. And vice versa. This is something I can work on later if you require it. But for now, I can work on making sure that old style sticks around.
It's absolutely ok if changes to either one are not picked up by the other. Its just for the time we migrating from one version to the other. Right now I have so many changes in my worksapce due to the new files that I'm having trouble seeing the real changes I need to commit while the rest of the team is still on the older version.
Addressed with regression tests. Here is how it works: I added two preference settings to AJDT that store whether or not the old style aspect/in path should be added to the existing aspect/in path. For projects that have an old style aspect/in path, the setting added is: org.eclipse.ajdt.ui.aspectPath=visited (or) org.eclipse.ajdt.ui.inPath=visited This means that on subsequent builds, the old style aspect/in path will be ignored in 1.6. This has no effect in 1.4 and earlier. If you ever change the 1.6 aspect/in path, this will not show up in the old style path at all. If you change the old style aspect/in path, you can remove the org.eclipse.ajdt.ui.aspectPath=visited or org.eclipse.ajdt.ui.inPath (manually from the .settings/org.eclipse.ajdt.ui.prefs file) and AJDT will re-apply the old style path. Please let me know if this addresses your problem.
Everything works as expected. Thank you very much for implementing this. It will ease our migration efforts.
Glad it works.
