Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] Problems with Building -- Exporting aspects across multiple projects in eclipse

Are you able to run the testcase outside of eclipse from the command
line?  I can't see where it is getting the old classfile from when
executing the test if the .class on the disk is correct...

Andy.

On 11/04/2008, Mike Schneider <mikepschneider@xxxxxxxxx> wrote:
> The time stamp on the class file is updated.  The new string does
>  appear in the class
>  file when I use the javap command.  But I still see this behavior.
>
>  I also tried: disabling inlining of code, and removing the binary
>  output folder of the aspects
>  project from the aspectpath and the classpath of project C.  None of
>  those solved the behavior.
>
>  The only thing that seems to fix it is to remove the aspectj nature of
>  project C.  So it seems
>  that when the aspectj nature is on, and the java files are compiled
>  with ajc, that the
>  correct class files are generated, but when I launch they are somehow
>  not picked up by the code
>  that is executing.
>
>
>  On Fri, Apr 11, 2008 at 3:21 PM, Andy Clement <andrew.clement@xxxxxxxxx> wrote:
>  > So you can run the test in project C without the aspecpath being set
>  >  for the project, if it is just a logging aspect?  Does the test pickup
>  >  the string change in this case?
>  >
>  >  Does the timestamp on file X change on the disk when it is rebuilt?
>  >  Can you use javap -verbose on it to check it really has the new string
>  >  value in the class file?
>  >
>  >  You could try switching off around advice inlining in project C to see
>  >  if that makes any difference (in one of the AJDT preference menus) -
>  >  it shouldn't... but it is something to try.
>  >
>  >
>  >
>  >  Andy.
>  >
>  >  On 11/04/2008, Mike Schneider <mikepschneider@xxxxxxxxx> wrote:
>  >  > I am not using inpath, only aspectpath.
>  >  >
>  >  >  I changed a string in java file X in project C.  The unit test that
>  >  >  referred to that string also lived in project C.  I could see that
>  >  >  only file X was the one file that got recompiled and rewoven.  I did
>  >  >  not expect any other files to be recompiled and did not see any, only
>  >  >  file X was recompiled.
>  >  >
>  >  >  The aspect is a simple entry-and-exit logging using an around advice.
>  >  >  The unit test does not depend on the aspect actually being there to
>  >  >  pass.
>  >  >
>  >  >  I'll see if I can reproduce it with a sample set of projects.
>  >  >
>  >  >
>  >  >
>  >  >  On Fri, Apr 11, 2008 at 1:22 PM, Andy Clement <andrew.clement@xxxxxxxxx> wrote:
>  >  >  > > With all of the event tracing on, when I changed the file and save it,
>  >  >  >  > I see that AJC recompiles and reweaves that one file.  It does not
>  >  >  >
>  >  >  > > show any obvious errors or other problems.  But, when I run the unit
>  >  >  >  > test in eclipse I don't see my change.  Only when I do a full rebuild
>  >  >  >  > do I see the changes in the unit test.
>  >  >  >
>  >  >  >  Which file to do you change?  Something in the Aspect project? Project C?
>  >  >  >  Does the change you expect to see in the unit test rely on the aspect being
>  >  >  >  rewoven?  The unit test is in which project C?
>  >  >  >  When you make the change and save it, and see it rebuild/reweave - is there
>  >  >  >  a file in a dependent project you would expect to be seeing rebuilt but it
>  >  >  >  does not?
>  >  >  >
>  >  >  >  This might be easier with a concrete set of test projects that exhibit
>  >  >  >  the problem.
>  >  >  >  Right now I don't know why this would be failing, if the event trace view shows
>  >  >  >  something is rebuilt/rewoven then the new version is on the disk and when
>  >  >  >  executing the tests, that is the version that will be used.  Elements on the
>  >  >  >  aspectpath are implicitly included on the classpath for a project as
>  >  >  >  well, I hope
>  >  >  >  that isn't causing you a problem with a type in the aspect project overriding
>  >  >  >  some type from another project.  You aren't using inpath anywhere are you?
>  >  >  >
>  >  >  >
>  >  >  >
>  >  >  >  Andy.
>  >  >  >
>  >  >  >  On 11/04/2008, Mike Schneider <mikepschneider@xxxxxxxxx> wrote:
>  >  >  >  > My projects are set up as such (somewhat simplified, as I really have
>  >  >  >  >  8 eclipse projects, but I'll describe what I believe is relevant)
>  >  >  >  >
>  >  >  >  >  Projects Aspects is the base project (and contains only one aspect
>  >  >  >  >  file, and no java files)
>  >  >  >  >  Project A includes the binary output folder from Project Aspects on
>  >  >  >  >  its aspect path
>  >  >  >  >  Project B depends on project A, and includes the binary output folder
>  >  >  >  >  from Project Aspects on its aspect path
>  >  >  >  >  Project C depends on project B, and includes the binary output folder
>  >  >  >  >  from Project Aspects on its aspect path
>  >  >  >  >
>  >  >  >  >  All 4 projects have aspectj nature turned on.
>  >  >  >  >
>  >  >  >  >  I noticed the particular issue below in Project C, but my colleagues
>  >  >  >  >  have observed it in other projects (B for instance).
>  >  >  >  >
>  >  >  >  >  With all of the event tracing on, when I changed the file and save it,
>  >  >  >  >  I see that ACJ recompiles and reweaves that one file.  It does not
>  >  >  >  >  show any obvious errors or other problems.  But, when I run the unit
>  >  >  >  >  test in eclipse I don't see my change.  Only when I do a full rebuild
>  >  >  >  >  do I see the changes in the unit test.
>  >  >  >  >
>  >  >  >  >  My version info is as follows:
>  >  >  >  >  AJDT Version: 1.5.2.200804031719
>  >  >  >  >  AspectJ version: 1.6.0.20081300000000
>  >  >  >  >
>  >  >  >  >  Any ideas?
>  >  >  >  >
>  >  >  >  >
>  >  >  >  >
>  >  >  >  >
>  >  >  >  >  On Fri, Apr 11, 2008 at 12:44 PM, Andy Clement <andrew.clement@xxxxxxxxx> wrote:
>  >  >  >  >  > How are your projects configured? Did you go for aspectpath or inpath?
>  >  >  >  >  >   So you have AJDT Project A  and Java Project B with B depending on A
>  >  >  >  >  >  via aspectpath ?  You make the change where ? to java code in A or B?
>  >  >  >  >  >
>  >  >  >  >  >   Are you on a recent version of AJDT (I made some changes to
>  >  >  >  >  >  incremental compilation recently).
>  >  >  >  >  >
>  >  >  >  >  >  To understand what is/isnt getting built you can activate the AJDT
>  >  >  >  >  >  Event Trace view in eclipse, turn on full reporting of all types of
>  >  >  >  >  >  event (button in top right) and then when you make your change it will
>  >  >  >  >  >  tell you everything it is doing. Does something in there not look
>  >  >  >  >  >  right?
>  >  >  >  >  >
>  >  >  >  >  >  Andy.
>  >  >  >  >  >
>  >  >  >  >  >
>  >  >  >  >  >
>  >  >  >  >  >  On 11/04/2008, Mike Schneider <mikepschneider@xxxxxxxxx> wrote:
>  >  >  >  >  >  > Thanks Andy.  I basically figured out the same thing after some
>  >  >  >  >  >  >  hunting.  This technique works and it shows the correct markers in my
>  >  >  >  >  >  >  code.
>  >  >  >  >  >  >
>  >  >  >  >  >  >  However, I have a second problem.  Now when I run my code within
>  >  >  >  >  >  >  eclipse it does not pick up my recent changes to the java
>  >  >  >  >  >  >  files without doing a clean.  For instance, I have a unit test that
>  >  >  >  >  >  >  passes.  I update some of the data inputted to the unit test
>  >  >  >  >  >  >  such that it shouldn't pass.   I run it again (with build
>  >  >  >  >  >  >  automatically turned on) and it still passes.  I do a full clean,
>  >  >  >  >  >  >  allow the
>  >  >  >  >  >  >  rebuild to run, and run it again, and the test fails.  The only
>  >  >  >  >  >  >  solution I have currently is to disable aspects, or to do a full clean
>  >  >  >  >  >  >  each time
>  >  >  >  >  >  >  I execute.
>  >  >  >  >  >  >
>  >  >  >  >  >  >  Any idea what's going on here, and how I can fix it?    Thanks
>  >  >  >  >  >  >
>  >  >  >  >  >  >  Mike
>  >  >  >  >  >  >
>  >  >  >  >  >  >
>  >  >  >  >  >  >  On Mon, Apr 7, 2008 at 9:28 AM, Andy Clement <andrew.clement@xxxxxxxxx> wrote:
>  >  >  >  >  >  >  > Hello Mike,
>  >  >  >  >  >  >  >
>  >  >  >  >  >  >  >  Aspects from a project upon which you depend are not automatically
>  >  >  >  >  >  >  >  picked up unless they can be found on the aspect path for the project
>  >  >  >  >  >  >  >  you want to get woven.
>  >  >  >  >  >  >  >
>  >  >  >  >  >  >  >
>  >  >  >  >  >  >  >  > I also tried adding the folder
>  >  >  >  >  >  >  >  >  containing the .aj files to the Inpath of the derived project and the
>  >  >  >  >  >  >  >  >  AspectJ path of the derived project.
>  >  >  >  >  >  >  >
>  >  >  >  >  >  >  >  Like classpath, the inpath and aspectpath are for jars and directories
>  >  >  >  >  >  >  >  containing class files, not source files.  You need to put the bin
>  >  >  >  >  >  >  >  folder of the project where the aspects are built onto the aspectpath
>  >  >  >  >  >  >  >  of the projects you want to be woven. ( I know this could be more UI
>  >  >  >  >  >  >  >  friendly and involve some simple clicks rather than path
>  >  >  >  >  >  >  >  configuration).  With the compiled aspects on the aspectpath, the
>  >  >  >  >  >  >  >  projects will get woven.  Now, showing across project markers is quite
>  >  >  >  >  >  >  >  complicated (perhaps I mean  'not always 100% reliable' ....) so the
>  >  >  >  >  >  >  >  best way to verify your code is woven as you expect is to run your
>  >  >  >  >  >  >  >  tests.  Or you could turn on the weave info messages in the UI and
>  >  >  >  >  >  >  >  then information about what gets woven will come out in the problems
>  >  >  >  >  >  >  >  view as info messages.
>  >  >  >  >  >  >  >
>  >  >  >  >  >  >  >  Andy.
>  >  >  >  >  >  >  >  _______________________________________________
>  >  >  >  >  >  >  >  aspectj-users mailing list
>  >  >  >  >  >  >  >  aspectj-users@xxxxxxxxxxx
>  >  >  >  >  >  >  >  https://dev.eclipse.org/mailman/listinfo/aspectj-users
>  >  >  >  >  >  >  >
>  >  >  >  >  >  >  _______________________________________________
>  >  >  >  >  >  >  aspectj-users mailing list
>  >  >  >  >  >  >  aspectj-users@xxxxxxxxxxx
>  >  >  >  >  >  >  https://dev.eclipse.org/mailman/listinfo/aspectj-users
>  >  >  >  >  >  >
>  >  >  >  >  >  _______________________________________________
>  >  >  >  >  >  aspectj-users mailing list
>  >  >  >  >  >  aspectj-users@xxxxxxxxxxx
>  >  >  >  >  >  https://dev.eclipse.org/mailman/listinfo/aspectj-users
>  >  >  >  >  >
>  >  >  >  >  _______________________________________________
>  >  >  >  >  aspectj-users mailing list
>  >  >  >  >  aspectj-users@xxxxxxxxxxx
>  >  >  >  >  https://dev.eclipse.org/mailman/listinfo/aspectj-users
>  >  >  >  >
>  >  >  >  _______________________________________________
>  >  >  >  aspectj-users mailing list
>  >  >  >  aspectj-users@xxxxxxxxxxx
>  >  >  >  https://dev.eclipse.org/mailman/listinfo/aspectj-users
>  >  >  >
>  >  >  _______________________________________________
>  >  >  aspectj-users mailing list
>  >  >  aspectj-users@xxxxxxxxxxx
>  >  >  https://dev.eclipse.org/mailman/listinfo/aspectj-users
>  >  >
>  >  _______________________________________________
>  >  aspectj-users mailing list
>  >  aspectj-users@xxxxxxxxxxx
>  >  https://dev.eclipse.org/mailman/listinfo/aspectj-users
>  >
>  _______________________________________________
>  aspectj-users mailing list
>  aspectj-users@xxxxxxxxxxx
>  https://dev.eclipse.org/mailman/listinfo/aspectj-users
>


Back to the top