Re: is it legal to shade "gson" packages in Maven?
On Sun, Feb 23, 2020 at 10:21 AM Tibor Digana wrote: > > 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. > Sorry, I don't buy it. I noticed the shading of maven shared utils today too, and that also strikes me as misguided and unnecessary. Maybe there's a reason for shading this dependency (though it's yet to be demonstrated here) but I suspect the pot roast principle might be in play here: https://www.psychologytoday.com/us/blog/thinking-makes-it-so/201402/the-pot-roast-principle -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: is it legal to shade "gson" packages in Maven?
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 < sitnikov.vladi...@gmail.com> 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 >
Re: is it legal to shade "gson" packages in Maven?
> 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
Re: is it legal to shade "gson" packages in Maven?
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 wrote: > On Sun, Feb 23, 2020 at 9:34 AM Vladimir Sitnikov > 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 > elh...@ibiblio.org > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: is it legal to shade "gson" packages in Maven?
On Sun, Feb 23, 2020 at 9:34 AM Vladimir Sitnikov 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 elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: is it legal to shade "gson" packages in Maven?
On Sun, Feb 23, 2020 at 9:03 AM Enrico Olivelli 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 elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: is it legal to shade "gson" packages in Maven?
>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 Vladimir
Re: is it legal to shade "gson" packages in Maven?
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 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 > 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 > elh...@ibiblio.org > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: is it legal to shade "gson" packages in Maven?
I would prefer not to add a shaded jar if it is not really needed. Il Dom 23 Feb 2020, 11:57 Vladimir Sitnikov 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 >
Re: is it legal to shade "gson" packages in Maven?
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 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 elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: is it legal to shade "gson" packages in Maven?
> Here the GSON library is only one https://github.com/FasterXML/jackson-jr is 100KiB or so. Have you checked it? Vladimir
Re: is it legal to shade "gson" packages in Maven?
Shade has option exclude rules if you wanted to slim down that side of it, and still stick with Jackson. Shading itself should alter the should or shouldn't aspect of library/package linkage within a app/lib/service/plugin/solution. You're guided by imports in Java-land - Apache license stuff can't import GPL2 and still be adhering. And others. "What is linkage" is primarily import with Java, but there are other ways linkage can be set up and still entangled in license considerations/debates. - Paul
Re: is it legal to shade "gson" packages in Maven?
I want to use JSON because the data structures can be better transferred over a channel, easier extend and the current algorithm can be removed. The jackson is actually 3 libraries and very big to shade (few megabytes). The MJson library is very old without long support. Here the GSON library is only one, still supported by Google and it is compiled with javac 1.6. Of course I should not use the libraries directly on the classpath. Everybody knows that the conflicts can be nicely avoided by shaing the Java packages of external libraries. T On Sun, Feb 23, 2020 at 10:21 AM Enrico Olivelli wrote: > 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 > 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: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: is it legal to shade "gson" packages in Maven?
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 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: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
is it legal to shade "gson" packages in Maven?
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
