ajdt-dev

[ajdt-dev] Project meta data is out of date for tools.ajdt

emo@xxxxxxx (portal on behalf of emo) — Sat, 05 May 2012 04:00:15 GMT

Andrew,
Projects are required to keep meta data up to date using the MyFoundation
Portal (http://portal.eclipse.org/).  The following problems were found
with this project's meta-data:

* The date for release "2.2.0" is in the past, but the release is not
marked as completed. If it is completed, it should be marked as completed;
if it has been postponed, it should be given a new target date.
* There is no next/future release of this project. All Eclipse projects
must have a "next release" planned and scheduled.

[ajdt-dev] Project meta data is out of date for tools.ajdt

emo@xxxxxxx (portal on behalf of emo) — Thu, 05 Apr 2012 04:00:15 GMT

Andrew,
Projects are required to keep meta data up to date using the MyFoundation
Portal (http://portal.eclipse.org/).  The following problems were found
with this project's meta-data:

* The date for release "2.2.0" is in the past, but the release is not
marked as completed. If it is completed, it should be marked as completed;
if it has been postponed, it should be given a new target date.
* There is no next/future release of this project. All Eclipse projects
must have a "next release" planned and scheduled.

[ajdt-dev] Project meta data is out of date for tools.ajdt

emo@xxxxxxx (portal on behalf of emo) — Mon, 05 Mar 2012 05:00:06 GMT

Andrew,
Projects are required to keep meta data up to date using the MyFoundation
Portal (http://portal.eclipse.org/).  The following problems were found
with this project's meta-data:

* The date for release "2.2.0" is in the past, but the release is not
marked as completed. If it is completed, it should be marked as completed;
if it has been postponed, it should be given a new target date.
* There is no next/future release of this project. All Eclipse projects
must have a "next release" planned and scheduled.

Re: [ajdt-dev] ajdt+groovy-eclipse

andrew.clement@xxxxxxx (Andy Clement) — Wed, 29 Feb 2012 18:03:54 GMT

Hi Steve,

The bug you are looking for is this one:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=287092

> Is it possible to run AJDT and Eclipse-Groovy in the same project?  Or
> rather is it possible to ever do this in the future?  Or are there
> underlying limitations of eclipse that would prevent this?

The limitations are simply that: Groovy-Eclipse patches
org.eclipse.jdt.core; AspectJ uses a branch of jdt core called
org.aspectj.org.eclipse.jdt.core.  This means when you switch your
project to AspectJ (and it switches compiler) it starts using one that
doesn't have the groovy-eclipse changes in.  And when you switch your
project back to groovy you don't have a compiler that is Aspect aware.

In theory it is just a task of taking the patches made to
org.eclipse.jdt.core and applying them to the org.aspectj copy of jdt
core - but we never find the time.

It sounds like you do want the weaver to weave into the groovy code
(rather than just using groovy for scripts which could possibly be
made to work in an easier way).  If you were able to split the
project, you could maybe get something working.  Groovy in one
project, then use 'inpath' on the AspectJ project to consume the
groovy compiled code and include it in the output of the AspectJ
project.

So we know what the challenge is, but it doesn't ever seem to reach
the top of the priority list...

cheers
Andy

On 29 February 2012 07:42, Steve Ash  wrote:
>
> I looked for anything existing in the codehaus jira for groovy+eclipse as
> well as the bugzilla tracker for AJDT and didn't find anything related, even
> though I'm sure its come up before.  So I will ask, and apologize if its
> already been covered extensively.
>
> Is it possible to run AJDT and Eclipse-Groovy in the same project?  Or
> rather is it possible to ever do this in the future?  Or are there
> underlying limitations of eclipse that would prevent this?
>
> Since we do (and want to continue doing) compile time weaving-- I guess our
> best option is to use load time weaving in eclipse for junit etc and then
> use re-weaving at compile time to weave aspects into the bytecode coming out
> of eclipse-groovy compiler?
>
> For us the only aspects that we use are @Transactional and others that are
> still compilable as java code by javac -- so maven-groovy should be able to
> handle it.
>
> But this is still a pretty big departure from our current toolchain (just
> straight aspectj and AJDT) so I am hoping there is a better option or plans
> for one, since you guys are one in the same, I think.
>
> Thanks,
>
> Steve
>
>
> _______________________________________________
> ajdt-dev mailing list
> ajdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ajdt-dev
>

[ajdt-dev] ajdt+groovy-eclipse

stevemash@xxxxxxx (Steve Ash) — Wed, 29 Feb 2012 15:42:18 GMT

I looked for anything existing in the codehaus jira for groovy+eclipse as well as the bugzilla tracker for AJDT and didn't find anything related, even though I'm sure its come up before. So I will ask, and apologize if its already been covered extensively.

Is it possible to run AJDT and Eclipse-Groovy in the same project? Or rather is it possible to ever do this in the future? Or are there underlying limitations of eclipse that would prevent this?

Since we do (and want to continue doing) compile time weaving-- I guess our best option is to use load time weaving in eclipse for junit etc and then use re-weaving at compile time to weave aspects into the bytecode coming out of eclipse-groovy compiler?

For us the only aspects that we use are @Transactional and others that are still compilable as java code by javac -- so maven-groovy should be able to handle it.

But this is still a pretty big departure from our current toolchain (just straight aspectj and AJDT) so I am hoping there is a better option or plans for one, since you guys are one in the same, I think.

Thanks,

Steve

Re: [ajdt-dev] Some @aspectj advices leading to some runtime errors

andrew.clement@xxxxxxx (Andy Clement) — Tue, 10 Jan 2012 17:25:03 GMT

Hi,

I would raise AspectJ bugzillas, perhaps one for the proceed problem
and one for the line number debug information being incorrect.

Code style aspects can do more checking around the proceed() call.  If
you are using annotation style we would have to generate checking code
that ran at runtime, to avoid errors like this:

> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 1

we don't generate that code and so unless you get the right
incantation for your proceed parameters it will manifest as nasty
runtime failures. There have been several bugs in this area over the
years, it needs a big refactoring.

> Shouldn't this be :
>
> state[hasThis ? 1 : 0] = adviceBindings[bindThis ? 1 : 0];

could be.  If that fixes all your tests and doesn't break any of the
AspectJ tests, we can put it in.  If you could attach patches to the
bugzilla that would be great.  if you want I can show you how to
create AspectJ testcases that you could also contribute back to the
regression test suite.

cheers,
Andy

On 10 January 2012 03:58,   wrote:
> Hi list,
>
> Glad to use AspectJ in one of our project!
>
> [I use AJDT 2.2.0.e37x-20120105-1100 with AspectJ version: 1.7.0.20111215190600 in my IDE. And AspectJ 1.6.12 in my production environment]
>
> I encounter some problems with using @aspectj.
> I define the following example class in a simple AspectJ project.
>
> 
> package foo;
>
> public class Test {
>
>        public final static void main(String[] args) {
>                Test test = new Test();
>                System.out.println(test.runTest());
>        }
>
>        public int runTest() {
>                return this.test(5);
>        }
>
>        public int test(int i) {
>                return i;
>        }
> }
> 
>
> Then I tried different way of pointcuting the int test(int) method. I describe each time what I observe bellow.
>
> 1. Using neither args() nor this()
>
> 
> package foo;
>
> import org.aspectj.lang.ProceedingJoinPoint;
> import org.aspectj.lang.annotation.Around;
> import org.aspectj.lang.annotation.Aspect;
> import org.aspectj.lang.annotation.Pointcut;
>
> @Aspect
> public class TestAspect {
>
>        @Pointcut("call(int foo.Test.test(int)) && "
>                        + " target(test)")
>        void testPointcut(Test test) {}
>
>        @Around("testPointcut(test)")
>        public Object doTest(final ProceedingJoinPoint jp,
>                        Test test) throws Throwable {
>                return jp.proceed(new Object[] { test });
>        }
> }
> 
>
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 1
>        at foo.Test.test_aroundBody1$advice(Test.java:18)
>        at foo.Test.runTest(Test.java:11)
>        at foo.Test.main(Test.java:7)
>
>
> 2. Using args() but no this()
>
> From reading the docs this code is correct.
>
> 
> package foo;
>
> import org.aspectj.lang.ProceedingJoinPoint;
> import org.aspectj.lang.annotation.Around;
> import org.aspectj.lang.annotation.Aspect;
> import org.aspectj.lang.annotation.Pointcut;
>
> @Aspect
> public class TestAspect {
>
>        @Pointcut("call(int foo.Test.test(int)) && "
>                        + " target(test) && args(i)")
>        void testPointcut(Test test, int i) {}
>
>        @Around("testPointcut(test, i)")
>        public Object doTest(final ProceedingJoinPoint jp,
>                        Test test, int i) throws Throwable {
>                return jp.proceed(new Object[] { test, i * 2 });
>        }
> }
> 
>
> Exception in thread "main" java.lang.ClassCastException: java.lang.Integer cannot be cast to foo.Test
>        at foo.Test.test_aroundBody1$advice(Test.java:18)
>        at foo.Test.runTest(Test.java:11)
>        at foo.Test.main(Test.java:7)
>
> 3. Using args() and this()
>
> 
> package foo;
>
> import org.aspectj.lang.ProceedingJoinPoint;
> import org.aspectj.lang.annotation.Around;
> import org.aspectj.lang.annotation.Aspect;
> import org.aspectj.lang.annotation.Pointcut;
>
> @Aspect
> public class TestAspect {
>
>        @Pointcut("call(int foo.Test.test(int)) && "
>                        + " target(test) && args(i)")
>        void testPointcut(Test test, int i) {}
>
>        @Around("testPointcut(test, i) && this(t)")
>        public Object doTest(final ProceedingJoinPoint jp,
>                        Test test, int i, Object t) throws Throwable {
>                return jp.proceed(new Object[] { t, test, i * 2 });
>        }
> }
> 
>
> This version works as expected. However, it seems that the generated bytecode during weaving incorrectly builds the debug line markers as if you put a breakpoint in the advice, Eclise don't suspend inside the advice code but elsewhere in the Test class code. Also, when you try to step (in a blind way) in the code from a breakpoint in runTest(), you can observe there is somewhat a mismatch in the variable handling...
>
> Should I raise a bug for all that ?
>
> After playing with AspectJ source code (version 1.6.12), I suspect there might be a bug in the weaver but also in line 202 of JoinPointImpl:
>
> state[hasThis ? 1 : 0] = adviceBindings[hasThis ? 1 : 0];
>
> Shouldn't this be :
>
> state[hasThis ? 1 : 0] = adviceBindings[bindThis ? 1 : 0];
>
> Everytime you can replace the faulty proceed(..) call by a no-arg proceed() call and then this works as expected.
>
> Thanks for you help!
> Didier.aj
> _______________________________________________
> ajdt-dev mailing list
> ajdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ajdt-dev

[ajdt-dev] Some @aspectj advices leading to some runtime errors

ptitjes@xxxxxxx (ptitjes) — Tue, 10 Jan 2012 11:58:08 GMT

Hi list,

Glad to use AspectJ in one of our project!

[I use AJDT 2.2.0.e37x-20120105-1100 with AspectJ version: 1.7.0.20111215190600 in my IDE. And AspectJ 1.6.12 in my production environment]

I encounter some problems with using @aspectj.
I define the following example class in a simple AspectJ project.


package foo;

public class Test {

        public final static void main(String[] args) {
                Test test = new Test();
                System.out.println(test.runTest());
        }

        public int runTest() {
                return this.test(5);
        }

        public int test(int i) {
                return i;
        }
}


Then I tried different way of pointcuting the int test(int) method. I describe each time what I observe bellow.

1. Using neither args() nor this()


package foo;

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;

@Aspect
public class TestAspect {

        @Pointcut("call(int foo.Test.test(int)) && "
                        + " target(test)")
        void testPointcut(Test test) {}

        @Around("testPointcut(test)")
        public Object doTest(final ProceedingJoinPoint jp,
                        Test test) throws Throwable {
                return jp.proceed(new Object[] { test });
        }
}


Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 1
        at foo.Test.test_aroundBody1$advice(Test.java:18)
        at foo.Test.runTest(Test.java:11)
        at foo.Test.main(Test.java:7)


2. Using args() but no this()

>From reading the docs this code is correct.


package foo;

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;

@Aspect
public class TestAspect {

        @Pointcut("call(int foo.Test.test(int)) && "
                        + " target(test) && args(i)")
        void testPointcut(Test test, int i) {}

        @Around("testPointcut(test, i)")
        public Object doTest(final ProceedingJoinPoint jp,
                        Test test, int i) throws Throwable {
                return jp.proceed(new Object[] { test, i * 2 });
        }
}


Exception in thread "main" java.lang.ClassCastException: java.lang.Integer cannot be cast to foo.Test
        at foo.Test.test_aroundBody1$advice(Test.java:18)
        at foo.Test.runTest(Test.java:11)
        at foo.Test.main(Test.java:7)

3. Using args() and this()


package foo;

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;

@Aspect
public class TestAspect {

        @Pointcut("call(int foo.Test.test(int)) && "
                        + " target(test) && args(i)")
        void testPointcut(Test test, int i) {}

        @Around("testPointcut(test, i) && this(t)")
        public Object doTest(final ProceedingJoinPoint jp,
                        Test test, int i, Object t) throws Throwable {
                return jp.proceed(new Object[] { t, test, i * 2 });
        }
}


This version works as expected. However, it seems that the generated bytecode during weaving incorrectly builds the debug line markers as if you put a breakpoint in the advice, Eclise don't suspend inside the advice code but elsewhere in the Test class code. Also, when you try to step (in a blind way) in the code from a breakpoint in runTest(), you can observe there is somewhat a mismatch in the variable handling...

Should I raise a bug for all that ?

After playing with AspectJ source code (version 1.6.12), I suspect there might be a bug in the weaver but also in line 202 of JoinPointImpl:

state[hasThis ? 1 : 0] = adviceBindings[hasThis ? 1 : 0];

Shouldn't this be :

state[hasThis ? 1 : 0] = adviceBindings[bindThis ? 1 : 0];

Everytime you can replace the faulty proceed(..) call by a no-arg proceed() call and then this works as expected.

Thanks for you help!
Didier.aj

[ajdt-dev] Project meta data is out of date for tools.ajdt

emo@xxxxxxx (portal on behalf of emo) — Thu, 05 Jan 2012 05:00:16 GMT

Andrew,
Projects are required to keep meta data up to date using the MyFoundation
Portal (http://portal.eclipse.org/).  The following problems were found
with this project's meta-data:

* The date for release "2.2.0" is in the past, but the release is not
marked as completed. If it is completed, it should be marked as completed;
if it has been postponed, it should be given a new target date.
* There is no next/future release of this project. All Eclipse projects
must have a "next release" planned and scheduled.

[ajdt-dev] First AJDT snapshot release with AspectJ 1.7

andrew@xxxxxxx (Andrew Eisenberg) — Fri, 16 Dec 2011 16:40:50 GMT

Hi all,

We now have a first usable snapshot release of AJDT with AspectJ 1.7
available on the dev update site:
http://download.eclipse.org/tools/ajdt/37/dev/update/

All tests are passing and we have done a simple smoke test.  It is now
at a stage where we want to get feedback from the community.  So,
please try out the new AJDT and let us know if you have any issues
(with the Eclipse tools or with the compiler).  Thanks.

Andrew

Re: [ajdt-dev] Android with AspectJ and building it with Ant on Eclipse

andrew@xxxxxxx (Andrew Eisenberg) — Mon, 12 Dec 2011 16:57:49 GMT

I took a bit of a look at your situation.  It is expected that aspects
coming in from the aspect path will have warnings on all the advices.
This is because the aspect project itself does not know that it is on
the aspect path of any other project.  However, if you open your
target project, you will see that the appropriate targets have aspectj
gutter markers.    This project does know about aspects coming from
the aspect path.

So, take a look at your target project, and if you see aspectj gutter
markers, then things should be working appropriately.  However, I
don't really know how the android compiler works.  There may be some
extra code generation going on.  It may work on source code, not byte
code and will therefore not know how to handle aspects.



On Fri, Dec 9, 2011 at 11:26 AM, Sam Xiao  wrote:
> Hi all,
>
>
>
> Nice to meet everyone here!
>
>
>
> I'm new to Android and wanted to use AspectJ with it. I had searched couple
> articles online and follow the instruction to have it working:
> http://blog.punegtug.org/2010/11/adding-aspect-to-android.html
>
>
>
> But I wanted to know whether if it's possible to separate the aspects away
> from the Android project. In the tutorial link above, it has both the
> Android App and the aspects inside the same project, but in many cases, we
> wanted to leave the Android Project untouched in its isolating spaces.
>
>
>
> Let said I have AndroidProject in my Eclipse workspace, I would like to
> create a separate projects for my aspects called something like
> "AndroidAspectProject" which only contains the aspects for it.
>
>
>
> I'm not sure whether this would work because it seems we need to let AspectJ
> compiler inject point cuts and advices to the .class files before creating
> the .dex files. In this sense, I may not able to do it in a separate
> project.
>
>
>
> Does anyone try with this?
>
>
>
> Another related question would be: Is it possible to have Ant build the
> AndroidProject with AND without aspects on it? Can this be done outside of
> Eclipse?
>
> I'm looking for a way to build different flavours as I'm only injecting
> pointcuts into the AndroidProject on dev/debug build, but will leave it
> untouched on release build.
>
>
>
> I had already asked such question on Stackoverflow:
> http://stackoverflow.com/questions/8409425/android-with-aspectj-and-building-it-with-ant-on-eclipse
>
> But I’m still stuck to finding the best way to handle my case of building
> AspectJ libraries used in Android Project.
>
>
>
> Andrew Eisenberg (thanks to him, the person who recommended me using this
> mailing list) already provided some advices to my question, however, it
> doesn’t really quite working for me as I had errors when I put my *.aj as a
> separate projects in the workspace in Eclipse.
>
>
>
>
>
> Thanks in advanced for any answers for this!
>
>
>
>
>
> Thanks.
>
> Sam Xiao.
>
> Office: 1-408-324-3760
>
>
>
>
> _______________________________________________
> ajdt-dev mailing list
> ajdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ajdt-dev
>