Re: [aspectj-users] Compatibility with older AJDT versions

[Andrew Eisenberg <andrew@xxxxxxxxxxxx>]

Hi Thomas,

This is something worth considering.  Even though, I dislike storing
the same information in two places.  If the information in .classpath
always takes precedence, then it could be reasonable.

Please raise an enhancement request on bugzilla.  Since AJDT 1.6.4 is
coming out at the end of the week, it will not be able to be included
in that release.  However, I may be able to include it into an early
dev build of AJDT 1.6.5.

Also, 1.5.3 should be able to recognize the "modern" .classpath (and
delete the old style .classpath).  If not, then this is a bug.  Are
you sure that others are using 1.5.3? Based on looking at the cvs
history this behavior was introduced in 1.5, not in 1.6.  So, I am
surprised that it still seems to be using the old style.

On Fri, Mar 13, 2009 at 5:28 AM, Thomas M. Hofmann
<email@xxxxxxxxxxxxxxxxx> wrote:
> Hi,
>
> since I am migrating a code base from AJDT 1.5.3 to 1.6.3 / 1.6.4 I want
> to tell you one small annoyance I found.
>
> With AJDT 1.5.3 the AspectJ Build settings were stored in preference
> files. In AJDT, some of this information is now stored in .classpath.
>
> I looked at the code in AspectJCorePreferences and found the following:
>
> private static String[] internalGetProjectPath(IProject project,
> IClasspathAttribute attribute, boolean useResolvedPath) {
>        if (isAspectPathAttribute(attribute)) {
>                String[] old = getOldProjectAspectPath(project);
>                if (old != null) {
>                        AJLog.log("Migrating aspect path settings for
> project "+project.getName()); //$NON-NLS-1$
>
> setProjectAspectPath(project,old[0],old[1],old[2]);
>                        removeOldAspectPathSetting(project);
>                }
>        } else { // INPATH_ATTRIBUTE
>            String[] old = getOldProjectInPath(project);
>            if (old != null) {
>                AJLog.log("Migrating inpath settings for project
> "+project.getName()); //$NON-NLS-1$
>                setProjectInPath(project,old[0],old[1],old[2]);
>                removeOldInPathSetting(project);
>            }
>        }
>
>
> This tells me whenever an old settings file is found it is migrated to
> the and the old file is deleted.
>
> Now, I would like to suggest a different algorithm:
>
> 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.
>
> Could this be still considered for 1.6.4 final?
>
> Thanks for listening.
>
> Thomas
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>