Hi,
I'm using M1 so can't comment direclty on M2 stuff, but thought I'd
chip in with some thoughts on source file placement.
I've tried a few different approaches and have settled on putting the
aspects in with the java source as I view them as java-like if not
strict java (after all AJDT lets you name your files .java instead of
.aj). So, mine live in plain old main/src/java and it works well in
Eclipse and from Maven.
In M1 I did have some problems with having aspects across source trees
(or indead affecting source in multiple trees, for example
main/test/java)...
Cheers,
T
gdub-2 wrote:
>
> Good morning-
>
> I'm trying to figure out the best way to
> use AspectJ with both Eclipse and Maven 2.
>
> Problem 1:
> I have the Codehaus plugin installed and
> working. But the eclipse:eclipse target
> does not configure the project as AspectJ.
> Does anyone know if this feature is being
> considered? If it is not in the works
> already, in which plugin (aspectj or
> eclipse or both) should the support lie?
>
> Problem 2:
> Say the rt dependency in Maven is set
> to Eclipse 1.5.2a. Run eclipse:eclipse
> target and the dependency is is set
> correctly in the IDE. However, changing
> the project to an AJ project from within
> the IDE (required because of P1 above),
> adds a conflicting dependency on a jar from
> AJDT itself (1.5.2.something).
>
> Problem 3:
> There is, AFAICT, no Maven source location
> convention for source files that require an
> AspectJ compiler. I am not sure that
> src/{main,test}/java is the correct
> place since it is not strictly Java code.
> I imagine that there are good reasons
> against establishing a convention such as
> using src/{main,test}/aspectj and I'd like
> to hear them. Pragmatically wrt to
> the topic at hand, the use of the
> AspectJ compiler is all-or-nothing at the
> project level in Eclipse so a separate
> code location is meaningless there. But, I
> don't think basic build convention
> decisions should be made on the basis
> of supporting any particular development
> tool.
>
> I know this is a big conceptual
> problem. The value of AspectJ in many
> cases is to enable unanticipated extension
> of Java software. So, a large portion
> of the code that is compiled/woven by ajc is
> not aware (nor should it be) that it is
> being advised--meaning the advised code
> developer would rightly place sources in
> .../java. Aspects might be best packaged
> separately for such situations. But, a
> growing body of software is being designed
> with aspects for application logic. That
> means, for instance, pointcuts in class
> definitions and aspect source files mixed
> in with standard java sources. Such code
> might belong in a directory such as
> .../aspectj to signal, by convention, that
> the code requires an AspectJ compiler.
> There are many such issues with this
> particular language because it doesn't fit
> traditional language models and probably
> breaks subtle assumptions in the models
> of many development tools such as Maven
> and Eclipse.
>
> Any thoughts? Am I missing some
> fundamental piece of understanding that
> makes AJDT and Maven integration a
> snap?
>
> TIA,
>
> -dub
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/successful-AJDT-integration--tf2631647s177.html#a7347170
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
