Re: [ajdt-dev] aspectj nature on EJB/Web projects in WSAD 5.x?

[michael collier <acapela@xxxxxxxxx>]

>I'm glad the updater script worked for you :)  Are you using

>WSAD 5.1.2 or base WSAD 5.1?  We have been testing mainly on

>WSAD 5.1.2.

 

development in general is with "base" 5.1 right now.

 

we have one of our developers investigating 5.1.2, uprated to J2SE 1.4, working through integration issues. i will coordinate with him, and see if i can give 5.1.2 a try.

 

>...there is a known bug in WSAD when working with EJB projects
>that have the AspectJ nature.  The problem is that the

>deployment tool for the EJB asks the project for the Java

>builder...

 

yes. i had already rummaged my workspace, and found the relevant logfile. FWIW, the exception is as follows (i expect you already have all of this, just want to make certain we don't somehow have a new problem):

 

-----

!ENTRY org.eclipse.ajdt.ui 4 0 Oct 18, 2004 12:36:16.61
!MESSAGE Compile failed.
!STACK 0
java.lang.NullPointerException
 at java.lang.Throwable.<init>(Throwable.java)
 at java.lang.Throwable.<init>(Throwable.java)
 at java.lang.NullPointerException.<init>(NullPointerException.java:63)
 at org.eclipse.jdt.internal.launching.JRERuntimeClasspathEntryResolver.resolveLibraryLocations(JRERuntimeClasspathEntryResolver.java:51)
 at org.eclipse.jdt.internal.launching.JRERuntimeClasspathEntryResolver.resolveRuntimeClasspathEntry(JRERuntimeClasspathEntryResolver.java:43)
 at org.eclipse.jdt.internal.launching.RuntimeClasspathEntryResolver.resolveRuntimeClasspathEntry(RuntimeClasspathEntryResolver.java:81)
 at org.eclipse.jdt.launching.JavaRuntime.resolveRuntimeClasspathEntry(JavaRuntime.java:879)
 at org.eclipse.ajdt.internal.ui.ajde.ProjectProperties.getClasspath(ProjectProperties.java:205)
 at org.eclipse.ajdt.internal.builder.Builder.build(Builder.java:150)
 at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:427)
 at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java)
 at org.eclipse.core.runtime.Platform.run(Platform.java)
 at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:125)
 at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:181)
 at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:191)
 at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:151)
 at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java)
 at org.eclipse.core.runtime.Platform.run(Platform.java)
 at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:165)
 at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:265)
 at org.eclipse.core.internal.resources.Project.build(Project.java:85)
 at org.eclipse.ui.actions.BuildAction.invokeOperation(BuildAction.java:156)
 at org.eclipse.ui.actions.WorkspaceAction.execute(WorkspaceAction.java:122)
 at org.eclipse.ui.actions.WorkspaceAction$1.execute(WorkspaceAction.java:279)
 at org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(WorkspaceModifyOperation.java:71)
 at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1595)
 at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:85)
 at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:101)

-----

looks like what you expected, no builder in the classpath at runtime. unfortunately, just about everything we want to do with aspectj relates to EJB in some fashion. looks like this approach is a non-starter right now.

 

with regard to an ant external tools builder:

 

>Interestingly I've never seen anyone set it up in this

>way - it should *work* but I've never seen it used before.

 

if there is an example ajc invocation (i.e. command line), example ant XML, or any resources at all that you could suggest that would get us close, that would be a great help. something resembling this, that works external to WSAD, might be adaptable to run as an external builder in WSAD.

 

this would be our preferred solution anyway (maintaining the aspectj project(s) seperately, and "covering" other projects with it); it would relieve developers from having to incorporate ajdt unless they were directly developing aspects (they could simply not check out the aspectj project).

 

thanks.

 

mike