You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Dale Peakall (JIRA)" <ji...@codehaus.org> on 2009/05/05 14:48:44 UTC
[jira] Created: (MECLIPSE-558) Ignoring listed AspectJ dependencies
Ignoring listed AspectJ dependencies
------------------------------------
Key: MECLIPSE-558
URL: http://jira.codehaus.org/browse/MECLIPSE-558
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: AJDT support
Affects Versions: 2.6, 2.7
Reporter: Dale Peakall
When AJDT support is enabled, the plugin ignores any dependencies that include the term "aspectj" in the artifactId: these include aspectjrt.jar, aspectjweaver.jar and aspectjtools.jar. Instead the project gets created with a link to the AspectJ Runtime Library "Folder" which just contains aspectjrt.jar. However, if the project depends on the other AspectJ artifacts, e.g. aspectjweaver.jar (because it uses load-time-weaving) it is broken and no amount of POM tweaking will get it back in there.
Using the <ajdtVersion>none</ajdtVersion> is fine if the project doesn't include any aspects - but if it does it needs AJDT to compile the aspect - but also needs the other AspectJ artifacts (that were specified in the POM) to run Unit Tests etc.
At a minimum the plugin should be modified to only replace aspectjrt. However, I am generally uncomfortable with the whole replacement concept. As long as projects specify the appropriate dependencies then AJDT will be able to compile and run the project (i.e. the special "AspectJ Runtime Library" folder is not required). This will also ensure that a consistent version of AspectJ is used (the version provided by Eclipse need not be the same as specified in the POM).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-558) Ignoring listed AspectJ
dependencies
Posted by "Antoine Lochet (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MECLIPSE-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=179129#action_179129 ]
Antoine Lochet commented on MECLIPSE-558:
-----------------------------------------
Works great here too.
Thanks for the tip!
> Ignoring listed AspectJ dependencies
> ------------------------------------
>
> Key: MECLIPSE-558
> URL: http://jira.codehaus.org/browse/MECLIPSE-558
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: AJDT support
> Affects Versions: 2.6, 2.7
> Reporter: Dale Peakall
>
> When AJDT support is enabled, the plugin ignores any dependencies that include the term "aspectj" in the artifactId: these include aspectjrt.jar, aspectjweaver.jar and aspectjtools.jar. Instead the project gets created with a link to the AspectJ Runtime Library "Folder" which just contains aspectjrt.jar. However, if the project depends on the other AspectJ artifacts, e.g. aspectjweaver.jar (because it uses load-time-weaving) it is broken and no amount of POM tweaking will get it back in there.
> Using the <ajdtVersion>none</ajdtVersion> is fine if the project doesn't include any aspects - but if it does it needs AJDT to compile the aspect - but also needs the other AspectJ artifacts (that were specified in the POM) to run Unit Tests etc.
> At a minimum the plugin should be modified to only replace aspectjrt. However, I am generally uncomfortable with the whole replacement concept. As long as projects specify the appropriate dependencies then AJDT will be able to compile and run the project (i.e. the special "AspectJ Runtime Library" folder is not required). This will also ensure that a consistent version of AspectJ is used (the version provided by Eclipse need not be the same as specified in the POM).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-558) Ignoring listed AspectJ dependencies
Posted by "Arnaud Heritier (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MECLIPSE-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Arnaud Heritier updated MECLIPSE-558:
-------------------------------------
Fix Version/s: 2.8
> Ignoring listed AspectJ dependencies
> ------------------------------------
>
> Key: MECLIPSE-558
> URL: http://jira.codehaus.org/browse/MECLIPSE-558
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: AJDT support
> Affects Versions: 2.6, 2.7
> Reporter: Dale Peakall
> Fix For: 2.8
>
>
> When AJDT support is enabled, the plugin ignores any dependencies that include the term "aspectj" in the artifactId: these include aspectjrt.jar, aspectjweaver.jar and aspectjtools.jar. Instead the project gets created with a link to the AspectJ Runtime Library "Folder" which just contains aspectjrt.jar. However, if the project depends on the other AspectJ artifacts, e.g. aspectjweaver.jar (because it uses load-time-weaving) it is broken and no amount of POM tweaking will get it back in there.
> Using the <ajdtVersion>none</ajdtVersion> is fine if the project doesn't include any aspects - but if it does it needs AJDT to compile the aspect - but also needs the other AspectJ artifacts (that were specified in the POM) to run Unit Tests etc.
> At a minimum the plugin should be modified to only replace aspectjrt. However, I am generally uncomfortable with the whole replacement concept. As long as projects specify the appropriate dependencies then AJDT will be able to compile and run the project (i.e. the special "AspectJ Runtime Library" folder is not required). This will also ensure that a consistent version of AspectJ is used (the version provided by Eclipse need not be the same as specified in the POM).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-558) Ignoring listed AspectJ
dependencies
Posted by "Dale Peakall (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MECLIPSE-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=179105#action_179105 ]
Dale Peakall commented on MECLIPSE-558:
---------------------------------------
Brilliant tip Aziz - worked a treat!
> Ignoring listed AspectJ dependencies
> ------------------------------------
>
> Key: MECLIPSE-558
> URL: http://jira.codehaus.org/browse/MECLIPSE-558
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: AJDT support
> Affects Versions: 2.6, 2.7
> Reporter: Dale Peakall
>
> When AJDT support is enabled, the plugin ignores any dependencies that include the term "aspectj" in the artifactId: these include aspectjrt.jar, aspectjweaver.jar and aspectjtools.jar. Instead the project gets created with a link to the AspectJ Runtime Library "Folder" which just contains aspectjrt.jar. However, if the project depends on the other AspectJ artifacts, e.g. aspectjweaver.jar (because it uses load-time-weaving) it is broken and no amount of POM tweaking will get it back in there.
> Using the <ajdtVersion>none</ajdtVersion> is fine if the project doesn't include any aspects - but if it does it needs AJDT to compile the aspect - but also needs the other AspectJ artifacts (that were specified in the POM) to run Unit Tests etc.
> At a minimum the plugin should be modified to only replace aspectjrt. However, I am generally uncomfortable with the whole replacement concept. As long as projects specify the appropriate dependencies then AJDT will be able to compile and run the project (i.e. the special "AspectJ Runtime Library" folder is not required). This will also ensure that a consistent version of AspectJ is used (the version provided by Eclipse need not be the same as specified in the POM).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-558) Ignoring listed AspectJ
dependencies
Posted by "Aziz Joumady (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MECLIPSE-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=178055#action_178055 ]
Aziz Joumady commented on MECLIPSE-558:
---------------------------------------
I had the same issue, and I resolved that by explicitly defining the used version.
<ajdtVersion>1.6.4</ajdtVersion>
The "AspectJ Runtime Library" is still referencing to the Eclipse library, but my other librairies (aspectjweaver in my case) are not filtered from the "Referenced Librairies", and now allow me to run my JUnit tests.
> Ignoring listed AspectJ dependencies
> ------------------------------------
>
> Key: MECLIPSE-558
> URL: http://jira.codehaus.org/browse/MECLIPSE-558
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: AJDT support
> Affects Versions: 2.6, 2.7
> Reporter: Dale Peakall
>
> When AJDT support is enabled, the plugin ignores any dependencies that include the term "aspectj" in the artifactId: these include aspectjrt.jar, aspectjweaver.jar and aspectjtools.jar. Instead the project gets created with a link to the AspectJ Runtime Library "Folder" which just contains aspectjrt.jar. However, if the project depends on the other AspectJ artifacts, e.g. aspectjweaver.jar (because it uses load-time-weaving) it is broken and no amount of POM tweaking will get it back in there.
> Using the <ajdtVersion>none</ajdtVersion> is fine if the project doesn't include any aspects - but if it does it needs AJDT to compile the aspect - but also needs the other AspectJ artifacts (that were specified in the POM) to run Unit Tests etc.
> At a minimum the plugin should be modified to only replace aspectjrt. However, I am generally uncomfortable with the whole replacement concept. As long as projects specify the appropriate dependencies then AJDT will be able to compile and run the project (i.e. the special "AspectJ Runtime Library" folder is not required). This will also ensure that a consistent version of AspectJ is used (the version provided by Eclipse need not be the same as specified in the POM).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MECLIPSE-558) Ignoring listed AspectJ dependencies
Posted by "nicolas de loof (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MECLIPSE-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
nicolas de loof closed MECLIPSE-558.
------------------------------------
Resolution: Fixed
Assignee: nicolas de loof
Completed: At revision: 825429
> Ignoring listed AspectJ dependencies
> ------------------------------------
>
> Key: MECLIPSE-558
> URL: http://jira.codehaus.org/browse/MECLIPSE-558
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: AJDT support
> Affects Versions: 2.6, 2.7
> Reporter: Dale Peakall
> Assignee: nicolas de loof
> Fix For: 2.8
>
>
> When AJDT support is enabled, the plugin ignores any dependencies that include the term "aspectj" in the artifactId: these include aspectjrt.jar, aspectjweaver.jar and aspectjtools.jar. Instead the project gets created with a link to the AspectJ Runtime Library "Folder" which just contains aspectjrt.jar. However, if the project depends on the other AspectJ artifacts, e.g. aspectjweaver.jar (because it uses load-time-weaving) it is broken and no amount of POM tweaking will get it back in there.
> Using the <ajdtVersion>none</ajdtVersion> is fine if the project doesn't include any aspects - but if it does it needs AJDT to compile the aspect - but also needs the other AspectJ artifacts (that were specified in the POM) to run Unit Tests etc.
> At a minimum the plugin should be modified to only replace aspectjrt. However, I am generally uncomfortable with the whole replacement concept. As long as projects specify the appropriate dependencies then AJDT will be able to compile and run the project (i.e. the special "AspectJ Runtime Library" folder is not required). This will also ensure that a consistent version of AspectJ is used (the version provided by Eclipse need not be the same as specified in the POM).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-558) Ignoring listed AspectJ
dependencies
Posted by "Owen Jacobson (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MECLIPSE-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=183147#action_183147 ]
Owen Jacobson commented on MECLIPSE-558:
----------------------------------------
Is there a mailing list thread or something that explains why the default ajdtVersion isn't "none"? From a dumb-user point of view, that seems like a mistake: 2.5.1 generates working Eclipse projects and 2.7 doesn't, without specific configuration to get back behaviour it used to have by default. If there's some specific thing that Eclipse is doing or is about to start doing that explains it, I'd love to know. :)
> Ignoring listed AspectJ dependencies
> ------------------------------------
>
> Key: MECLIPSE-558
> URL: http://jira.codehaus.org/browse/MECLIPSE-558
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: AJDT support
> Affects Versions: 2.6, 2.7
> Reporter: Dale Peakall
>
> When AJDT support is enabled, the plugin ignores any dependencies that include the term "aspectj" in the artifactId: these include aspectjrt.jar, aspectjweaver.jar and aspectjtools.jar. Instead the project gets created with a link to the AspectJ Runtime Library "Folder" which just contains aspectjrt.jar. However, if the project depends on the other AspectJ artifacts, e.g. aspectjweaver.jar (because it uses load-time-weaving) it is broken and no amount of POM tweaking will get it back in there.
> Using the <ajdtVersion>none</ajdtVersion> is fine if the project doesn't include any aspects - but if it does it needs AJDT to compile the aspect - but also needs the other AspectJ artifacts (that were specified in the POM) to run Unit Tests etc.
> At a minimum the plugin should be modified to only replace aspectjrt. However, I am generally uncomfortable with the whole replacement concept. As long as projects specify the appropriate dependencies then AJDT will be able to compile and run the project (i.e. the special "AspectJ Runtime Library" folder is not required). This will also ensure that a consistent version of AspectJ is used (the version provided by Eclipse need not be the same as specified in the POM).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira