Re: is it legal to shade "gson" packages in Maven?

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: is it legal to shade "gson" packages in Maven?

Enrico Olivelli
Tibor,
can you please explain better your intent ?
Is it about shading it into surefire booter ?

Enrico

Il giorno dom 23 feb 2020 alle ore 08:43 Tibor Digana
<[hidden email]> ha scritto:
>
>  I want to ask you if it is still legal to shade packages in gson library.
> Although it contains the Apache 2.0 license but it contains Copyright (C)
> 2010 Google Inc.  as well, see:
> https://github.com/google/gson/blob/master/gson/src/main/java/com/google/gson/stream/JsonReader.java
>
> --
> Cheers
> Tibor

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: is it legal to shade "gson" packages in Maven?

Elliotte Rusty Harold
Why do you need to shade this at all? GSON should work just fine as a
normal library. Shading is a last resort that usually causes more
problems than it solves:

https://jlbp.dev/JLBP-18.html

On Sun, Feb 23, 2020 at 2:43 AM Tibor Digana <[hidden email]> wrote:
>
>  I want to ask you if it is still legal to shade packages in gson library.
> Although it contains the Apache 2.0 license but it contains Copyright (C)
> 2010 Google Inc.  as well, see:
> https://github.com/google/gson/blob/master/gson/src/main/java/com/google/gson/stream/JsonReader.java
>
> --
> Cheers
> Tibor



--
Elliotte Rusty Harold
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: is it legal to shade "gson" packages in Maven?

Enrico Olivelli
In reply to this post by Enrico Olivelli
I would prefer not to add a shaded jar if it is not really needed.




Il Dom 23 Feb 2020, 11:57 Vladimir Sitnikov <[hidden email]>
ha scritto:

> > Here the GSON library is only one
>
> https://github.com/FasterXML/jackson-jr is 100KiB or so.
> Have you checked it?
>

This is very interesting

Jackson Databind is famous for a long list of CVEs, I have never seen this
'small version' maybe it is worth to check.

Again, if we don't need, let's step away from adding a new library.

Why not using XML and built in java support?

In this specific case, surefire, I think that we don't even need it as the
TCP work has already been mostly completed


Enrico

>
> Vladimir
>
Reply | Threaded
Open this post in threaded view
|

Re: is it legal to shade "gson" packages in Maven?

Enrico Olivelli
In reply to this post by Elliotte Rusty Harold
Elliotte,
This is about surefire, we cannot pollute Java classpath of running tests.
The library should be loaded with a special class loader, it would be more
complex than writing a simple hard coded coder/decoder as we already have
in surefire

Enrico

Enrico

Il Dom 23 Feb 2020, 14:59 Elliotte Rusty Harold <[hidden email]> ha
scritto:

> Why do you need to shade this at all? GSON should work just fine as a
> normal library. Shading is a last resort that usually causes more
> problems than it solves:
>
> https://jlbp.dev/JLBP-18.html
>
> On Sun, Feb 23, 2020 at 2:43 AM Tibor Digana <[hidden email]>
> wrote:
> >
> >  I want to ask you if it is still legal to shade packages in gson
> library.
> > Although it contains the Apache 2.0 license but it contains Copyright (C)
> > 2010 Google Inc.  as well, see:
> >
> https://github.com/google/gson/blob/master/gson/src/main/java/com/google/gson/stream/JsonReader.java
> >
> > --
> > Cheers
> > Tibor
>
>
>
> --
> Elliotte Rusty Harold
> [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: is it legal to shade "gson" packages in Maven?

Elliotte Rusty Harold
On Sun, Feb 23, 2020 at 9:03 AM Enrico Olivelli <[hidden email]> wrote:
>
> Elliotte,
> This is about surefire, we cannot pollute Java classpath of running tests.
> The library should be loaded with a special class loader, it would be more
> complex than writing a simple hard coded coder/decoder as we already have
> in surefire


Absolutely. By using separate class loaders, or better yet a
completely different process, you avoid polluting the classpath
without shading. By contrast shading with the same class loader does
pollute the user's classpath with the shaded code. I'll quote from
what IO wrote for https://jlbp.dev/JLBP-1.html

The tools we use for Java projects are more often than not themselves
written in Java. This includes build systems such as Maven, javac, and
Ant; runtime environments such as Tomcat, Hadoop, Beam, and App
Engine; and editors such as jEdit, Eclipse, and IntelliJ IDEA. Tools
like these should have their own classpaths from which they load their
own code.

It is critical not to mix the classpath of the tool with the classpath
of the product. Dependencies of the tool should not be dependencies of
the product. For example, there’s no reason javax.tools.JavaCompiler
should appear in the classpath of an MP3 player simply because the
player’s source code was compiled by javac.

Indeed javac does not transmit its own dependencies into the products
it builds, but not all tools are this well behaved. Maven annotation
processors such as AutoValue and Animal Sniffer are sometimes declared
to be dependencies of the product itself in the pom.xml. Since they
are only needed at compile time, they should instead be added to the
annotation processor path.

When running code from Maven, prefer mvn exec:exec to mvn exec:java.
mvn exec:exec uses a completely separate process to run the user’s
code while mvn exec:java runs the user’s process in the same virtual
machine Maven itself uses.

Modern application servers are reasonably good about separating the
code they host from their own. However there have been issues in the
past where the boundary was not as aggressively maintained. The
jre/lib/ext directory in particular has been a common source of hard
to debug dependency issues where a different version of a library was
loaded instead of the one the user expected. If you are creating a
product that runs user supplied code, implement completely separate
classpaths for user code and your product’s code.

--
Elliotte Rusty Harold
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: is it legal to shade "gson" packages in Maven?

Elliotte Rusty Harold
In reply to this post by Enrico Olivelli
On Sun, Feb 23, 2020 at 9:34 AM Vladimir Sitnikov
<[hidden email]> wrote:
>
> >Why not using XML and built in java support?
>
> It is no longer built-in:
> https://www.oracle.com/technetwork/java/javase/11-relnote-issues-5012449.html#JDK-8190378
>

What was removed was badly architected data binding packages that
caused more trouble than they were worth. Plain old reliable SAX and
DOM are still bundled as are XPath and XSLT.

--
Elliotte Rusty Harold
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: is it legal to shade "gson" packages in Maven?

Tibor Digana
Alright! There is no question about yes or no to shade. The right answer is
yes.
We always do it and we have reason for that for 13 years.
Why? Because of the gson project may risk the conflicts with surefire JVM
and surefire transitive dependencies.
The same reason to shade Maven Shared Utils, and many other artifacts.

I was asking about the Copyright problem in Google sources.
The Apache 2.0 license is legal for us.
The Jackson is legal as well however it contains jackson-core, this means
more than one library but that's still okay.

So we have two opntions: gson and jackson.
If the Copyright is not a real problem then the last test should be done
with JDK 9, JDK11 and JDK 14.




On Sun, Feb 23, 2020 at 3:45 PM Elliotte Rusty Harold <[hidden email]>
wrote:

> On Sun, Feb 23, 2020 at 9:34 AM Vladimir Sitnikov
> <[hidden email]> wrote:
> >
> > >Why not using XML and built in java support?
> >
> > It is no longer built-in:
> >
> https://www.oracle.com/technetwork/java/javase/11-relnote-issues-5012449.html#JDK-8190378
> >
>
> What was removed was badly architected data binding packages that
> caused more trouble than they were worth. Plain old reliable SAX and
> DOM are still bundled as are XPath and XSLT.
>
> --
> Elliotte Rusty Harold
> [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: is it legal to shade "gson" packages in Maven?

Vladimir Sitnikov
> Copyright problem in Google sources.

Are you going to copy gson sources to maven source code?
If you do that, you need to keep the copyright.

Are you going to take the jar and optionally shade it?
In that case you need to check if gson.jar is accompanied with NOTICE file.
If notice is there, you need append it to maven's notice.
If notice is not there, updating maven's notice is not needed.

The above assumes gson license is Apache-2.0

Vladimir
Reply | Threaded
Open this post in threaded view
|

Re: is it legal to shade "gson" packages in Maven?

Romain Manni-Bucau
Catching a bit late but if it helps we can extract the needed parts from
johnzon and do a j6 friendly module, this would all stay apache so no legal
issue at all - or johnzon cna be forked if code is very localized if
preferred.

Le dim. 23 févr. 2020 à 21:52, Vladimir Sitnikov <
[hidden email]> a écrit :

> > Copyright problem in Google sources.
>
> Are you going to copy gson sources to maven source code?
> If you do that, you need to keep the copyright.
>
> Are you going to take the jar and optionally shade it?
> In that case you need to check if gson.jar is accompanied with NOTICE file.
> If notice is there, you need append it to maven's notice.
> If notice is not there, updating maven's notice is not needed.
>
> The above assumes gson license is Apache-2.0
>
> Vladimir
>