Adopting the onejar-maven-plugin

[Ben M.]

Hello everyone,

probably everyone of us has heard of or used the onejar-maven-plugin.

Due to some design decisions of the spring-boot-maven-plugin I use it every now and then.

As there was no recent development, I asked the plugin author whether he would be willing to donate it to mojohaus. And yes, he would do so. He would also change the License to Apache v2.0 for us.

Here is the original (current) source code:

https://github.com/jolira/onejar-maven-plugin

There are also some import fragments from svn (google code) which needs cleaning up.

Let me know what you think.

- Ben

PS: We really need to update the submission instructions:

https://www.mojohaus.org/contribution/submitting-a-plugin.html

They still talk about Jira.

[Jochen Wiedmann]

In this particular case, I'd hope that we can keep the sources of
onejar itself, and the Maven plugin in a shared repository.

Jochen

> --
> You received this message because you are subscribed to the Google Groups "mojohaus-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mojohaus-dev...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/mojohaus-dev/011434aa-77a2-4e7d-9c54-146a087089d3n%40googlegroups.com.



--
Philosophy is useless, theology is worse. (Industrial Desease, Dire Straits)

[Ben M.]

Hi Jochen!

Thank you for considering donating/submitting your plugin to Mojohaus!

You probably mean the sources which are currently packaged in this jar files?

https://github.com/jolira/onejar-maven-plugin/tree/master/src/main/resources

That should be possible, but I haven't looked into it yet.

It is possible best to make two modules:

/pom.xml (aggregator root)

 `-- onejar-boot

|    `-- pom.xml (sources of one-jar-boot which go into the user's one-jar file)

`-- onejar-maven-plugin

     `-- pom.xml (same as we have, but without pre-compiled .jar files)

The advantage would be that we have everything compiled every time.

[Jochen Wiedmann]

On Thu, Jan 27, 2022 at 8:54 AM Ben M. <bmar...@gmail.com> wrote:

> The advantage would be that we have everything compiled every time.

That seems to be desirable to me. On the other hand, it would only
work, if Simon would agree to maintain this site, rather than his
Sourceforge repository.

Jochen

[Benjamin Marwell]

Which site?

We would host the usage on gh-pages like all other plugins.

Or do you speak of another site?

[Jochen Wiedmann]

On Thu, Jan 27, 2022 at 11:44 AM Benjamin Marwell <bmar...@gmail.com> wrote:

> We would host the usage on gh-pages like all other plugins.
> Or do you speak of another site?

No, I mean the same site. I am simply suggesting, that in this case we
would host not only the plugin, but also it's main dependency. (If
that is doable.)

Jochen

[Hervé Boutemy]

IIUC, it's not a question of site but source code:

onejar-maven-plugin imports one-jar-boot as binary jar https://github.com/jolira/onejar-maven-plugin/tree/master/src/main/resources

maintaining the plugin is nice, but we also need to have a maintained one-jar-boot, given it seems unmaintained for 10 years http://one-jar.sourceforge.net/index.php?page=downloads&file=source

--
You received this message because you are subscribed to the Google Groups "mojohaus-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojohaus-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mojohaus-dev/CAF8HOZLaCB0D2Evn6S%3DVkiwmG5Ge5shyf63Z_%2BkYiJJ8GezWOQ%40mail.gmail.com.

[Alexander Kriegisch]

My two cents, because I like to use this plugin for easily creating
executable JARs for my AspectJ applications:

I agree that not just the Maven plugin but also OneJAR itself ought to
be maintained together. Whether it is OK for Mojohaus to maintain them
as two modules of the same project, is up to you guys to decide. Maybe
you have rules stating that only Maven plugins as such ought to be part
of Mojohaus.

Technically, converting the old CVS repo for OneJAR to Git should be
doable. SourceForge even has a little guide about how to do that:

https://sourceforge.net/p/forge/documentation/CVS/

If you want to keep it simple and not retain the full commit history,
but just the versions 0.95, 0.96, 0.97 stored as binary resources within
the plugin, please note that those JARs also contain the full source
code for each version, not just the class files. So you could just
unpack them into the new Maven module, commit and tag them. BTW, the
source code only consists of 6 classes with an overall size of about 90
KB.

--
Alexander Kriegisch

[Hervé Boutemy]

notice that there is UnoJar that already did the work of cleanly forking OneJar and maintain it:

https://github.com/nsoft/uno-jar

and it seems there is a Maven plugin listed in its README

--
You received this message because you are subscribed to the Google Groups "mojohaus-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojohaus-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mojohaus-dev/20220128044123.3C55E78C084B%40dd19710.kasserver.com.

[Jochen Wiedmann]

On Fri, Jan 28, 2022 at 8:18 AM Hervé Boutemy <herve....@gmail.com> wrote:
>
> notice that there is UnoJar that already did the work of cleanly forking OneJar and maintain it:
> https://github.com/nsoft/uno-jar

Thanks for the hint, Hervé. Reading through the license (and,
consequently, through the original license) made me reconsider: Both
appear to me to be non-standard licenses, so we probably should avoid
them.

Jochen

[Alexander Kriegisch]

Ben said in his original message:

> As there was no recent development, I asked the plugin author whether
> he would be willing to donate it to mojohaus. And yes, he would do so.
> He would also change the License to Apache v2.0 for us.

So what is the problem, really?
--
Alexander Kriegisch
https://scrum-master.de

[Hervé Boutemy]

IIUC:

- the core OneJar comes from Simon with his specific license http://one-jar.sourceforge.net/index.php?page=documents&file=license that is quite permissive

- Simon seems to be unresponsive to any update or contribution = this is the main issue with OneJar, because there was no update in 10 years

- UnoJar did the best fork possible: could not avoid retaining the original license, but at least it's now back to a living project with contributions

- UnoJar does not provide any Maven Plugin, but points to another fork of the plugin from GoogleCode

- this Maven plugin fork https://github.com/greening/unojar-maven-plugin is GPL-licensed (because it was the license at Google Code)and has migrated from original OneJar to current UnoJar

so IMHO, the best we can do is:

1. either contact greening to put his work at MojoHaus, staying with GPL license (because he can't really change)

2. or do a clean rewrite at MojoHaus with the license we want, without using code from Google Code (that is GPL licensed)

in every case, it will use UnoJar because that's the more viable option

WDYT?

--
You received this message because you are subscribed to the Google Groups "mojohaus-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojohaus-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mojohaus-dev/20220129030122.E598378C0806%40dd19710.kasserver.com.

[Jochen Wiedmann]

On Sat, Jan 29, 2022 at 4:01 AM Alexander Kriegisch
<alex...@kriegisch.name> wrote:

> > As there was no recent development, I asked the plugin author whether
> > he would be willing to donate it to mojohaus. And yes, he would do so.
> > He would also change the License to Apache v2.0 for us.
>
> So what is the problem, really?

Been missing that part. Bit surprising, as Simon isn't really known
for responding to questions. :-)

Would be nice, though, to have one-jar in a place, where it can be
actively maintained.

Jochen

[Hervé Boutemy]

UnoJar is the place: the only drawback is that it kept the unusual license, unusual but permissive, then with a good maintainer, it's ok

for the associated Maven, there is a GPL one outside

--
You received this message because you are subscribed to the Google Groups "mojohaus-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojohaus-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mojohaus-dev/CAF8HOZ%2B%2BZyFB1gAmLEtoXv2ya4ypUVA3f2DxBwCf%2BPUcNrVDog%40mail.gmail.com.

[Patrick G. Heck]

Hi, 

I'm the maintainer of UnoJar. I  just happened to notice this conversation when it came up in a search. I'm curious what your result was. WRT maven plugins. I'm happy for them to exist, and would certainly endeavor not to break them, but I'm not a fan of maven and use it only when forced to (I went straight from Ant to Gradle I love the dependency management and download mechanism they created, but never got along well with the POM). As such, I'm not planning on learning to write maven plugins or support them directly myself. If a GPL free one can be contributed I'd likely let someone handle that directly (grant commit access) after a few successful, pain free pull requests. (basically, just make me get tired of wasting time reading your PR's and not finding anything important :) ).

As for licenses yes I find the original OneJar License entirely lamentable that he didn't use standard 3 clause BSD but bastardized it with his actual name and a trademark like clause regarding use of the One-JAR name... I've not bee able to reach Simon and had offered to help him maintain on source-forge but never got a response. As such I have set up UnoJar's License file to say that new code is MIT license and old code is under Simon's license, which is the best I can do to free things up AFAICT. That said, It's all very permissive and if you don't mention Simon or One-JAR, I think it's no different than BSD/MIT terms.

I'm also not a big fan of GPL in it's various flavors, since I typically write my software with the hope that as many people as possible will use it, and also to ensure that I can always use it wherever I happen to be working. Also I and have watched companies spend dozens of man-years removing LGPL when their lawyers decided it was in conflict with some obscure aspect of their warranty program. So if there's a new version of maven plugin that's been created please let me know, I'll happily list it. If it's any of Apache/MIT/BSD I'll list it first ;).

I'm also happy to have contributions/enhancements/bugfixes and feature requests. The project has been kept alive because I think it was really the *right* way to approach fat-jar packaging, and to support my JeserJ project which has a hard goal of keeping the simplest possible command line invocation via java -jar.

The next feature I'm contemplating is to support UnoJars inside UnoJars such that dependency on different versions can easily co-exist without all the messy problems Shade/Shadow have trying to rename stuff and edit class files. This is working in JesterJ for a long time now, but I'm going to move that into UnoJar where it probably should have been from the start.

Best,

-Gus

[Alexander Kriegisch]

Hi Patrick.

I cannot comment on whether this issue was moved forward or not, only on
this, simply to counter-balance it:

> WRT maven plugins. I'm happy for them to exist, and would certainly
> endeavor not to break them, but I'm not a fan of maven and use it only
> when forced to (I went straight from Ant to Gradle I love the
> dependency management and download mechanism they created, but never
> got along well with the POM).

Of course, Mojohaus is all about Maven plugins and my feelings regarding
Gradle are similar to yours towards Maven: I only touch it if I
absolutely have to. Anyway, the Mojohaus committers (I am not one of
them) are very proficient in writing/maintaining Maven plugins, which
sounds like win/win to me: You are dedicated to maintaining UnoJar, and
here are people who can maintain the corresponding Maven plugin.

I cannot say much about the mythical Simon, but I guess if someone
(Ben?) is determined to reach (out to) him, it should be feasible to get
his consent for any desired licence changes.

On a side note: Maybe it makes sense that we do not develop things
multiple times. So, I want to mention that on top of Spring Boot Maven
and OneJar Maven there is also Agent Embedder Maven Plugin [1],
scratching yet another itch which some Spring Boot users and other
developers might have: How to embed Java agents into an executable JAR
and launch them automatically with 'java -jar'. A classic example is a
Spring Boot application using AspectJ load-time weaving (instead of
Spring AOP). Spoiler: I maintain both Agent Embedder Maven Plugin and
AspectJ.

[1] https://github.com/dev-aspectj/agent-embedder-maven-plugin

--
Alexander Kriegisch
https://scrum-master.de

> https://groups.google.com/d/msgid/mojohaus-dev/CAF8HOZ%2B%2BZyFB1gAmLEtoXv2ya4ypUVA3f2DxBwCf%2BPUcNrVDog%40mail.gmail.com <https://groups.google.com/d/msgid/mojohaus-dev/CAF8HOZ%2B%2BZyFB1gAmLEtoXv2ya4ypUVA3f2DxBwCf%2BPUcNrVDog%40mail.gmail.com>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "mojohaus-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to mojohaus-dev...@googlegroups.com

> <mailto:mojohaus-dev...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/mojohaus-dev/21d6503b-7334-4e57-9fa1-0468de69f6fdn%40googlegroups.com <https://groups.google.com/d/msgid/mojohaus-dev/21d6503b-7334-4e57-9fa1-0468de69f6fdn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Patrick G. Heck]

If you can find Simon and get him to grant an MIT or an unaltered BSD 3 clause license that would be awesome. I think the entire world was less savvy about licensing back in 2004, and his alterations probably didn't seem like a big deal, but now anything not exactly matching a known license is flagged as unknown, and presents a barrier potentially involving a lawyer at many companies that employ scanning software. The javadoc linked from your site (https://docs.oracle.com/javase/9/docs/api/java/lang/instrument/package-summary.html) is interesting. I'll have to look through that.

I've been working on the notion of re-launching a sub-process to allow the addition of arbitrary args. Of related concern are --add-opens which seem to be working as Jar Manifest "Add-Opens" attributes, but I've been entirely unable to hunt down any spec that mentions that as an option in Jar Manifests Add-Exports I did find. It's particularly frustrating that there doesn't seem to be a single specification/reference for jar files that actually documents what Manifest attributes are significant to JVM's There are a few here: https://docs.oracle.com/en/java/javase/22/docs/specs/jar/jar.html (and a similar page if you google jar specification). The only way I found out about Add-Exports was because it showed up on a mailing-list discussion when I was googling...

And now I find out about agent related attributes only through this mailing list and the link on your github site... *sigh*

-Gus

Founder, Chief Architect, Needham Software LLC

Commiter & PMC member Apache Solr & Apache Lucene

508-333-5312

https://www.needhamsoftware.com

You received this message because you are subscribed to a topic in the Google Groups "mojohaus-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mojohaus-dev/rvMn64oLZ4g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mojohaus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mojohaus-dev/fe06fbee-de84-4dae-9c28-09f01f7a4258%40Kriegisch.name.