aspectj iajc терпит неудачу, когда подкласс наследует переименованный метод, вплетенный в его базовый класс и определенный в отдельном jar - PullRequest
1 голос
/ 11 августа 2011

Я использую aspectJ для внедрения реализации интерфейса. Eclipse компилирует все просто отлично. Однако проект также должен быть построен с использованием муравья.

Задача iajc не выполняется с: «Тип Foo должен реализовывать унаследованный абстрактный метод Bar.doThings ()» где Bar - интерфейс, который имеет реализацию типа (ITD).

код выглядит следующим образом (в соответствующих файлах):

class Foo extends BaseFoo {...}
abstract class BaseFoo implements Bar {...}
interface Bar{ 
     void doThings{} 
     public static aspect Implementation {
           void Bar.doThings() {
               //whatever
            }
     }
 }

В ткацких сообщениях показан класс BaseFoo, имеющий метод doThings() intertyped но Фу нет. и, следовательно, завершается с ошибкой «необходимо реализовать ...».

Я вполне уверен, что у меня есть подобные ситуации, работающие правильно в моем common.jar. Это происходит, когда я компилирую другой модуль, в котором определен Bar и реализован ITD / в common.jar. Common.jar указан правильно в <iajc .... aspectPathRef..>, иначе BaseFoo не был бы напечатан.

Похоже, что компилятор не видит реализацию, унаследованную от базового класса, в котором она была переписана.

Вот как выглядит iajc:

   <iajc destdir="${build.dir}" sourceroots="${javasrc.dir}"`
            source="1.6"
            classpathref="classpath" 
            Xlint="warnings" 
            aspectPathRef="aspectlib"
            showWeaveInfo="true" />

где aspectlib включает apsectjrt.jar и мой common.jar

и еще одна вещь: проект eclipse, который выполняет компиляцию и запуск, не делится на общий и другие модули - все каталоги src просто импортируются в один агрегатный проект.

Так что, пожалуйста - что здесь не так?

Ответы [ 3 ]

1 голос
/ 13 августа 2011

Вот ссылка на ошибку, которую я отправил на aspectj bugzilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=354683

Я решил проблему следующим образом: Определение аспектов и интерфейсов в jar-иерархических интерфейсах и их иерархических реализациях неправильно сплетено в целевом проекте как в eclipse, так и в командной строке.

Вот весь код в проекте "jar":

public interface CommonData {void getData();}
public interface CommonDataImpl extends CommonData {}
public aspect CommonDataImplementation {
     public void CommonDataImpl.getData() {}
}
public interface DerivedCommonDataInterface extends CommonData {
    void getDerivedData();
}
public interface DerivedCommonDataInterfaceImpl 
           extends DerivedCommonDataInterface, CommonDataImpl {}
public aspect DerivedCommonDataInterfaceImplementation {
    public void DerivedCommonDataInterfaceImpl.getDerivedData() {}
}

Обратите внимание, что «производный» интерфейс расширяет другой, и его реализация расширяет «общую» реализацию.

Вот весь целевой проект:

public abstract class AbstractBaseClass <T extends Whatever> 
    implements DerivedCommonDataInterfaceImpl {}
public class DerivedClass extends AbstractBaseClass {}

Файлы build.xml будут здесь бесполезной тратой пространства - вы можете скачать tar из приложения к ошибке (ссылка выше). Так что, пока кто-то из проекта aspectj не придет к этому - это ответ.

И даже несмотря на то, что эта проблема является довольно серьезной проблемой и может сделать ее демонстрацией во многих ситуациях, я собираюсь объединить всю мою настоящую работу в единый проект eclipse / ant через символические ссылки или svnexternals или что угодно, потому что реализация интерфейсов через ITD - это it - объем кода, который я удалил и который еще не удален благодаря ITD, трудно переоценить.

Большие пальцы к вам, люди (ошибки и все:)

0 голосов
/ 22 августа 2011

Попытайтесь поместить весь свой связанный с AspetJ код в тег inpath, а не aspectPathRef.У меня довольно сложная сборка Ant + AspectJ.И не испытывай таких проблем, как ты.

Вот структура моей задачи сборки AspectJ:

 <iajc destDir="${aop.output}" Xlintwarnings="true" showWeaveInfo="true" target="1.6"
         source="1.6" 
            bootclasspathref="android.target.classpath">

            <sourceroots>                   
                <path refid="${main.project.sources}" />

            </sourceroots>
            <inpath>                    
                <path refid="all.your.AspetJ.related.code.from.other.projects "/>                   
            </inpath>
            <classpath>

                <pathelement location="libs/httpmime-4.0.3.jar"/>
                <pathelement location="libs/apache-mime4j-0.6.jar"/>
                <pathelement location="libs/commons-io-2.0.1.jar"/>
                ....
                <pathelement location="${aspectj.home}/aspectjrt.jar"/>

            </classpath>
        </iajc>

Как видите, я вообще не использую aspectPathRef.

0 голосов
/ 12 августа 2011

То, как вы описываете вещи, звучит правильно. Это может быть ошибка в AspectJ в том, что статические внутренние аспекты и ITD не смешиваются между файлами JAR.

Я только что попробовал настройку, которую вы описали в Eclipse и AJDT (не с файлом JAR, а с отдельными проектами), и он работал нормально для меня.

Во-первых, вы можете попробовать сделать аспект на высшем уровне?

Если это не сработает, можете ли вы сообщить о проблеме в проекте, который вы можете прикрепить к сообщению об ошибке на eclipse.org? Если это так, я или кто-то еще взгляну на это.

https://bugs.eclipse.org/bugs/

...