Continue the work on Mojohaus vs. Aspectj.dev

[bmarwell]

Hi Alex,

it is not hard to get commit access to mojohaus.
If you are interested, just ping here in again: https://groups.google.com/g/mojohaus-dev/c/1_CTFryUqys/m/goEZILj7BQAJ

WDYT?

Best regards,
Ben

[kriegaex]

Thanks for reaching out, Ben. The timing could not be worse, though. It is kind of surprising to get a reaction the very day I released the plugin with group ID dev.aspectj for the first time on Maven Central and announced it on the AspectJ mailing list.

Actually, the first time someone asked for Java 9 support under mojohaus/aspectj-maven-plugin#24 for the plugin, was in March 2017. Since November 2017, when there were RC releases of AspectJ 1.9.0, people asked the maintainer to support it. Nothing happend, up to this day in May 2021 the plugin only supports Java 8.

In November 2018, Nick Wong opened his PR mojohaus/aspectj-maven-plugin#45 for supporting Java 11. By then, the original maintainer did not even respond anymore. Neither he nor Mojohaus tried to resolve the situation that he was simply too busy to continue maintaining the plugin. No blame to David, life happens and priorities change. Anyway, Mojohaus as an organisation failed. People - myself included - have been asking, appealing, pleading.

In December 2018, Nick published his fork on Maven Central and later talked to JetBrains in order to make them recognise the plugin in IntelliJ IDEA.

In January 2020, plugin version 12.6 supported Java 13. By that time, I was involved a bit, too, trying to contact David Karlsen, the original maintainer. After a few tries, he responded once per e-mail, saying he was busy, but would be willing to accept PRs, which never happened. He also said he would like to welcome Nick and me on the team, which also never happened. I also tried to suggest to him to reach out to Mojohaus in order to hand over to Nick. At the time, I was not interested in becoming a maintainer, because I have zero knowledge about Maven plugins, which has not changed substantially since then.

Earlier this year, Nick told me at mojohaus/aspectj-maven-plugin#45 (comment), that he is no longer available as a maintainer and recommended me to fork again, which I did. For now I am still using a Mojohaus parent POM and have not changed much in the plugin, but I did upgrade it to Java 16 - remember, the original is still at Java 8! - and published it yesterday. I also made sure that IntelliJ IDEA is going to recognise the new group ID by talking to JetBrains, like Nick did before for his fork.

This was a long and painful journey. I even pay for the aspectj.dev domain and had to work through a process to get the corresponding group ID dev.aspectj approved by Sonatype, so I am able to publish on Maven Central. Nick must have gone through the same process before for com.nickwongdev. In the meantime, even AspectJ maintainer Andy Clement tried to reach out to someone at Mojohaus, but also without result, I guess.

it is not hard to get commit access to mojohaus.

Well, it certainly does not seem so. It definitely did not work for more than three years to even get a simple PR (which is outdated now) accepted into a Mojohaus project. Actually, I would have welcomed the invitation until not so long ago, even though I am afraid of yet another OSS organisation with tedious processes, micro-managing code reviews, IP trail legal reviews obstructing release processes etc. I might have accepted all that for the benefit of the AspectJ community, because I love AspectJ, even though I never wanted the responsibility for this plugin and certainly not the ceremony of working inside an OSS organisation. (Maybe Mojohaus is very agile compared to Apache and Eclipse and my fears are unfounded, I cannot say.)

Today, having seen myself forced into forking the plugin, at least after having invested time and a little amount of money (for the domain name), I have the freedom to commit whatever I want and to release on my own terms whenever I want. I am independent of people running legal departments, CI servers, code review systems or Jira instances. You might understand, that I am not feeling so inclined to kick all my efforts into the trash just so as to get that shiny org.codehaus.mojo group ID attached to the plugin. At this point, Mojohaus would have to actively reach out to me, explain the benefits of "coming home" with the plugin and convince me that I would rather be supported than impeded by OSS organisational ceremony when working under their umbrella. For now, I would rather appreciate them to officially retire the plugin and point to my GitHub repository, endorsing it as the official successor. They definitely did not care about the plugin in the last few years.

[bmarwell]

Hi Alex,

sorry for reaching out just right now. I was trying to pull in your dependency yesterday, probably just before you uploaded it. I opened this issue because I thought a maven central release would be more likely this way.

Well, I got invited to mojohaus multiple times now, but I am also an Apache committer and PMC, and this are mostly the same people working there. I am sorry to hear that you made these experiences. I saw some dead threads on google groups.

While Mojohaus does have some advantages, e.g. domain, workflows, access, etc. I can really see your point. I will talk to some people to see if we can make one of your proposals happen (dev-aspectj becoming the new upstream OR an invitation) – whatever makes more sense. I do fully understand your point, and I (personally) have no objections making this repo the upstream repo. I will see what I can do. Any way, the primary goal should be to not confuse users (like me, I came here as a user), so both ways would work for me.

Thanks for the insights,
Ben.

[kriegaex]

Thanks for your friendly and considerate reply, Ben.

Any way, the primary goal should be to not confuse users

Which is why this morning (local time) I generated new plugin documentation on GitHub Pages directly for this project, instead of pointing to the outdated Mojohaus docs from the main read-me file. The acknowledgements for Codehaus, Mojohaus and Nick Wong both in

• the project history section and
• the licence file

are there, though, which is not just a matter of IP (intellectual property) trail but IMO also one of professional courtesy.

[bmarwell]

Great. Btw: Same timezone, same country. ;-)

So, why not try moving forward here.
I created a thread at https://groups.google.com/g/mojohaus-dev/c/TbCpyd6OgTE. I also pinged some ASF committers in the Slack, so let's see what happens.

I will see if this plugin works for Shiro: https://github.com/apache/shiro/tree/main/support/aspectj. I will merge the PR soon.
Sadly, the previous one did try to find a file jrt-fs.jar. I do not know if this plugin will do the same. Thus I created #2. We test Shiro on different JVMs, because OpenJ9 does not always contain all the aliases that Hotspot ships with. Hotspot often contains more stuff than needed for Java certification. I will not open an issue, because I do not know if this has been resolved with your plugin. I want to wait for you to merge my PR first.

Here is the stack trace FYI:

org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal com.nickwongdev:aspectj-maven-plugin:1.12.6:compile (aspectj-compile) on project shiro-aspectj: AJC compiler errors:
abort ABORT -- (IllegalStateException) Unexpectedly unable to initialize a JRT filesystem
Unexpectedly unable to initialize a JRT filesystem
java.lang.IllegalStateException: Unexpectedly unable to initialize a JRT filesystem
	at org.aspectj.weaver.bcel.ClassPathManager$JImageEntry.<init>(ClassPathManager.java:370)
	at org.aspectj.weaver.bcel.ClassPathManager.addPath(ClassPathManager.java:113)
	at org.aspectj.weaver.bcel.ClassPathManager.<init>(ClassPathManager.java:87)
	at org.aspectj.weaver.bcel.BcelWorld.<init>(BcelWorld.java:285)
	at org.aspectj.ajdt.internal.core.builder.AjBuildManager.initBcelWorld(AjBuildManager.java:841)
	at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performBuild(AjBuildManager.java:253)
	at org.aspectj.ajdt.internal.core.builder.AjBuildManager.batchBuild(AjBuildManager.java:189)
	at org.aspectj.ajdt.ajc.AjdtCommand.doCommand(AjdtCommand.java:114)
	at org.aspectj.ajdt.ajc.AjdtCommand.runCommand(AjdtCommand.java:60)
	at org.aspectj.tools.ajc.Main.run(Main.java:371)
	at org.aspectj.tools.ajc.Main.runMain(Main.java:248)
	at org.codehaus.mojo.aspectj.AbstractAjcCompiler.execute(AbstractAjcCompiler.java:550)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
	at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:957)
	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:289)
	at org.apache.maven.cli.MavenCli.main(MavenCli.java:193)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
Caused by: java.io.IOException: /opt/hostedtoolcache/java_adopt-openj9_jdk/11.0.11-9/x64/lib/jrt-fs.jar not exist
	at java.base/jdk.internal.jrtfs.JrtFileSystemProvider.newFileSystem(JrtFileSystemProvider.java:118)
	at java.base/jdk.internal.jrtfs.JrtFileSystemProvider.newFileSystem(JrtFileSystemProvider.java:106)
	at java.base/java.nio.file.FileSystems.newFileSystem(FileSystems.java:337)
	at java.base/java.nio.file.FileSystems.newFileSystem(FileSystems.java:286)
	at org.aspectj.weaver.bcel.ClassPathManager$JImageEntry.<init>(ClassPathManager.java:360)
	... 33 more

[kriegaex]

Great. Btw: Same timezone, same country. ;-)

Are you sure? I am in Southeast Asia ATM. ;-)

I created a thread at https://groups.google.com/g/mojohaus-dev/c/TbCpyd6OgTE. I also pinged some ASF committers in the Slack, so let's see what happens.

Cool, thanks.

> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal com.nickwongdev:aspectj-maven-plugin:1.12.6:compile (aspectj-compile) on project shiro-aspectj: AJC compiler errors:
> abort ABORT -- (IllegalStateException) Unexpectedly unable to initialize a JRT filesystem
> Unexpectedly unable to initialize a JRT filesystem
> java.lang.IllegalStateException: Unexpectedly unable to initialize a JRT filesystem
> 	at org.aspectj.weaver.bcel.ClassPathManager$JImageEntry.<init>(ClassPathManager.java:370)
> 	at org.aspectj.weaver.bcel.ClassPathManager.addPath(ClassPathManager.java:113)
> 	at org.aspectj.weaver.bcel.ClassPathManager.<init>(ClassPathManager.java:87)
> 	at org.aspectj.weaver.bcel.BcelWorld.<init>(BcelWorld.java:285)
> (...)
> Caused by: java.io.IOException: /opt/hostedtoolcache/java_adopt-openj9_jdk/11.0.11-9/x64/lib/jrt-fs.jar not exist
> 	at java.base/jdk.internal.jrtfs.JrtFileSystemProvider.newFileSystem(JrtFileSystemProvider.java:118)
> 	at java.base/jdk.internal.jrtfs.JrtFileSystemProvider.newFileSystem(JrtFileSystemProvider.java:106)
> 	at java.base/java.nio.file.FileSystems.newFileSystem(FileSystems.java:337)
> 	at java.base/java.nio.file.FileSystems.newFileSystem(FileSystems.java:286)
> 	at org.aspectj.weaver.bcel.ClassPathManager$JImageEntry.<init>(ClassPathManager.java:360)
> 	... 33 more

I am unaware of any changes there while I was working on AspectJ 1.9.7. I just tried to make it compatible with Java 15/16, but did not change any functionality, because I do not have the necessary knowledge in AspectJ internals, just lately having started to contribute. Honestly, I never tried running AspectJ on anything other than Oracle JDK or OpenJDK. @aclement would know much more about this. But I still do see class ClassPathManager.JImageEntry in the code base, and there were no changes. See here. So that would be a core AspectJ issue rather than an AspectJ Maven one. You might want to create an MCVE and open an issue there.

[bmarwell]

I am unaware of any changes there while I was working on AspectJ 1.9.7. I just tried to make it compatible with Java 15/16, but did not change any functionality, because I do not have the necessary knowledge in AspectJ internals, just lately having started to contribute. Honestly, I never tried running AspectJ on anything other than Oracle JDK or OpenJDK. @aclement would know much more about this. But I still do see class ClassPathManager.JImageEntry in the code base, and there were no changes. See here. So that would be a core AspectJ issue rather than an AspectJ Maven one. You might want to create an MCVE and open an issue there.

It is not an aspectj issue, I believe. Should be fixed by #6.

[olamy]

@kriegaex why not simply asking on the mailing list? perso I received too many gh notifications to they go to a folder which I read later....
anyway you should have received a gh invite to collaborate.

[kriegaex]

@olamy, because I did not know that such a mailing list exists or that it would be the place to ask. Before I join, please explain why I should become a Mojohaus committer after all the frustrations and efforts of the past. With all due respect: Sell it to me, please. We tried to get a simple PR merged for 2.5 years, and now one day after my first Maven Central release, after setting up a documentation site, while being in the process of setting up CI on GitHub etc., someone kindly invites me to throw it all away.

Please also provide a link where I can read about rules, procedures, restrictions etc., because of all those I want as few as possible. I just want to be able to compile my AspectJ projects with Maven and as a side effect provide other users with the same benefit.

Thank you. I know, this situation was nobody's bad intention and sh** happens, but it occurred due to a mess-up (as in negligence) of one or several persons, processes, tools or whatever. IMO, that it developed thus far, is inexcusable. I apologise if you find my response cheeky, but I really need more than a belated invitation. I need good reasons for dumping my investment and giving up freedom I now possess, because I did some work and thus IMO earned it.

[bmarwell]

Well, I can try.
For one, there are a lot of folks which might not want to migrate to another groupId for various reasons. Probably silly reasons, but they exist.

The other reason why you should join mojohaus is: Some things you did claim are not true:

• Not every PR needs a review. A review can also be done later.
• The documentation shows the mailing lists do exist: http://www.mojohaus.org/aspectj-maven-plugin/mail-lists.html
• There has been at least SOME activity on the mailing lists: https://groups.google.com/g/mojohaus-dev/search?q=aspectj
• There is no need to "dump" your investment, we can pull in the changes you made. Or do you mean monetary for your webspace and domain?
• Cannot talk much about the freedom you might need to give up, but I am sure there is not much to give up. No need for reviewing each single and small PR, you can release whenever you want – I guess? => https://www.mojohaus.org/development/performing-a-release.html

after setting up a documentation site, while being in the process of setting up CI on GitHub etc., someone kindly invites me to throw it all away.
Yes it is true, the PR is open for 2.5 years now, but nothing needs to be thrown away. We can pull in your changes easily.

Another benefit is: It is much easier to attract developers.

But the best reason is what you wrote yourself:

I know, this situation was nobody's bad intention and sh** happens

So let's make the best out of it, shall we?

[olamy]

@kriegaex there is nothing to sell here. I'm not a company trying to hire someone...
We are supposed to be a group of person who spend their spare time on opensource projects.
And sometimes they don't have time or their interest changed....
The spirit is we do that to help people (not to get rewarded).
If you want to participate at mojohaus that's fine if not it's fine as well.
The project have an ASF license so not a problem at all you can fork etc...
But remember it's an opensource project under ASF license so if you do something in a fork it will stay under the same license and everybody is able to merge/cherrypick it somewhere else including in the original source code.

[philsttr]

For what it's worth, I (as a user) would like to see it merged back to the original repo / group id. I feel more comfortable pulling in dependencies from mojohaus, because at least they have a process (however ineffective it may be) for continuation whenever maintainers quit for whatever reason. With persistence and interest from community members, I believe becoming a maintainer can be achieved. I say this, even though I have my own experience of being denied when I offered to help.

Having said that, thank you @kriegaex for doing everything you have done so far. I'll respect your decision, whatever you decide.

[kriegaex]

@bmarwell:

Some things you did claim are not true

I did not claim anything, I said I was afraid it might be similar to other OSS projects I lately tried to contribute to, where everything is slow and bureaucratic. I just listed some of the things I want to avoid. If Mojohaus is super agile, great. Reality since 2017 for this plugin was different, though. I explained the details already, and they are facts.

https://www.mojohaus.org/development/performing-a-release.html

That is quite a lot. Also, that page links to development guidelines, then code styles. The guidelines could be much worse, but there is lots of baggage I do not need for this small project.

Yes it is true, the PR is open for 2.5 years now, but nothing needs to be thrown away. We can pull in your changes easily.

That offer should have come at least a year ago, better two.

Another benefit is: It is much easier to attract developers.

Well, I am one, so is Nick. We were not attracted but disheartened and scared off.

---

@olamy:

there is nothing to sell here. I'm not a company trying to hire someone...

Fine, then don't sell it. IMO, you always have to sell your idea to someone in life, if you want to convince him. If that is asking too much, it means the idea is not so important to the person unwilling to sell it, which is also good to know.

We are supposed to be a group of person who spend their spare time on opensource projects.

Just like me.

And sometimes they don't have time or their interest changed....

If that happens, you have a responsibility and should actively pursue a hand-over and try to attract new maintainers, either within the existing group or outside of it. That is part of the "O" in "OSS". If the one maintainer of a project is hit by a truck and cannot hand over by herself, the rest of the group should take care of it. A group is not worth much, if it is not a team, i.e. more than the sum of its constituent parts.

If you want to participate at mojohaus that's fine if not it's fine as well.

At this point, I do not feel like I wish to. I am quite comfortable in the current situation - a situation which I was forced into, please remember.

But remember it's an opensource project under ASF license so if you do something in a fork it will stay under the same license and everybody is able to merge/cherrypick it somewhere else including in the original source code.

Are you threatening me to appoint another maintainer and cannibalise my work back into a project that for years was factually dead? Remember, Nick and I wanted to contribute back and were ignored. Now I do not want that anymore. I am reapating what I said to Ben before you entered the discussion:

I would rather appreciate them to officially retire the plugin and point to my GitHub repository, endorsing it as the official successor. They definitely did not care about the plugin in the last few years.

So my friendly request to you, Olivier, is to help take care of retiring the already dead Mojohaus project, naming this one as the successor. I think, we should all try to avoid a schism and tell the user community where to find the plugin.

If Mojohaus refuses to retire the plugin, I would rather become a member there than risk having two plugins which both publish releases, even merging stuff from one another. That would be chaotic. In that case, the greater good would be served better by me becoming a Mojohaus committer, but I would do so reluctantly and not be happy about it at all. Is that what you want, getting new committers by coercion? I don't think so.

[hboutemy]

Hi @kriegaex , I know we've failed for some time to add people who want to involve seriously: please help us by joining your forces with the whole team. It's a long run, being together will be easier over years: "If you want to go fast, go alone. If you want to go far, go together"

[olamy]

@kriegaex Fair enough it's your decision. But we will be happy to have you here
@philsttr do you want to join and help?

[bmarwell]

It is not an issue with this project, so I am closing this. Feel free to continue adding comments as needed. :-)