Make product independent of Maven Compiler Plugin

kriegaex commented 3 years ago

Currently, m2eclipse-ajdt fails to import projects when Maven Compiler executions are deactivated. As background information, here is a partial transcript of previous e-mail conversations between @kriegaex and @joker1:

@kriegaex wrote:

BTW, I just tried without deactivating MCP's default executions and by explicitly and redundantly setting source and target there:
<plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-compiler-plugin</artifactId>
 <version>3.8.1</version>
 
 
 <configuration>
  <source>11</source>
  <target>11</target>
 </configuration>
</plugin>
I can confirm that now it works, so for now that is at least a workaround.

@kriegaex wrote:
The AspectJ compiler (AJC) is a full replacement of Java, which is why AspectJ Maven Plugin (AMP) can be used as a full replacement of Maven Compiler Plugin (MCP) as well. This is why I deactivated all MCP in my sample project in order to find out, which plugin settings are imported correctly and which are not. BTW, I also often deactivate MCP in real projects, because I want ACJ to compile all classes and avoid two compiler runs. Javac does not know what AJC might want to weave into the classes it compiles.

Please note that AJC and also AMC have full sets of compiler parameters, such as source, target, compliance level, source and target folders, all of which have defaults. Furthermore, plugins can have dependencies, for AMP most notably you can override the dependency to aspectjtools.jar, if you want to use or upgrade to a certain AspectJ version. This should be respected by the m2e connector too and end up with correct settings in Eclipse. Moreover, there are the weaveDependencies which should end up on the AJC inpath (binary post-compile weaving!) and the aspectLibraries and aspectDirectory settings, which should end up on the AJC 'aspectpath'. Same goes for all other plugin option, all of which should be mapped to the corresponding AJDT project settings.

If any of those options are not imported correctly, it simply means that the AspectJ m2e connector is either broken or an incomplete product, unfit for productive use. This would of course not be your fault,because you simply forked prior work and kept it alive for your own use, providing it as-is on a best effort basis. But if you are interested, we can collaborate in order to get this thing into an acceptable state. I can tell you what the expected result should be and provide example AMP configurations, you can fix or implement it. The alternative would be that you introduce me into the code base as a mentor, as well as you can, so I can contribute to it. I have no idea about the Eclipse API and all things OSGi and also no big interest. I am contributing to so many AspectJ-related projects already, I don't know where to find the time to do more. But that AspectJ as a long-standing Eclipse project does not work nicely in Eclipse when used with the quasi standard Maven plugin, does not look good for sure. Having to tell users to configure MCP in order to get AMP running, is weird.

@joker1 wrote:
I took a deeper look at the implementation. I might be able to use m2eclipse JavaConfigurator to make changes you need when not using compiler-plugin. I think this plugin has been originally written so that it uses only aspectDirectory configuration parameter as source directory.

@joker1 wrote:
Actually.. your use case is aspectj compilation without using maven-compiler-plugin at all? Why is that?

I'm always using the compiler-plugin which takes care of source/target folders and code compliance level.

@joker1 wrote:
I am able to reproduce several problems with your project.

Most of the problems are caused by this:
<execution>
 <id>default-compile</id>
 <phase>none</phase>
</execution>
<execution>
 <id>default-testCompile</id>
 <phase>none</phase>
</execution>
I think this messes up m2eclipse somehow and is not related to m2eclipse-ajdt.

Eclipse does not correctly set source/target folders and aspectjrt dependency because of this. I didn't fully understand your problem previously because it has nothing to do with this plugin.

Only the lifecycle mapping problem is related to this plugin and it is now fixed. I'm also using eclipse 2021-06.

@kriegaex wrote:

0.14.4 does the same with dev.aspectj as the previous version did with com.nickwongdev, i.e. the 4 problems I mentioned.

Please note that I use Eclipse 2021-06. Which version are you using? Furthermore, I am using a new AJDT version I mentioned in my answer here:

https://stackoverflow.com/a/68569168/1082681

Could these two factors cause the problem?

This plugin does not add any runtime dependencies. Are those even required for compilation and where exactly should these dependencies be added by this plugin?

I am surprised you as an AspectJ user are asking this: AspectJ always needs aspectjrt.jar on the classpath, just like we need it in the Maven POM. If you simply create a new AspectJ project in Eclipse with AJDT, it is added automatically. Shouldn't the Maven connector do the same? And shouldn't it know how to make source and target paths as well as source and target levels? Otherwise the connector is not worth much.

I am attaching a super simple Maven project. That one causes the problems I described. My Eclipse default JDK is 16. If it works for you and you can simply run class 'Application' after Maven import and also see the aspect output, then maybe I need to try and recompile the plugin against Eclipse dependencies from 2021-03 (I used those for AJDt, because otherwise AJDT would no longer work in Eclipse 2021-03/06). Maybe there have been API changes.

@joker1 wrote:

I fixed the lifecycle mapping with dev.aspectj and uploaded new version.

Please update to version 0.14.4 and test if dev.aspectj works (works for me).

I can help with your other problems too but I need more details about what you are doing.

Also, please note that I am not the original author of this plugin and most of the source code is several years old. I mostly updated the plugin packaging logic for modern eclipse. There is not much java source code though so I may be able to help with that too.

@joker1 wrote:

You seem to have several problems some of which might not be related to this plugin. This plugin simply binds the maven/eclipse compile process to aspectj-maven-plugin.

The fact that are you are unable to use dev.aspectj is related to this plugin. I can test it later to find any problems (I'm still using the com.nickwongdev version personally).

This plugin does not add any runtime dependencies. Are those even required for compilation and where exactly should these dependencies be added by this plugin?

I don't think any source/target folder and code compliance level related problems are caused by this plugin. I assume that you import an existing maven project to eclipse and it shows wrong folders and code compilance level. These steps are handled by M2Eclipse (this plugin simply handles the aspectj compilation).

@kriegaex wrote:

Unfortunately, the behaviour does not change for dev.aspectj. If I switch to com.nickwongdev, at least the unmapped Maven goal errors disappear, but the wrong folders are imported (source folder 'src' instead of 'src/main/java', 'bin' instead of 'target/classes'). If I fix that manually, still the import did not add the AspectJ runtime dependency, only the AspectJ nature without aspectjrt. Next problem is that the code compliance level in my POM (Java 11) is not imported, instead I get the global configuration default of Java 1.8. After fixing those 4 things (source, target folders, library and compliance level), I can finally compile and run my project. I.e., I have to set up 90% by myself instead of the Maven connection importing the plugin settings.

Do you have any idea, why I have those problems with com.nickwongdev and why dev.aspectj is still not working at all?

@joker1 wrote:

I was able to create new releases and upload those to repo.t5.fi repositories. (had to use --offline switch with maven, had everything cached locally).

You can try to install the new version

@joker1 wrote:

The problem seems to be that I forgot to create/upload new release after I added the dev.aspectj plugin to the list of supported groupId values.

I will create new release and upload it to repo.t5.fi as soon as possible.

@kriegaex wrote:

I am reaching out on behalf of the AspectJ development team. Maven integration for AJDT is broken, but not maintained within the AspectJ team. However, it seems you are maintaining this project:

https://github.com/joker1/m2eclipse-ajdt

I successfully installed the plugin from the 2020-12 update site, but it does not seem to work as expected in my Eclipse 2021-06 installation. When trying to install a simple Maven project using the dev.aspectj plugin fork (my own one), which your read-me says is supported, I end up with the usual "Plugin execution not covered by lifecycle configuration: dev.aspectj:aspectj-maven-plugin:1.13:compile" error message the plugin is supposed to fix. The imported project does not have a Java or AspectJ nature, only Maven. No paths or libraries are configured correctly.

Do you have any idea, what could be wrong here? Can we somehow collaborate in order to get this fixed? Unfortunately, you deactivated issue creation for your repository, which is why I am contacting you directly.

joker1 commented 3 years ago

Use m2e-jdt as example how to implement the necessary features: https://github.com/eclipse-m2e/m2e-core/tree/master/org.eclipse.m2e.jdt

kriegaex commented 3 years ago

That might be a good idea, because the AspectJ Compiler is a fork of the Eclipse Java Compiler, which is part of JDT Core. I am unsure how close AJDT is to JDT, though. Anyway, I hope you do not have to re-invent to wheel 100% and can take valuable information from m2e.jdt.

mpet commented 2 years ago

@joker1 is there any progress on this issue? I will test @kriegaex fix in the meantime.

joker1 / m2eclipse-ajdt

Make product independent of Maven Compiler Plugin #1