On Thu, Feb 25, 2021 at 10:00 AM Jean-Noël Rouvignac (ForgeRock) <
jean-noel.rouvig...@forgerock.com> wrote:

> Hello!
>
> I am coming back on this subject that I originally suggested here:
> https://github.com/apache/jclouds/pull/93#issuecomment-762705311
>
> Here is my original message:
> > BTW are you interested in removing the dependency on XMLBuilder?
> >
> > This adds a dependency to the com.jamesmurty.utils:java-xmlbuilder jar
> > and a transitive dependency to the net.iharder:base64 jar (which is
> > superseded by java.util.Base64 with java 8 anyway). They are 18kb each
> > approximately and not OSGi compatible. They are not huge, but it's less
> > API surface and it's less things to change when trying to use jclouds
> > in an OSGi context (they need to be replaced by OSGi compatible bundles
> > like org.apache.servicemix.bundles.java-xmlbuilder).
>
> I would also add that XMLBuilder is only used in a tiny portion of jclouds:
> the s3 api. I hope retesting would be minimal.
>
> Andrew Gaul answered "We are interested in any OSGi improvements, if they
> remove dependencies or otherwise."
>
>
>
>
> I am now ready to look at this, but first I would like to know how I should
> do it:
>
> 1. I could copy the code of XMLBuilder and trim it down to remove any
> unnecessary indirections, but I do not if this is compliant with the
> licensing of Apache: I think the ASF wants to be the copyright owner of the
> code? Obviously I cannot transfer ownership of somebody else's code.
>

The library is already licensed under ASLv2, so it should be fine to bundle
it.
If in doubt, you can read: https://infra.apache.org/licensing-howto.html
That document details how to bundle stuff, but in short, this approach
should be
just copying the files "keeping the original copyright and headers", and
then
add an entry in the NOTICE files mentioning we include and modify it.


>
> 2. I could keep the nice fluent XMLBuilder API only and reimplement it
> myself.
>
> 3. I could directly use the `javax.xml` and `org.w3c.dom` APIs of the JDK.
>

2 and 3 are perfectly valid options as well. I don't know how much effort
those would require
but since it is only used in S3, changes are going to be very local and
probably makes sense to
go for 3 and get rid of the dependency entirely.


>
> Please let me know what approach you prefer and I'll try to do it.
>
> Thanks!
> Jean-Noel Rouvignac
>
> --
> ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
>

Reply via email to