Community
Participate
Working Groups
Sometimes an AJDT project gets into a state where it has a meta-inf/manifest.mf - and this file fails to make it out to the destination folder.
Looking at the resource handling in AJDT, it is not quite as I expected. A project clean does not mean 'delete everything in the bin directory and rebuild from scratch' - it means 'delete all the .class files in the bin directory, assume the resources are OK and leave them alone, then do a full build'. It relies on a change delta from eclipse to indicate that something has changed in the resources (non source files) on the source paths and then copies them to the output location. So, what I think is being observed as 'AJDT fails to copy the manifest.mf to the output folder' is actually 'something deleted META-INF/MANIFEST.MF without letting Eclipse know' and now eclipse/ajdt think it is up to date and refuse (even on a clean) to recopy.
/sigh Found the problem - not quite what I thought it was but knowing how AJDT wasn't doing what I imagined to be a clean helped me track it down. (and when Rob indicated touching the file on the filesystem caused it to be fixed) There is special code in AspectJ itself to avoid a problem of duplicate resource writing when creating a zip file (ie. using -outjar option). This code explicitly looks for MANIFEST.MF and completely ignores it. Unfortunately it doesn't check whether -outjar was being used, it just always ignores it... (DOH!) Fix for bug 57666 introduced this behaviour. What made it confusing to diagnose is that AJDT also does resource copying, but only sometimes, when resources change (and not on a project clean). Hence touching the file on the filesystem and doing a refresh causing Eclipse to recognize a change to MANIFEST.MF and the AJDT resource copying puts the file in the output folder. Fixed in AspectJ, fixed in AJDT - builds will be available shortly containing the fix (for Eclipse 3.3)
