Re: Questions about the release

[Colm O hEigeartaigh]

Great thanks! I will re-spin the release.

Colm.

On Tue, May 9, 2017 at 4:01 PM, Emmanuel Lécharny 
wrote:

>
>
> Le 09/05/2017 à 16:54, Colm O hEigeartaigh a écrit :
> > OK I have added all of the parts from the Netty NOTICE that were
> "modified"
> > in Netty and licenses, so long as they weren't ASL v2.0. Emmanuel, please
> > review and let me know if it's finally right.
> >
> > https://github.com/apache/directory-kerby/tree/trunk/kerby-dist/kdc-dist
> >
> > Colm.
>
> That sounds correct !
>
> Thanks for the hard work !
>
> --
> Emmanuel Lecharny
>
> Symas.com
> directory.apache.org
>
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: Questions about the release

[Colm O hEigeartaigh]

OK I have added all of the parts from the Netty NOTICE that were "modified"
in Netty and licenses, so long as they weren't ASL v2.0. Emmanuel, please
review and let me know if it's finally right.

https://github.com/apache/directory-kerby/tree/trunk/kerby-dist/kdc-dist

Colm.

On Tue, May 9, 2017 at 2:37 PM, Emmanuel Lécharny 
wrote:

>
>
> Le 09/05/2017 à 14:23, Colm O hEigeartaigh a écrit :
> > Hi Kai,
> >
> > What matters is what jars we are including in the "lib". Any changes
> Netty
> > made to third party dependencies in these jars must be in the
> > NOTICE/licenses.
>
> Colm is right.
>
> Now, it's enough - assuming that they have been double checked - to
> include Netty's N files in our dist packages, because Netty has
> already done the work : ie gathering the dependencies they are using.
>
>
>
> I know, I know, this is a painful process...
>
> --
> Emmanuel Lecharny
>
> Symas.com
> directory.apache.org
>
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: Questions about the release

[Emmanuel Lécharny]

Le 09/05/2017 à 14:23, Colm O hEigeartaigh a écrit :
> Hi Kai,
>
> What matters is what jars we are including in the "lib". Any changes Netty
> made to third party dependencies in these jars must be in the
> NOTICE/licenses.

Colm is right.

Now, it's enough - assuming that they have been double checked - to
include Netty's N files in our dist packages, because Netty has
already done the work : ie gathering the dependencies they are using.



I know, I know, this is a painful process...

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Questions about the release

[Colm O hEigeartaigh]

Hi Kai,

What matters is what jars we are including in the "lib". Any changes Netty
made to third party dependencies in these jars must be in the
NOTICE/licenses.

Colm.

On Tue, May 9, 2017 at 1:20 PM, Zheng, Kai <kai.zh...@intel.com> wrote:

> Hi Colm and Emmanuel,
>
> Regarding Netty, what we used is the TCP/UDP network transport support,
> which should be one of its basic functionalities. We haven't used any other
> parts, like the one JBoss marshalling function. The relevant codes are in
> kerby KDC. Hope this helps.
>
> Regards,
> Kai
>
> -Original Message-
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Tuesday, May 09, 2017 8:12 PM
> To: kerby@directory.apache.org
> Subject: Re: Questions about the release
>
> I haven't. So I think I should include all "This product contains a
> modified portion" portions from the NOTICE file, but not "This product
> optionally depends on" from here:
>
> https://github.com/netty/netty/blob/4.1/NOTICE.txt
>
> ? As well as any of the licenses that are referred.
>
> Colm.
>
> On Tue, May 9, 2017 at 12:46 PM, Emmanuel Lécharny <elecha...@gmail.com>
> wrote:
>
> >
> >
> > Le 09/05/2017 à 12:24, Colm O hEigeartaigh a écrit :
> > > Thanks Emmanuel. The user would have to add zookeeper/nimbus in the
> > > poms before generating the distribution to add them, so I am going
> > > to remove these from the NOTICE file as they are not required.
> > >
> > > OK here are the changes I have made...please review:
> > >
> > > 1) The root NOTICE just includes the standard Apache copyright notice:
> > >
> > > https://github.com/apache/directory-kerby/blob/trunk/NOTICE
> > >
> > > 2) The two "distributions" of "kdc-dist" and "tool-dist" have the
> > following
> > > NOTICE files:
> > >
> > > https://github.com/apache/directory-kerby/blob/trunk/
> > kerby-dist/kdc-dist/NOTICE
> > > https://github.com/apache/directory-kerby/blob/trunk/
> > kerby-dist/tool-dist/NOTICE
> > >
> > > and the following identical license folders:
> > >
> > > https://github.com/apache/directory-kerby/tree/trunk/
> > kerby-dist/tool-dist/licenses
> > > https://github.com/apache/directory-kerby/tree/trunk/
> > kerby-dist/kdc-dist/licenses
> > >
> > > We only bundle Netty + SLF4J in "kdc-dist" and only SLF4J in the
> > tool-dist,
> > > so I think we are covered.
> >
> >
> > Sounds good to me.
> >
> > Have you taken into account the transitive dependencies ? (ie, N for
> > things that are embedded in Netty).
> >
> > --
> > Emmanuel Lecharny
> >
> > Symas.com
> > directory.apache.org
> >
> >
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

RE: Questions about the release

[Zheng, Kai]

Hi Colm and Emmanuel,

Regarding Netty, what we used is the TCP/UDP network transport support, which 
should be one of its basic functionalities. We haven't used any other parts, 
like the one JBoss marshalling function. The relevant codes are in kerby KDC. 
Hope this helps.

Regards,
Kai 

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Tuesday, May 09, 2017 8:12 PM
To: kerby@directory.apache.org
Subject: Re: Questions about the release

I haven't. So I think I should include all "This product contains a modified 
portion" portions from the NOTICE file, but not "This product optionally 
depends on" from here:

https://github.com/netty/netty/blob/4.1/NOTICE.txt

? As well as any of the licenses that are referred.

Colm.

On Tue, May 9, 2017 at 12:46 PM, Emmanuel Lécharny <elecha...@gmail.com>
wrote:

>
>
> Le 09/05/2017 à 12:24, Colm O hEigeartaigh a écrit :
> > Thanks Emmanuel. The user would have to add zookeeper/nimbus in the 
> > poms before generating the distribution to add them, so I am going 
> > to remove these from the NOTICE file as they are not required.
> >
> > OK here are the changes I have made...please review:
> >
> > 1) The root NOTICE just includes the standard Apache copyright notice:
> >
> > https://github.com/apache/directory-kerby/blob/trunk/NOTICE
> >
> > 2) The two "distributions" of "kdc-dist" and "tool-dist" have the
> following
> > NOTICE files:
> >
> > https://github.com/apache/directory-kerby/blob/trunk/
> kerby-dist/kdc-dist/NOTICE
> > https://github.com/apache/directory-kerby/blob/trunk/
> kerby-dist/tool-dist/NOTICE
> >
> > and the following identical license folders:
> >
> > https://github.com/apache/directory-kerby/tree/trunk/
> kerby-dist/tool-dist/licenses
> > https://github.com/apache/directory-kerby/tree/trunk/
> kerby-dist/kdc-dist/licenses
> >
> > We only bundle Netty + SLF4J in "kdc-dist" and only SLF4J in the
> tool-dist,
> > so I think we are covered.
>
>
> Sounds good to me.
>
> Have you taken into account the transitive dependencies ? (ie, N for 
> things that are embedded in Netty).
>
> --
> Emmanuel Lecharny
>
> Symas.com
> directory.apache.org
>
>


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: Questions about the release

[Colm O hEigeartaigh]

I haven't. So I think I should include all "This product contains a
modified portion" portions from the NOTICE file, but not "This product
optionally depends on" from here:

https://github.com/netty/netty/blob/4.1/NOTICE.txt

? As well as any of the licenses that are referred.

Colm.

On Tue, May 9, 2017 at 12:46 PM, Emmanuel Lécharny 
wrote:

>
>
> Le 09/05/2017 à 12:24, Colm O hEigeartaigh a écrit :
> > Thanks Emmanuel. The user would have to add zookeeper/nimbus in the poms
> > before generating the distribution to add them, so I am going to remove
> > these from the NOTICE file as they are not required.
> >
> > OK here are the changes I have made...please review:
> >
> > 1) The root NOTICE just includes the standard Apache copyright notice:
> >
> > https://github.com/apache/directory-kerby/blob/trunk/NOTICE
> >
> > 2) The two "distributions" of "kdc-dist" and "tool-dist" have the
> following
> > NOTICE files:
> >
> > https://github.com/apache/directory-kerby/blob/trunk/
> kerby-dist/kdc-dist/NOTICE
> > https://github.com/apache/directory-kerby/blob/trunk/
> kerby-dist/tool-dist/NOTICE
> >
> > and the following identical license folders:
> >
> > https://github.com/apache/directory-kerby/tree/trunk/
> kerby-dist/tool-dist/licenses
> > https://github.com/apache/directory-kerby/tree/trunk/
> kerby-dist/kdc-dist/licenses
> >
> > We only bundle Netty + SLF4J in "kdc-dist" and only SLF4J in the
> tool-dist,
> > so I think we are covered.
>
>
> Sounds good to me.
>
> Have you taken into account the transitive dependencies ? (ie, N for
> things that are embedded in Netty).
>
> --
> Emmanuel Lecharny
>
> Symas.com
> directory.apache.org
>
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: Questions about the release

[Emmanuel Lécharny]

Le 09/05/2017 à 12:24, Colm O hEigeartaigh a écrit :
> Thanks Emmanuel. The user would have to add zookeeper/nimbus in the poms
> before generating the distribution to add them, so I am going to remove
> these from the NOTICE file as they are not required.
>
> OK here are the changes I have made...please review:
>
> 1) The root NOTICE just includes the standard Apache copyright notice:
>
> https://github.com/apache/directory-kerby/blob/trunk/NOTICE
>
> 2) The two "distributions" of "kdc-dist" and "tool-dist" have the following
> NOTICE files:
>
> https://github.com/apache/directory-kerby/blob/trunk/kerby-dist/kdc-dist/NOTICE
> https://github.com/apache/directory-kerby/blob/trunk/kerby-dist/tool-dist/NOTICE
>
> and the following identical license folders:
>
> https://github.com/apache/directory-kerby/tree/trunk/kerby-dist/tool-dist/licenses
> https://github.com/apache/directory-kerby/tree/trunk/kerby-dist/kdc-dist/licenses
>
> We only bundle Netty + SLF4J in "kdc-dist" and only SLF4J in the tool-dist,
> so I think we are covered.


Sounds good to me.

Have you taken into account the transitive dependencies ? (ie, N for
things that are embedded in Netty).

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Questions about the release

[Colm O hEigeartaigh]

Thanks Emmanuel. The user would have to add zookeeper/nimbus in the poms
before generating the distribution to add them, so I am going to remove
these from the NOTICE file as they are not required.

OK here are the changes I have made...please review:

1) The root NOTICE just includes the standard Apache copyright notice:

https://github.com/apache/directory-kerby/blob/trunk/NOTICE

2) The two "distributions" of "kdc-dist" and "tool-dist" have the following
NOTICE files:

https://github.com/apache/directory-kerby/blob/trunk/kerby-dist/kdc-dist/NOTICE
https://github.com/apache/directory-kerby/blob/trunk/kerby-dist/tool-dist/NOTICE

and the following identical license folders:

https://github.com/apache/directory-kerby/tree/trunk/kerby-dist/tool-dist/licenses
https://github.com/apache/directory-kerby/tree/trunk/kerby-dist/kdc-dist/licenses

We only bundle Netty + SLF4J in "kdc-dist" and only SLF4J in the tool-dist,
so I think we are covered.

Colm.


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

On Tue, May 9, 2017 at 11:04 AM, Emmanuel Lécharny 
wrote:

>
>
> Le 09/05/2017 à 11:16, Colm O hEigeartaigh a écrit :
> > OK, seeing as we don't bundle them by default, then IMO we don't need to
> > include them in the NOTICE file. Emmanuel, can you confirm?
> Everything that is not bundled does not have to be into N files.
>
> If there is no way a user can grab the sources and generate a package
> from those source that contain this bundle, then there is no need to
> have the N file in the source either. OTOH, if the user can grab the
> source, build it to produce a package that will contain the bundle, then
> we need teh N files somwhere so that they get added when the user
> build the packaged. In any case, it should not be present in our source
> package N
>
> To be very clear : there are two kinds of N files :
> - those we include in our source or binary packages (if we provide some).
> - those that get included when we generate some packages from the source
> package (they are 'second order' N files)
>
> The first category makes our package legit, teh second category protect
> our users when they build their own package using our build system
> (typically the 'dist' modules).
>
> --
> Emmanuel Lecharny
>
> Symas.com
> directory.apache.org
>
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: Questions about the release

[Emmanuel Lécharny]

Le 09/05/2017 à 11:16, Colm O hEigeartaigh a écrit :
> OK, seeing as we don't bundle them by default, then IMO we don't need to
> include them in the NOTICE file. Emmanuel, can you confirm?
Everything that is not bundled does not have to be into N files.

If there is no way a user can grab the sources and generate a package
from those source that contain this bundle, then there is no need to
have the N file in the source either. OTOH, if the user can grab the
source, build it to produce a package that will contain the bundle, then
we need teh N files somwhere so that they get added when the user
build the packaged. In any case, it should not be present in our source
package N

To be very clear : there are two kinds of N files :
- those we include in our source or binary packages (if we provide some).
- those that get included when we generate some packages from the source
package (they are 'second order' N files)

The first category makes our package legit, teh second category protect
our users when they build their own package using our build system
(typically the 'dist' modules).

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Questions about the release

[Colm O hEigeartaigh]

OK, seeing as we don't bundle them by default, then IMO we don't need to
include them in the NOTICE file. Emmanuel, can you confirm?

Colm.

On Tue, May 9, 2017 at 10:11 AM, Zheng, Kai <kai.zh...@intel.com> wrote:

> Hi Colm,
>
> Thanks for this!
>
> >> Kai, is there a reason that the zookeeper + nimbus dependencies are not
> in the lib directories of the distributions?
> This is a good question I happened to know the answer.
>
> Yes we have already supported various KDC back ends, like the LDAP, ZK
> ones, but which one is to bundle in the KDC dist and used by default? It's
> hard to tell, because each one seems to need some time to mature. I'd
> suggest we take time to improve them when received user interests. So
> that's why we didn't put all the supported back ends in the dist.
>
> Nimbus is another story, it's for the token support. It's not bundled by
> default because I'm not sure most users would want the token support.
>
> Considering this release trouble, now I intend we don't bundle this
> plugins that involve external deps heavily, but it's just a thought. We can
> discuss about the way later. For now less change much better.
>
> Thanks again.
>
> Regards,
> Kai
>
> -Original Message-
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Tuesday, May 09, 2017 4:52 PM
> To: kerby@directory.apache.org
> Subject: Re: Questions about the release
>
> OK I have made some changes based on my understanding of what is required.
> Please correct me if I'm wrong!
>
> Mockito, Hamcrest (junit) are test dependencies and are not required in
> the NOTICE file or to specify the license.
>
> We bundle Netty and SLF4J in the distribution. So we have the SLF4J
> license included in "licenses" and mentioned in NOTICE, as well as the
> Netty NOTICE.
>
> From what I can see from kerby-dist/kdc-dist/target/lib and
> kerby-dist/tool-dist/target/lib, all of the dependencies are covered.
> However, in NOTICE we also have the "nimbus-jose-jwt," NOTICE and the
> "JLine" NOTICE (from Zookeeper). However, it appears we don't bundle either
> of these in the "lib" directories so I'm not sure why they are there.
>
> Kai, is there a reason that the zookeeper + nimbus dependencies are not in
> the lib directories of the distributions?
>
> Colm.
>
> On Tue, May 9, 2017 at 7:35 AM, Zheng, Kai <kai.zh...@intel.com> wrote:
>
> > Thanks Emmanuel and Colm! Could we lend your hands on this? Sure if
> > your bandwidth allows. We're much dummy in such things and seem to
> > have on confidence to get it right. :(
> >
> > For the long term, I would suggest we reorganize Kerby into two projects:
> > kerby-kerb for the Kerberos core and library; kerby-kdc. The two
> > projects can be separately released in their own appropriate cycles.
> > For Kerby-kerb, it avoids any 3rd party deps.
> >
> > Regards,
> > Kai
> >
> > -Original Message-
> > From: Emmanuel Lécharny [mailto:elecha...@gmail.com]
> > Sent: Tuesday, May 09, 2017 7:17 AM
> > To: kerby@directory.apache.org
> > Subject: Re: Questions about the release
> >
> >
> >
> > Le 08/05/2017 à 21:40, Colm O hEigeartaigh a écrit :
> > > I don't think we need the Mockito notice as it's a test dependency,
> > right?
> >
> > right.
> >
> > --
> > Emmanuel Lecharny
> >
> > Symas.com
> > directory.apache.org
> >
> >
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

RE: Questions about the release

[Zheng, Kai]

Hi Colm,

Thanks for this! 

>> Kai, is there a reason that the zookeeper + nimbus dependencies are not in 
>> the lib directories of the distributions?
This is a good question I happened to know the answer.

Yes we have already supported various KDC back ends, like the LDAP, ZK ones, 
but which one is to bundle in the KDC dist and used by default? It's hard to 
tell, because each one seems to need some time to mature. I'd suggest we take 
time to improve them when received user interests. So that's why we didn't put 
all the supported back ends in the dist.

Nimbus is another story, it's for the token support. It's not bundled by 
default because I'm not sure most users would want the token support.

Considering this release trouble, now I intend we don't bundle this plugins 
that involve external deps heavily, but it's just a thought. We can discuss 
about the way later. For now less change much better.

Thanks again.

Regards,
Kai

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Tuesday, May 09, 2017 4:52 PM
To: kerby@directory.apache.org
Subject: Re: Questions about the release

OK I have made some changes based on my understanding of what is required.
Please correct me if I'm wrong!

Mockito, Hamcrest (junit) are test dependencies and are not required in the 
NOTICE file or to specify the license.

We bundle Netty and SLF4J in the distribution. So we have the SLF4J license 
included in "licenses" and mentioned in NOTICE, as well as the Netty NOTICE.

From what I can see from kerby-dist/kdc-dist/target/lib and 
kerby-dist/tool-dist/target/lib, all of the dependencies are covered.
However, in NOTICE we also have the "nimbus-jose-jwt," NOTICE and the "JLine" 
NOTICE (from Zookeeper). However, it appears we don't bundle either of these in 
the "lib" directories so I'm not sure why they are there.

Kai, is there a reason that the zookeeper + nimbus dependencies are not in the 
lib directories of the distributions?

Colm.

On Tue, May 9, 2017 at 7:35 AM, Zheng, Kai <kai.zh...@intel.com> wrote:

> Thanks Emmanuel and Colm! Could we lend your hands on this? Sure if 
> your bandwidth allows. We're much dummy in such things and seem to 
> have on confidence to get it right. :(
>
> For the long term, I would suggest we reorganize Kerby into two projects:
> kerby-kerb for the Kerberos core and library; kerby-kdc. The two 
> projects can be separately released in their own appropriate cycles. 
> For Kerby-kerb, it avoids any 3rd party deps.
>
> Regards,
> Kai
>
> -Original Message-
> From: Emmanuel Lécharny [mailto:elecha...@gmail.com]
> Sent: Tuesday, May 09, 2017 7:17 AM
> To: kerby@directory.apache.org
> Subject: Re: Questions about the release
>
>
>
> Le 08/05/2017 à 21:40, Colm O hEigeartaigh a écrit :
> > I don't think we need the Mockito notice as it's a test dependency,
> right?
>
> right.
>
> --
> Emmanuel Lecharny
>
> Symas.com
> directory.apache.org
>
>


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: Questions about the release

[Colm O hEigeartaigh]

OK I have made some changes based on my understanding of what is required.
Please correct me if I'm wrong!

Mockito, Hamcrest (junit) are test dependencies and are not required in the
NOTICE file or to specify the license.

We bundle Netty and SLF4J in the distribution. So we have the SLF4J license
included in "licenses" and mentioned in NOTICE, as well as the Netty NOTICE.

>From what I can see from kerby-dist/kdc-dist/target/lib and
kerby-dist/tool-dist/target/lib, all of the dependencies are covered.
However, in NOTICE we also have the "nimbus-jose-jwt," NOTICE and the
"JLine" NOTICE (from Zookeeper). However, it appears we don't bundle either
of these in the "lib" directories so I'm not sure why they are there.

Kai, is there a reason that the zookeeper + nimbus dependencies are not in
the lib directories of the distributions?

Colm.

On Tue, May 9, 2017 at 7:35 AM, Zheng, Kai <kai.zh...@intel.com> wrote:

> Thanks Emmanuel and Colm! Could we lend your hands on this? Sure if your
> bandwidth allows. We're much dummy in such things and seem to have on
> confidence to get it right. :(
>
> For the long term, I would suggest we reorganize Kerby into two projects:
> kerby-kerb for the Kerberos core and library; kerby-kdc. The two projects
> can be separately released in their own appropriate cycles. For Kerby-kerb,
> it avoids any 3rd party deps.
>
> Regards,
> Kai
>
> -Original Message-
> From: Emmanuel Lécharny [mailto:elecha...@gmail.com]
> Sent: Tuesday, May 09, 2017 7:17 AM
> To: kerby@directory.apache.org
> Subject: Re: Questions about the release
>
>
>
> Le 08/05/2017 à 21:40, Colm O hEigeartaigh a écrit :
> > I don't think we need the Mockito notice as it's a test dependency,
> right?
>
> right.
>
> --
> Emmanuel Lecharny
>
> Symas.com
> directory.apache.org
>
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: Questions about the release

[Emmanuel Lécharny]

Le 08/05/2017 à 21:40, Colm O hEigeartaigh a écrit :
> I don't think we need the Mockito notice as it's a test dependency, right?

right.

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Questions about the release

[Colm O hEigeartaigh]

I don't think we need the Mockito notice as it's a test dependency, right?

Colm.

On Mon, May 8, 2017 at 3:02 PM, Colm O hEigeartaigh 
wrote:

> Actually, scratch that, it's fine to have the NOTICE file with the
> dependency information in the source as well.
>
> Colm.
>
> On Mon, May 8, 2017 at 2:50 PM, Colm O hEigeartaigh 
> wrote:
>
>> Thanks Emmanuel! So if I understand correctly, the changes that were made
>> to the NOTICE file in Kerby are incorrect:
>>
>> https://github.com/apache/directory-kerby/blob/trunk/NOTICE
>>
>> Instead, the NOTICE file should just have the standard Apache bit.
>> However, we need to update the distribution source code to include the
>> NOTICE file with the added dependencies etc. Is this correct?
>>
>> Colm.
>>
>> On Mon, May 8, 2017 at 2:21 PM, Emmanuel Lécharny 
>> wrote:
>>
>>>
>>>
>>> Le 08/05/2017 à 14:44, Stefan Seelmann a écrit :
>>> > On 05/08/2017 01:23 PM, Emmanuel Lécharny wrote:
>>> >>
>>> >> Le 08/05/2017 à 11:26, Colm O hEigeartaigh a écrit :
>>> >>> Hi Emmanuel,
>>> >>>
>>> >>> Is there a wiki page or something that you are aware of at Apache
>>> that
>>> >>> clearly lays out what the obligations of projects are for licenses +
>>> notice
>>> >>> files for third party dependencies? It's something I've yet to
>>> clearly wrap
>>> >>> my head around.
>>> >> I think the page is the one pointed out by Stefan :
>>> >>
>>> >> https://www.apache.org/dev/licensing-howto.html#bundled-vs-n
>>> on-bundled
>>> >>
>>> >> The thing is that it's not really clear to me too, because there is no
>>> >> example on this page.
>>> > Here is another one, that makes it IMHO clear that the source N
>>> should
>>> > not include any information about dependencies:
>>> >
>>> > "LICENSE and NOTICE MUST NOT provide unnecessary information about
>>> > materials which are not bundled in the package, such as separately
>>> > downloaded dependencies."
>>> >
>>> > https://www.apache.org/legal/release-policy.html#licensing-d
>>> ocumentation
>>> >
>>> >> The logic is the following : we are distributing packages (either
>>> >> sources or bianeis - for convenience, as The ASF is only required to
>>> >> deliver source packages for the users to build them -), and we *must*
>>> >> not give an opportinuty for our users to make a mistake and embed an
>>> >> incompatible component, or forget to add a required notice or license
>>> in
>>> >> their own packages, putting them at risk of being sued because of
>>> that.
>>> >>
>>> >> We can think that if a company is going to use our packages should do
>>> >> their due diligence, but that is putting too much of a burden on them.
>>> >> More important, it would be very bad PR for The ASF if we were to
>>> forgot
>>> >> some of teh required N
>>> > I agree with you. But I think it's two differenct cases:
>>> >
>>> > 1) The content of a distributed package.
>>> > 1a) If the package only contains source code witten by ASF committers
>>> or
>>> > the compiled class files then the minimal N applies. (Note: this
>>> would
>>> > probably not apply if we would code against an API of an GPL library,
>>> > that's why it's not allowed in ASF projects).
>>> > 1b) If some source code was borrowed e.g. from some 3rd party licensed
>>> > under MIT then we need to include that license and copyright notice.
>>> > 1d) And only if we bundle (redistribute) 3rd party content (e.g. in an
>>> > uber jars or binary distribution or installer) then all required N of
>>> > the bundled artifacts have to be added.
>>>
>>> On the same page, as soon as we are talking about source package.
>>>
>>> >
>>> > 2) The dependencies. As long as they are not bundled then they must not
>>> > be added to N
>>> correct.
>>>
>>> >  But of course it's our duty to make sure that all used
>>> > dependencies are compatible to ALv2. And we should be nice to our users
>>> > and list the dependencies. And in fact we do that :). All the Maven
>>> > generated jars contain a META-INF/DEPENDENCIES file with all
>>> > dependencies and its licenses listed. And the Maven generated source
>>> zip
>>> > also containse a DEPENDENCIES file The only issue I see is that the
>>> > Kerby source package (kerby-all-1.0.0-source-release.zip) contains an
>>> > empty DEPENDENCIES (similar for ApacheDS, whereas for Fortress-core
>>> > looks fine). It's probably because of the multi-module build, but maybe
>>> > we can tune the Maven release build to include all dependencies for the
>>> > whole project.
>>> >
>>> >> So what does it mean for Kerby, specifically ? Let's check teh
>>> different
>>> >> use cases...
>>> >>
>>> >> 1) We are distributing sources only
>>> >>
>>> >> Ok, so we basically don't distribute any binary (libs or exe). Our
>>> users
>>> >> *must* build Kerby if they want to use one of the packages, or
>>> >> copy/paste kerby's code in their one code. Are we safe ? Not that
>>> much,
>>> >> as building the packages may pull some external dependencies 

Re: Questions about the release

[Colm O hEigeartaigh]

Thanks Emmanuel! So if I understand correctly, the changes that were made
to the NOTICE file in Kerby are incorrect:

https://github.com/apache/directory-kerby/blob/trunk/NOTICE

Instead, the NOTICE file should just have the standard Apache bit. However,
we need to update the distribution source code to include the NOTICE file
with the added dependencies etc. Is this correct?

Colm.

On Mon, May 8, 2017 at 2:21 PM, Emmanuel Lécharny 
wrote:

>
>
> Le 08/05/2017 à 14:44, Stefan Seelmann a écrit :
> > On 05/08/2017 01:23 PM, Emmanuel Lécharny wrote:
> >>
> >> Le 08/05/2017 à 11:26, Colm O hEigeartaigh a écrit :
> >>> Hi Emmanuel,
> >>>
> >>> Is there a wiki page or something that you are aware of at Apache that
> >>> clearly lays out what the obligations of projects are for licenses +
> notice
> >>> files for third party dependencies? It's something I've yet to clearly
> wrap
> >>> my head around.
> >> I think the page is the one pointed out by Stefan :
> >>
> >> https://www.apache.org/dev/licensing-howto.html#bundled-vs-non-bundled
> >>
> >> The thing is that it's not really clear to me too, because there is no
> >> example on this page.
> > Here is another one, that makes it IMHO clear that the source N should
> > not include any information about dependencies:
> >
> > "LICENSE and NOTICE MUST NOT provide unnecessary information about
> > materials which are not bundled in the package, such as separately
> > downloaded dependencies."
> >
> > https://www.apache.org/legal/release-policy.html#licensing-documentation
> >
> >> The logic is the following : we are distributing packages (either
> >> sources or bianeis - for convenience, as The ASF is only required to
> >> deliver source packages for the users to build them -), and we *must*
> >> not give an opportinuty for our users to make a mistake and embed an
> >> incompatible component, or forget to add a required notice or license in
> >> their own packages, putting them at risk of being sued because of that.
> >>
> >> We can think that if a company is going to use our packages should do
> >> their due diligence, but that is putting too much of a burden on them.
> >> More important, it would be very bad PR for The ASF if we were to forgot
> >> some of teh required N
> > I agree with you. But I think it's two differenct cases:
> >
> > 1) The content of a distributed package.
> > 1a) If the package only contains source code witten by ASF committers or
> > the compiled class files then the minimal N applies. (Note: this would
> > probably not apply if we would code against an API of an GPL library,
> > that's why it's not allowed in ASF projects).
> > 1b) If some source code was borrowed e.g. from some 3rd party licensed
> > under MIT then we need to include that license and copyright notice.
> > 1d) And only if we bundle (redistribute) 3rd party content (e.g. in an
> > uber jars or binary distribution or installer) then all required N of
> > the bundled artifacts have to be added.
>
> On the same page, as soon as we are talking about source package.
>
> >
> > 2) The dependencies. As long as they are not bundled then they must not
> > be added to N
> correct.
>
> >  But of course it's our duty to make sure that all used
> > dependencies are compatible to ALv2. And we should be nice to our users
> > and list the dependencies. And in fact we do that :). All the Maven
> > generated jars contain a META-INF/DEPENDENCIES file with all
> > dependencies and its licenses listed. And the Maven generated source zip
> > also containse a DEPENDENCIES file The only issue I see is that the
> > Kerby source package (kerby-all-1.0.0-source-release.zip) contains an
> > empty DEPENDENCIES (similar for ApacheDS, whereas for Fortress-core
> > looks fine). It's probably because of the multi-module build, but maybe
> > we can tune the Maven release build to include all dependencies for the
> > whole project.
> >
> >> So what does it mean for Kerby, specifically ? Let's check teh different
> >> use cases...
> >>
> >> 1) We are distributing sources only
> >>
> >> Ok, so we basically don't distribute any binary (libs or exe). Our users
> >> *must* build Kerby if they want to use one of the packages, or
> >> copy/paste kerby's code in their one code. Are we safe ? Not that much,
> >> as building the packages may pull some external dependencies and add
> >> them in the produced jars (typically, slf4j). In this case, the produced
> >> packages *must* include the embedded jars' N, if they are not fully AL
> >> 2.0, or if they required us to do so for any kind of reason (an AL 2.0
> >> bundle may have a NOTICE file that requires us to embed it. It could be
> >> attribution, a tribute for the cat's author, or anything...)
> > Here I disagree. If the users builds it then it's not our duty to
> > provide prober N because we don't redistribute what th user builds.
>
> Let me clarify : when we distribute only source package (aka tar.gz of
> source files) then this package 

Re: Questions about the release

[Emmanuel Lécharny]

Le 08/05/2017 à 14:44, Stefan Seelmann a écrit :
> On 05/08/2017 01:23 PM, Emmanuel Lécharny wrote:
>>
>> Le 08/05/2017 à 11:26, Colm O hEigeartaigh a écrit :
>>> Hi Emmanuel,
>>>
>>> Is there a wiki page or something that you are aware of at Apache that
>>> clearly lays out what the obligations of projects are for licenses + notice
>>> files for third party dependencies? It's something I've yet to clearly wrap
>>> my head around.
>> I think the page is the one pointed out by Stefan :
>>
>> https://www.apache.org/dev/licensing-howto.html#bundled-vs-non-bundled
>>
>> The thing is that it's not really clear to me too, because there is no
>> example on this page.
> Here is another one, that makes it IMHO clear that the source N should
> not include any information about dependencies:
>
> "LICENSE and NOTICE MUST NOT provide unnecessary information about
> materials which are not bundled in the package, such as separately
> downloaded dependencies."
>
> https://www.apache.org/legal/release-policy.html#licensing-documentation
>
>> The logic is the following : we are distributing packages (either
>> sources or bianeis - for convenience, as The ASF is only required to
>> deliver source packages for the users to build them -), and we *must*
>> not give an opportinuty for our users to make a mistake and embed an
>> incompatible component, or forget to add a required notice or license in
>> their own packages, putting them at risk of being sued because of that.
>>
>> We can think that if a company is going to use our packages should do
>> their due diligence, but that is putting too much of a burden on them.
>> More important, it would be very bad PR for The ASF if we were to forgot
>> some of teh required N
> I agree with you. But I think it's two differenct cases:
>
> 1) The content of a distributed package.
> 1a) If the package only contains source code witten by ASF committers or
> the compiled class files then the minimal N applies. (Note: this would
> probably not apply if we would code against an API of an GPL library,
> that's why it's not allowed in ASF projects).
> 1b) If some source code was borrowed e.g. from some 3rd party licensed
> under MIT then we need to include that license and copyright notice.
> 1d) And only if we bundle (redistribute) 3rd party content (e.g. in an
> uber jars or binary distribution or installer) then all required N of
> the bundled artifacts have to be added.

On the same page, as soon as we are talking about source package.

>
> 2) The dependencies. As long as they are not bundled then they must not
> be added to N
correct.

>  But of course it's our duty to make sure that all used
> dependencies are compatible to ALv2. And we should be nice to our users
> and list the dependencies. And in fact we do that :). All the Maven
> generated jars contain a META-INF/DEPENDENCIES file with all
> dependencies and its licenses listed. And the Maven generated source zip
> also containse a DEPENDENCIES file The only issue I see is that the
> Kerby source package (kerby-all-1.0.0-source-release.zip) contains an
> empty DEPENDENCIES (similar for ApacheDS, whereas for Fortress-core
> looks fine). It's probably because of the multi-module build, but maybe
> we can tune the Maven release build to include all dependencies for the
> whole project.
>
>> So what does it mean for Kerby, specifically ? Let's check teh different
>> use cases...
>>
>> 1) We are distributing sources only
>>
>> Ok, so we basically don't distribute any binary (libs or exe). Our users
>> *must* build Kerby if they want to use one of the packages, or
>> copy/paste kerby's code in their one code. Are we safe ? Not that much,
>> as building the packages may pull some external dependencies and add
>> them in the produced jars (typically, slf4j). In this case, the produced
>> packages *must* include the embedded jars' N, if they are not fully AL
>> 2.0, or if they required us to do so for any kind of reason (an AL 2.0
>> bundle may have a NOTICE file that requires us to embed it. It could be
>> attribution, a tribute for the cat's author, or anything...)
> Here I disagree. If the users builds it then it's not our duty to
> provide prober N because we don't redistribute what th user builds.

Let me clarify : when we distribute only source package (aka tar.gz of
source files) then this package dos not have to have any N file if we
don't embed binary components (like lib, images, whatever) in the jar,
or when we haven't copy/pasted any snippet of external code.

Now, the trick is that users will take this package and will build
binary packages out of it, and these binary packages must have the
required N files. That mean the build configuration must contain the
necessary instructions to get those required N files to be present in
the generated binary. This is what we do for ApacheDS, with the N file
present in the
installers-maven-plugin/src/main/resources/org/apache/directory/server/installers
directory. That what I meant when 

Re: Questions about the release

[Stefan Seelmann]

On 05/08/2017 01:23 PM, Emmanuel Lécharny wrote:
> 
> 
> Le 08/05/2017 à 11:26, Colm O hEigeartaigh a écrit :
>> Hi Emmanuel,
>>
>> Is there a wiki page or something that you are aware of at Apache that
>> clearly lays out what the obligations of projects are for licenses + notice
>> files for third party dependencies? It's something I've yet to clearly wrap
>> my head around.
> 
> I think the page is the one pointed out by Stefan :
> 
> https://www.apache.org/dev/licensing-howto.html#bundled-vs-non-bundled
> 
> The thing is that it's not really clear to me too, because there is no
> example on this page.

Here is another one, that makes it IMHO clear that the source N should
not include any information about dependencies:

"LICENSE and NOTICE MUST NOT provide unnecessary information about
materials which are not bundled in the package, such as separately
downloaded dependencies."

https://www.apache.org/legal/release-policy.html#licensing-documentation

> The logic is the following : we are distributing packages (either
> sources or bianeis - for convenience, as The ASF is only required to
> deliver source packages for the users to build them -), and we *must*
> not give an opportinuty for our users to make a mistake and embed an
> incompatible component, or forget to add a required notice or license in
> their own packages, putting them at risk of being sued because of that.
> 
> We can think that if a company is going to use our packages should do
> their due diligence, but that is putting too much of a burden on them.
> More important, it would be very bad PR for The ASF if we were to forgot
> some of teh required N

I agree with you. But I think it's two differenct cases:

1) The content of a distributed package.
1a) If the package only contains source code witten by ASF committers or
the compiled class files then the minimal N applies. (Note: this would
probably not apply if we would code against an API of an GPL library,
that's why it's not allowed in ASF projects).
1b) If some source code was borrowed e.g. from some 3rd party licensed
under MIT then we need to include that license and copyright notice.
1d) And only if we bundle (redistribute) 3rd party content (e.g. in an
uber jars or binary distribution or installer) then all required N of
the bundled artifacts have to be added.

2) The dependencies. As long as they are not bundled then they must not
be added to N But of course it's our duty to make sure that all used
dependencies are compatible to ALv2. And we should be nice to our users
and list the dependencies. And in fact we do that :). All the Maven
generated jars contain a META-INF/DEPENDENCIES file with all
dependencies and its licenses listed. And the Maven generated source zip
also containse a DEPENDENCIES file The only issue I see is that the
Kerby source package (kerby-all-1.0.0-source-release.zip) contains an
empty DEPENDENCIES (similar for ApacheDS, whereas for Fortress-core
looks fine). It's probably because of the multi-module build, but maybe
we can tune the Maven release build to include all dependencies for the
whole project.

> So what does it mean for Kerby, specifically ? Let's check teh different
> use cases...
> 
> 1) We are distributing sources only
> 
> Ok, so we basically don't distribute any binary (libs or exe). Our users
> *must* build Kerby if they want to use one of the packages, or
> copy/paste kerby's code in their one code. Are we safe ? Not that much,
> as building the packages may pull some external dependencies and add
> them in the produced jars (typically, slf4j). In this case, the produced
> packages *must* include the embedded jars' N, if they are not fully AL
> 2.0, or if they required us to do so for any kind of reason (an AL 2.0
> bundle may have a NOTICE file that requires us to embed it. It could be
> attribution, a tribute for the cat's author, or anything...)

Here I disagree. If the users builds it then it's not our duty to
provide prober N because we don't redistribute what th user builds.

> 2) We are distributing binaries
> 
> And, yes, the jars pulled from Maven *are* binaries. Again, we have to
> make sure that those binaries contain all the required N for all the
> embedded components in our jars.

If and only if 3rd party dependencies are bundled within the jar (like
an uber jar).

> 3) We are distributing installers
> 
> This is not Kerby's choice, it's ApacheDS and Studio choice, so I'll
> explain what is required for teh sake of clarity, but it wo'nt apply to
> Kerby. Installers are usually binaries that generate binaries. We have
> to verify that the installer's binaries are fully AL 2.0 compatible, and
> that the generated installers contain all the required N too.

Right, and it's lot of work to get it right ;)

> Why should we not add extraneous N files ? Because that would make our
> user's task too complex, and we don't want that.
> 
> 
> One last note about GPL/LGPL dependencies : GPL are clearly a no-no for
> us. As GPL is a 

Re: Questions about the release

[Colm O hEigeartaigh]

Hi Emmanuel,

Is there a wiki page or something that you are aware of at Apache that
clearly lays out what the obligations of projects are for licenses + notice
files for third party dependencies? It's something I've yet to clearly wrap
my head around.

Colm.

On Mon, May 8, 2017 at 10:22 AM, Emmanuel Lecharny 
wrote:

> As soon as I'll beback home !
>
>
> Le lun. 8 mai 2017 à 09:27, Li, Jiajia  a écrit :
>
> > I've added the slf4j N, mockito N, netty's NOTICE, hamcrest N,
> > bouncycastle N(used by netty, but not included in it's N),
> > Jline N(used by zookeeper, but not included in it's N)
> > You can find out the NOTICE at NOTICE file, the licenses in LICENSE file
> > and license/ folder.
> >
> > I also checked the following:
> > >>> Check the google gson N files.
> > Gson is released under the Apache 2.0 license.
> >
> > >>>check the nimbus-jose-jwt N
> > The library source code is provided under the Apache 2.0 license.
> >
> > >>>nimbus-jose-jwt has itself some dependencies that requires some N
> > (potentially, that has to be checked) :
> > >>>jcip-annotations, json-smart and bcprov-jdk15on
> > jcip-annotations, json-smart are under Apache 2.0 license, and I've added
> > bouncycastle license
> >
> > And checked the transitive dependencies:
> > commons-io: AL 2.0
> > log4j: AL 2.0
> > junit: AL 2.0
> >
> > @ Emmanuel, could you review the changes?
> >
> > Thanks
> > Jiajia
> >
> >
> > -Original Message-
> > From: Emmanuel Lécharny [mailto:elecha...@gmail.com]
> > Sent: Monday, May 8, 2017 12:18 PM
> > To: kerby@directory.apache.org
> > Subject: Questions about the release
> >
> > Hi guys,
> >
> >
> > I have checked all the modules, and their dependencies. Here is the
> result
> > :
> >
> >
> > kerby-all -> test[junit, assertj-core] : OK, no N, test
> >
> >  |
> >
> >  +-- kerby-common -> [commons.io] : OK, no N, Apache
> >  +-- kerby-pkix -> [slf4j-api], test[slf4j-simple, mockito-core] : Need
> to
> > add the slf4j N
> >  +-- kerby-kerb
> >
> >  ||
> >
> >  |+-- kerb-core -> OK
> >
> >  |+-- kerb-common -> [commons.io] : OK, no N, Apache
> >  |+-- kerb-util -> test[mockito-core] : OK, no N, test
> >  |+-- kerb-crypto -> OK
> >  |+-- kerb-identity -> OK
> >  |+-- kerb-identity-test -> test, no N
> >  |+-- kerb-client -> test[mockito-core]: OK, no N, test
> >  |+-- kerb-server -> test[slf4j-simple]: OK, no N, test
> >  |+-- kerb-kdc-test -> test, no N
> >  |+-- integration-test -> test, no N
> >  |+-- kerb-admin -> OK
> >  |+-- kerb-admin-server -> OK
> >  |+-- kerb-simplekdc -> OK
> >  |+-- kerb-client-api-all -> OK
> >  |+-- kerb-server-api-all -> OK
> >  +-- kerby-kdc -> [netty-transport, netty-handler, netty-common,
> > netty-codec, netty-buffer, slf4j-api] : Need to add the mockito mockito
> > N, add the netty's NOTICE file
> >
> >  +-- kerby-tool
> >
> >  ||
> >
> >  |+-- client-tool -> OK
> >  |+-- kdc-tool -> OK
> >
> >  +-- kerby-kdc-test  -> test, no N
> >  +-- kerby-backend
> >
> >  ||
> >
> >  |+-- ldap-backend -> test[slf4j-simple], OK, no N, test
> >  |+-- mavibot-backend -> test[slf4j-simple], OK, no N, test
> >  |+-- json-backend -> [com.google.code.gson], test[slf4j-simple] :
> > Check the google gson N files.
> >  |+-- zookeeper-backend-> OK
> >
> >  +-- kerby-dist
> >
> >  ||
> >
> >  |+-- kdc-dist -> [netty, gson, slf4j-api, slf4j-log4j12] : Check
> > the google gson N files. need to add the slf4j N, add the netty's
> > NOTICE file
> >  |+-- tool-dist-> [slf4j-api, slf4j-log4j12] : Need to add the slf4j
> > N
> >
> >  +-- benchmark -> benchmarks, no N
> >  +-- kerby-provider
> >
> >   |
> >
> >   +- token-provider -> [nimbus-jose-jwt] -> check the nimbus-jose-jwt
> > N
> >
> >
> > AFAICT, there are not that many missing bits, but there is one more step
> > to complete : check the transitive depndencies.
> >
> > Running mvn dependency:tree on modules which have external dependencies
> > should give the required informations. Typically, on token-provider, here
> > is what it gives :
> >
> >
> > MacBook-Pro:token-provider elecharny$ mvn dependency:tree Java
> HotSpot(TM)
> > 64-Bit Server VM warning: ignoring option MaxPermSize=256M; support was
> > removed in 8.0 [INFO] Scanning for projects...
> > [INFO]
> >
> > [INFO]
> > 
> > [INFO] Building Token provider 1.0.0
> > [INFO]
> > 
> > [INFO]
> > [INFO] --- maven-dependency-plugin:2.10:tree (default-cli) @
> > token-provider --- [INFO] org.apache.kerby:token-provider:jar:1.0.0
> > [INFO] +- org.apache.kerby:kerb-core:jar:1.0.0:compile
> > [INFO] |  \- org.apache.kerby:kerby-pkix:jar:1.0.0:compile
> > [INFO] | +- org.apache.kerby:kerby-asn1:jar:1.0.0:compile
> > [INFO] | +- org.apache.kerby:kerby-util:jar:1.0.0:compile
> 

Re: Questions about the release

[Emmanuel Lecharny]

As soon as I'll beback home !


Le lun. 8 mai 2017 à 09:27, Li, Jiajia  a écrit :

> I've added the slf4j N, mockito N, netty's NOTICE, hamcrest N,
> bouncycastle N(used by netty, but not included in it's N),
> Jline N(used by zookeeper, but not included in it's N)
> You can find out the NOTICE at NOTICE file, the licenses in LICENSE file
> and license/ folder.
>
> I also checked the following:
> >>> Check the google gson N files.
> Gson is released under the Apache 2.0 license.
>
> >>>check the nimbus-jose-jwt N
> The library source code is provided under the Apache 2.0 license.
>
> >>>nimbus-jose-jwt has itself some dependencies that requires some N
> (potentially, that has to be checked) :
> >>>jcip-annotations, json-smart and bcprov-jdk15on
> jcip-annotations, json-smart are under Apache 2.0 license, and I've added
> bouncycastle license
>
> And checked the transitive dependencies:
> commons-io: AL 2.0
> log4j: AL 2.0
> junit: AL 2.0
>
> @ Emmanuel, could you review the changes?
>
> Thanks
> Jiajia
>
>
> -Original Message-
> From: Emmanuel Lécharny [mailto:elecha...@gmail.com]
> Sent: Monday, May 8, 2017 12:18 PM
> To: kerby@directory.apache.org
> Subject: Questions about the release
>
> Hi guys,
>
>
> I have checked all the modules, and their dependencies. Here is the result
> :
>
>
> kerby-all -> test[junit, assertj-core] : OK, no N, test
>
>  |
>
>  +-- kerby-common -> [commons.io] : OK, no N, Apache
>  +-- kerby-pkix -> [slf4j-api], test[slf4j-simple, mockito-core] : Need to
> add the slf4j N
>  +-- kerby-kerb
>
>  ||
>
>  |+-- kerb-core -> OK
>
>  |+-- kerb-common -> [commons.io] : OK, no N, Apache
>  |+-- kerb-util -> test[mockito-core] : OK, no N, test
>  |+-- kerb-crypto -> OK
>  |+-- kerb-identity -> OK
>  |+-- kerb-identity-test -> test, no N
>  |+-- kerb-client -> test[mockito-core]: OK, no N, test
>  |+-- kerb-server -> test[slf4j-simple]: OK, no N, test
>  |+-- kerb-kdc-test -> test, no N
>  |+-- integration-test -> test, no N
>  |+-- kerb-admin -> OK
>  |+-- kerb-admin-server -> OK
>  |+-- kerb-simplekdc -> OK
>  |+-- kerb-client-api-all -> OK
>  |+-- kerb-server-api-all -> OK
>  +-- kerby-kdc -> [netty-transport, netty-handler, netty-common,
> netty-codec, netty-buffer, slf4j-api] : Need to add the mockito mockito
> N, add the netty's NOTICE file
>
>  +-- kerby-tool
>
>  ||
>
>  |+-- client-tool -> OK
>  |+-- kdc-tool -> OK
>
>  +-- kerby-kdc-test  -> test, no N
>  +-- kerby-backend
>
>  ||
>
>  |+-- ldap-backend -> test[slf4j-simple], OK, no N, test
>  |+-- mavibot-backend -> test[slf4j-simple], OK, no N, test
>  |+-- json-backend -> [com.google.code.gson], test[slf4j-simple] :
> Check the google gson N files.
>  |+-- zookeeper-backend-> OK
>
>  +-- kerby-dist
>
>  ||
>
>  |+-- kdc-dist -> [netty, gson, slf4j-api, slf4j-log4j12] : Check
> the google gson N files. need to add the slf4j N, add the netty's
> NOTICE file
>  |+-- tool-dist-> [slf4j-api, slf4j-log4j12] : Need to add the slf4j
> N
>
>  +-- benchmark -> benchmarks, no N
>  +-- kerby-provider
>
>   |
>
>   +- token-provider -> [nimbus-jose-jwt] -> check the nimbus-jose-jwt
> N
>
>
> AFAICT, there are not that many missing bits, but there is one more step
> to complete : check the transitive depndencies.
>
> Running mvn dependency:tree on modules which have external dependencies
> should give the required informations. Typically, on token-provider, here
> is what it gives :
>
>
> MacBook-Pro:token-provider elecharny$ mvn dependency:tree Java HotSpot(TM)
> 64-Bit Server VM warning: ignoring option MaxPermSize=256M; support was
> removed in 8.0 [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
> 
> [INFO] Building Token provider 1.0.0
> [INFO]
> 
> [INFO]
> [INFO] --- maven-dependency-plugin:2.10:tree (default-cli) @
> token-provider --- [INFO] org.apache.kerby:token-provider:jar:1.0.0
> [INFO] +- org.apache.kerby:kerb-core:jar:1.0.0:compile
> [INFO] |  \- org.apache.kerby:kerby-pkix:jar:1.0.0:compile
> [INFO] | +- org.apache.kerby:kerby-asn1:jar:1.0.0:compile
> [INFO] | +- org.apache.kerby:kerby-util:jar:1.0.0:compile
> [INFO] | \- org.slf4j:slf4j-api:jar:1.7.25:compile
> [INFO] +- com.nimbusds:nimbus-jose-jwt:jar:3.10:compile
> [INFO] |  +- net.jcip:jcip-annotations:jar:1.0:compile
> [INFO] |  +- net.minidev:json-smart:jar:1.3.1:compile
> [INFO] |  +- org.bouncycastle:bcprov-jdk15on:jar:1.52:compile
> [INFO] |  \- commons-io:commons-io:jar:2.4:compile
> [INFO] +- junit:junit:jar:4.12:test
> [INFO] |  \- org.hamcrest:hamcrest-core:jar:1.3:test
> [INFO] \- org.assertj:assertj-core:jar:2.6.0:test
> [INFO]
> 
> [INFO] BUILD SUCCESS
> [INFO]
> 

RE: Questions about the release

[Li, Jiajia]

Hi Emmanuel,

Thanks very much for listing out the dependencies of each modules, I will add 
the N based on your work.

Thanks
Jiajia

-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com] 
Sent: Monday, May 8, 2017 12:18 PM
To: kerby@directory.apache.org
Subject: Questions about the release

Hi guys,


I have checked all the modules, and their dependencies. Here is the result :


kerby-all -> test[junit, assertj-core] : OK, no N, test

 |

 +-- kerby-common -> [commons.io] : OK, no N, Apache
 +-- kerby-pkix -> [slf4j-api], test[slf4j-simple, mockito-core] : Need to add 
the slf4j N
 +-- kerby-kerb

 ||

 |+-- kerb-core -> OK

 |+-- kerb-common -> [commons.io] : OK, no N, Apache
 |+-- kerb-util -> test[mockito-core] : OK, no N, test
 |+-- kerb-crypto -> OK
 |+-- kerb-identity -> OK
 |+-- kerb-identity-test -> test, no N
 |+-- kerb-client -> test[mockito-core]: OK, no N, test
 |+-- kerb-server -> test[slf4j-simple]: OK, no N, test
 |+-- kerb-kdc-test -> test, no N
 |+-- integration-test -> test, no N
 |+-- kerb-admin -> OK
 |+-- kerb-admin-server -> OK
 |+-- kerb-simplekdc -> OK
 |+-- kerb-client-api-all -> OK
 |+-- kerb-server-api-all -> OK
 +-- kerby-kdc -> [netty-transport, netty-handler, netty-common, netty-codec, 
netty-buffer, slf4j-api] : Need to add the slf4j N, add the netty's NOTICE 
file

 +-- kerby-tool

 ||

 |+-- client-tool -> OK
 |+-- kdc-tool -> OK

 +-- kerby-kdc-test  -> test, no N
 +-- kerby-backend

 ||

 |+-- ldap-backend -> test[slf4j-simple], OK, no N, test
 |+-- mavibot-backend -> test[slf4j-simple], OK, no N, test
 |+-- json-backend -> [com.google.code.gson], test[slf4j-simple] :
Check the google gson N files.
 |+-- zookeeper-backend-> OK

 +-- kerby-dist

 ||

 |+-- kdc-dist -> [netty, gson, slf4j-api, slf4j-log4j12] : Check
the google gson N files. need to add the slf4j N, add the netty's NOTICE 
file
 |+-- tool-dist-> [slf4j-api, slf4j-log4j12] : Need to add the slf4j N

 +-- benchmark -> benchmarks, no N
 +-- kerby-provider

  |

  +- token-provider -> [nimbus-jose-jwt] -> check the nimbus-jose-jwt N


AFAICT, there are not that many missing bits, but there is one more step to 
complete : check the transitive depndencies.

Running mvn dependency:tree on modules which have external dependencies should 
give the required informations. Typically, on token-provider, here is what it 
gives :


MacBook-Pro:token-provider elecharny$ mvn dependency:tree Java HotSpot(TM) 
64-Bit Server VM warning: ignoring option MaxPermSize=256M; support was removed 
in 8.0 [INFO] Scanning for projects...
[INFO]

[INFO]

[INFO] Building Token provider 1.0.0
[INFO]

[INFO]
[INFO] --- maven-dependency-plugin:2.10:tree (default-cli) @ token-provider --- 
[INFO] org.apache.kerby:token-provider:jar:1.0.0
[INFO] +- org.apache.kerby:kerb-core:jar:1.0.0:compile
[INFO] |  \- org.apache.kerby:kerby-pkix:jar:1.0.0:compile
[INFO] | +- org.apache.kerby:kerby-asn1:jar:1.0.0:compile
[INFO] | +- org.apache.kerby:kerby-util:jar:1.0.0:compile
[INFO] | \- org.slf4j:slf4j-api:jar:1.7.25:compile
[INFO] +- com.nimbusds:nimbus-jose-jwt:jar:3.10:compile
[INFO] |  +- net.jcip:jcip-annotations:jar:1.0:compile
[INFO] |  +- net.minidev:json-smart:jar:1.3.1:compile
[INFO] |  +- org.bouncycastle:bcprov-jdk15on:jar:1.52:compile
[INFO] |  \- commons-io:commons-io:jar:2.4:compile
[INFO] +- junit:junit:jar:4.12:test
[INFO] |  \- org.hamcrest:hamcrest-core:jar:1.3:test
[INFO] \- org.assertj:assertj-core:jar:2.6.0:test
[INFO]

[INFO] BUILD SUCCESS
[INFO]

[INFO] Total time: 1.527 s
[INFO] Finished at: 2017-05-08T06:14:52+02:00 [INFO] Final Memory: 15M/247M 
[INFO]



As we can see, nimbus-jose-jwt has itself some dependencies that requires some 
N (potentially, that has to be checked) :
jcip-annotations, json-smart and bcprov-jdk15on. If nimbus-jose-jwt has done 
its job properly, its N files should already contain the required bits, but 
we must check.


This tas has to be ran on all the modules that have noapache and non-tests 
dependencies...


--
Emmanuel Lecharny

Symas.com
directory.apache.org