Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » AspectJ » AJDT fiddling with the Java Build path?
AJDT fiddling with the Java Build path? [message #41696] Mon, 04 October 2004 09:26 Go to next message
Michael Moser is currently offline Michael MoserFriend
Messages: 914
Registered: July 2009
Senior Member
I have a strange observation:

apparently since I converted a former Java Project to an AspectJ
project I noticed that "something" is fiddling with the build path
(right click on project => Properties => Java Build Path) of that
project:

I repeatedly now observed that all project imports (second tab at the
right "Projects") get unchecked and instead I get corresponding new
entries on the "Libraries" tab pointing to <project>/build/classes.

Who/which component is changing this and why?

Michael
Re: AJDT fiddling with the Java Build path? [message #41759 is a reply to message #41696] Mon, 04 October 2004 09:51 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: hawkinsh.uk.ibm.com

Michael Moser wrote:

> I have a strange observation:

> apparently since I converted a former Java Project to an AspectJ
> project I noticed that "something" is fiddling with the build path
> (right click on project => Properties => Java Build Path) of that
> project:

> I repeatedly now observed that all project imports (second tab at the
> right "Projects") get unchecked and instead I get corresponding new
> entries on the "Libraries" tab pointing to <project>/build/classes.

> Who/which component is changing this and why?

> Michael

Hi Michael,

There has been a lot of discussion in the last few months about what type
of dependencies there should be between projects when an AJ project is
involved. The problem is all because when Java projects depend on AJ
projects, the Java builder decides that it's not worth building the java
project because it doesn't understand the AJ project.

We were advised not to use project dependencies, and instead replace them
with class folder dependencies. This is the behaviour you're seeing (and
is in AJDT 1.1.11 and 1.1.12). Unfortunately, this leads to a number of
special cases which are broken when the dependencies are class folder, but
work when you have project dependencies. We've had various discussions
about this and have decided to revert to keeping the dependencies as
defined by the user. The remaining failing scenario can be found in the
following bug report:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=73435

The dev releases of AJDT remove the work done to convert to class folder
dependencies, and the lastest version can be found at the following update
site:

http://download.eclipse.org/technology/ajdt/30/dev/update

This will therefore be included in the 1.2 M1 release of AJDT.

Hope this helps,

Thanks, Helen
Re: AJDT fiddling with the Java Build path? [message #41815 is a reply to message #41759] Mon, 04 October 2004 10:22 Go to previous message
Michael Moser is currently offline Michael MoserFriend
Messages: 914
Registered: July 2009
Senior Member
"Helen Hawkins" <hawkinsh@uk.ibm.com> wrote in message
news:cjr6ei$f78$1@eclipse.org...
> ...
> We were advised not to use project dependencies, and instead replace
them
> with class folder dependencies. This is the behaviour you're seeing
(and
> is in AJDT 1.1.11 and 1.1.12). Unfortunately, this leads to a number
of
> special cases which are broken when the dependencies are class
folder, but
> work when you have project dependencies. We've had various
discussions
> about this and have decided to revert to keeping the dependencies as
> defined by the user.

Ahaa! I had just returned from an almost 2 months long
leave-of-absence and so hadn't been aware of that discussion. When I
had returned I had upgraded directly from 1.1.10 to 1.1.12 and this is
why I was now caught by surprise about this behaviour. Thanks for the
explanation!

> The dev releases of AJDT remove the work done to convert to class
folder
> dependencies, and the lastest version can be found at the following
update
> site:
>
> http://download.eclipse.org/technology/ajdt/30/dev/update
>
> This will therefore be included in the 1.2 M1 release of AJDT.

I will certainly have a look at this.

> Hope this helps,


Absolutely!

Thanks,
Michael
Re: AJDT fiddling with the Java Build path? [message #583623 is a reply to message #41696] Mon, 04 October 2004 09:51 Go to previous message
Eclipse UserFriend
Originally posted by: hawkinsh.uk.ibm.com

Michael Moser wrote:

> I have a strange observation:

> apparently since I converted a former Java Project to an AspectJ
> project I noticed that "something" is fiddling with the build path
> (right click on project => Properties => Java Build Path) of that
> project:

> I repeatedly now observed that all project imports (second tab at the
> right "Projects") get unchecked and instead I get corresponding new
> entries on the "Libraries" tab pointing to <project>/build/classes.

> Who/which component is changing this and why?

> Michael

Hi Michael,

There has been a lot of discussion in the last few months about what type
of dependencies there should be between projects when an AJ project is
involved. The problem is all because when Java projects depend on AJ
projects, the Java builder decides that it's not worth building the java
project because it doesn't understand the AJ project.

We were advised not to use project dependencies, and instead replace them
with class folder dependencies. This is the behaviour you're seeing (and
is in AJDT 1.1.11 and 1.1.12). Unfortunately, this leads to a number of
special cases which are broken when the dependencies are class folder, but
work when you have project dependencies. We've had various discussions
about this and have decided to revert to keeping the dependencies as
defined by the user. The remaining failing scenario can be found in the
following bug report:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=73435

The dev releases of AJDT remove the work done to convert to class folder
dependencies, and the lastest version can be found at the following update
site:

http://download.eclipse.org/technology/ajdt/30/dev/update

This will therefore be included in the 1.2 M1 release of AJDT.

Hope this helps,

Thanks, Helen
Re: AJDT fiddling with the Java Build path? [message #583651 is a reply to message #41759] Mon, 04 October 2004 10:22 Go to previous message
Michael Moser is currently offline Michael MoserFriend
Messages: 914
Registered: July 2009
Senior Member
"Helen Hawkins" <hawkinsh@uk.ibm.com> wrote in message
news:cjr6ei$f78$1@eclipse.org...
> ...
> We were advised not to use project dependencies, and instead replace
them
> with class folder dependencies. This is the behaviour you're seeing
(and
> is in AJDT 1.1.11 and 1.1.12). Unfortunately, this leads to a number
of
> special cases which are broken when the dependencies are class
folder, but
> work when you have project dependencies. We've had various
discussions
> about this and have decided to revert to keeping the dependencies as
> defined by the user.

Ahaa! I had just returned from an almost 2 months long
leave-of-absence and so hadn't been aware of that discussion. When I
had returned I had upgraded directly from 1.1.10 to 1.1.12 and this is
why I was now caught by surprise about this behaviour. Thanks for the
explanation!

> The dev releases of AJDT remove the work done to convert to class
folder
> dependencies, and the lastest version can be found at the following
update
> site:
>
> http://download.eclipse.org/technology/ajdt/30/dev/update
>
> This will therefore be included in the 1.2 M1 release of AJDT.

I will certainly have a look at this.

> Hope this helps,


Absolutely!

Thanks,
Michael
Previous Topic:Problem with AspectJ syntax: "no match for this type name"
Next Topic:Problem with AspectJ syntax: "no match for this type name"
Goto Forum:
  


Current Time: Fri Apr 19 07:15:23 GMT 2024

Powered by FUDForum. Page generated in 0.01737 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top