[DISCUSS] Installation JAR layout

[Kevin Minder <ke...@hortonworks.com>]

Hi Everyone,

I want to raise an issue I been thinking about regarding the layout of 
the install.  In particular the layout of the JARs.  Currently the build 
is using the Maven Shade plugin to create a single executable JARs for 
things like the server (bin/server-0.2.0-SNAPSHOT.jar), client shell 
(bin/shell-0.2.0-SHAPSHOT.jar) and test LDAP server 
(bin/ldap-0.2.0.SNAPSHOT.jar)

On one had I like this because it is neat and tidy.

On the other hand wearing my potential RM has it raises some concerns.

1) It complicates the LICENSE and NOTICE file generation since it is 
difficult to see what the dependencies are other than from reports.
2) The server and the shell likely share some dependencies. Creating 
self contained JARs for each causes duplication and disk bloat.
3) Does this cause or solve a patch issue?  Is it easier for customer to 
be given a new server-0.2.1-SNAPSHOT.jar to use instead of potentially a 
set of patched JARs?
4) The Apache build env seems to be running Maven 2 and the shade plugin 
we are using required Maven 3.

So this is what the "install" looks like now

bin/
     gateway-0.2.0-SNAPSHOT.jar
     ldap-0.2.0-SNAPSHOT.jar
     shell-0.2.0-SNAPSHOT.jar
lib/ - Empty but reserved for future use
ext/ - Empty but to be used by customers for custom extension
samples/ - Distributed sample files
templates/ - Distributed configuration templates
deployments/ - Location for customer topology deployments

The other option I can see is something like this where bin/ and lib/ 
would change

bin/
     gateway.jar - Empty executable jar with manifest main class and 
class path referring to JARs in lib/
     ldap.jar - Empty executable jar with manifest main class and class 
path referring to JARs in lib/
     shell.jar - Empty executable jar with manifest main class and class 
path referring to JARs in lib/
lib/
     gateway-server-0.2.0-SNAPSHOT.jar
     gateway-test-ldap-0.2.0-SNAPSHOT.jar
     gateway-shell-0.2.0-SNAPSHOT.jar
     commons-io-2.4.jar
     groovy-1.5.6.jar
     jetty-6.1.26.jar
     shiro-core-1.2.1.jar
     ... many more ...

Kevin.

Re: [DISCUSS] Installation JAR layout

[larry mccay <la...@gmail.com>]

Let it go unless someone wants a vote then you can revert.
Tests all pass - right?

On Fri, Mar 22, 2013 at 3:16 PM, Kevin Minder
<ke...@hortonworks.com> wrote:
> Uh Oh.
> I pushed by accident.  I know what you are all saying.  Sure it was an
> accident...  But it really was.
> What should I do now?  Try to figure how to revert it or only attempt that
> if people object?
> Kevin.
>
>
> On 3/22/13 12:36 PM, Kevin Minder wrote:
>>
>> Thanks. Just feeling this out and trying to figure out how to go fast
>> without being ignoring the community.  I'll be interested in what the
>> mentors have to say on the topic.
>>
>> On 3/22/13 12:25 PM, larry mccay wrote:
>>>
>>> I say make it so.
>>>
>>> Is this any different than a refactoring of the source, really?
>>> I think that votes are probably required for things that affect the
>>> community like a release which goes to the outside world.
>>>
>>> A change that fundamentally changes the architecture in such a way
>>> that existing extensions from outside the project will be affected
>>> would be another thing that we would need a vote for.
>>>
>>> A change in the charter and vision of the project would probably warrant
>>> a vote.
>>>
>>> IMHO - this is more of an internal change that doesn't affect the
>>> community or any existing extensions and shouldn't be slowed down by a
>>> vote.
>>>
>>> That said...
>>>
>>> +1 to the proposed layout and I suggest that you just commit it once
>>> done.
>>> If you are unsure about it a review request would suffice.
>>>
>>> On Fri, Mar 22, 2013 at 11:45 AM, Kevin Minder
>>> <ke...@hortonworks.com> wrote:
>>>>
>>>> So how does this work?
>>>>
>>>> I've spent the last 24 hours digging deep into Maven assemblies and
>>>> finally
>>>> have a working standalone prototype that can be used to implement the
>>>> second
>>>> model described below.
>>>> Both Larry and I prefer this model instead of the current model. This
>>>> preferred model has individual jars as opposed to creating large
>>>> executable
>>>> jars that contain all dependencies.
>>>>
>>>> So my question is how long should I wait to implement?
>>>> I don't really expect much of an opinion from anyone other that Larry at
>>>> this point BTW.
>>>>
>>>> Perhaps I'll do the work and submit a patch to the list for review and
>>>> if
>>>> nobody has input by say Monday morning apply the patch?
>>>>
>>>>
>>>> On 3/21/13 3:26 PM, larry mccay wrote:
>>>>>>
>>>>>> The other option I can see is something like this where bin/ and lib/
>>>>>> would
>>>>>> change
>>>>>>
>>>>>> bin/
>>>>>>       gateway.jar - Empty executable jar with manifest main class and
>>>>>> class
>>>>>> path referring to JARs in lib/
>>>>>>       ldap.jar - Empty executable jar with manifest main class and
>>>>>> class
>>>>>> path
>>>>>> referring to JARs in lib/
>>>>>>       shell.jar - Empty executable jar with manifest main class and
>>>>>> class
>>>>>> path
>>>>>> referring to JARs in lib/
>>>>>> lib/
>>>>>>       gateway-server-0.2.0-SNAPSHOT.jar
>>>>>>       gateway-test-ldap-0.2.0-SNAPSHOT.jar
>>>>>>       gateway-shell-0.2.0-SNAPSHOT.jar
>>>>>>       commons-io-2.4.jar
>>>>>>       groovy-1.5.6.jar
>>>>>>       jetty-6.1.26.jar
>>>>>>       shiro-core-1.2.1.jar
>>>>>>       ... many more ...
>>>>>>
>>>>> I believe that this is my preference.
>>>>> We may also want to add a gateway-common module that can be pulled out
>>>>> as a separate jar so that shell doesn't need to depend on all of
>>>>> server in order for them to share internal dependencies.
>>>>>
>>>>> Anyway - this approach gets my +1.
>>>>>
>>>>> On Thu, Mar 21, 2013 at 12:10 PM, Kevin Minder
>>>>> <ke...@hortonworks.com> wrote:
>>>>>>
>>>>>> Hi Everyone,
>>>>>>
>>>>>> I want to raise an issue I been thinking about regarding the layout of
>>>>>> the
>>>>>> install.  In particular the layout of the JARs.  Currently the build
>>>>>> is
>>>>>> using the Maven Shade plugin to create a single executable JARs for
>>>>>> things
>>>>>> like the server (bin/server-0.2.0-SNAPSHOT.jar), client shell
>>>>>> (bin/shell-0.2.0-SHAPSHOT.jar) and test LDAP server
>>>>>> (bin/ldap-0.2.0.SNAPSHOT.jar)
>>>>>>
>>>>>> On one had I like this because it is neat and tidy.
>>>>>>
>>>>>> On the other hand wearing my potential RM has it raises some concerns.
>>>>>>
>>>>>> 1) It complicates the LICENSE and NOTICE file generation since it is
>>>>>> difficult to see what the dependencies are other than from reports.
>>>>>> 2) The server and the shell likely share some dependencies. Creating
>>>>>> self
>>>>>> contained JARs for each causes duplication and disk bloat.
>>>>>> 3) Does this cause or solve a patch issue?  Is it easier for customer
>>>>>> to
>>>>>> be
>>>>>> given a new server-0.2.1-SNAPSHOT.jar to use instead of potentially a
>>>>>> set
>>>>>> of
>>>>>> patched JARs?
>>>>>> 4) The Apache build env seems to be running Maven 2 and the shade
>>>>>> plugin
>>>>>> we
>>>>>> are using required Maven 3.
>>>>>>
>>>>>> So this is what the "install" looks like now
>>>>>>
>>>>>> bin/
>>>>>>       gateway-0.2.0-SNAPSHOT.jar
>>>>>>       ldap-0.2.0-SNAPSHOT.jar
>>>>>>       shell-0.2.0-SNAPSHOT.jar
>>>>>> lib/ - Empty but reserved for future use
>>>>>> ext/ - Empty but to be used by customers for custom extension
>>>>>> samples/ - Distributed sample files
>>>>>> templates/ - Distributed configuration templates
>>>>>> deployments/ - Location for customer topology deployments
>>>>>>
>>>>>> The other option I can see is something like this where bin/ and lib/
>>>>>> would
>>>>>> change
>>>>>>
>>>>>> bin/
>>>>>>       gateway.jar - Empty executable jar with manifest main class and
>>>>>> class
>>>>>> path referring to JARs in lib/
>>>>>>       ldap.jar - Empty executable jar with manifest main class and
>>>>>> class
>>>>>> path
>>>>>> referring to JARs in lib/
>>>>>>       shell.jar - Empty executable jar with manifest main class and
>>>>>> class
>>>>>> path
>>>>>> referring to JARs in lib/
>>>>>> lib/
>>>>>>       gateway-server-0.2.0-SNAPSHOT.jar
>>>>>>       gateway-test-ldap-0.2.0-SNAPSHOT.jar
>>>>>>       gateway-shell-0.2.0-SNAPSHOT.jar
>>>>>>       commons-io-2.4.jar
>>>>>>       groovy-1.5.6.jar
>>>>>>       jetty-6.1.26.jar
>>>>>>       shiro-core-1.2.1.jar
>>>>>>       ... many more ...
>>>>>>
>>>>>> Kevin.
>>>>
>>>>
>>
>

Re: [DISCUSS] Installation JAR layout

["Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>]

And to add to Alan's great explanation already:

I usually operate in CTR and in RTC. First off, I love Review Board,
and Apache has an instance that we can easily request a group in:

http://reviews.apache.org/

Typically my litmus test is:

* is this a portion of the project that's controversial, or that more than
1 person is working on? Will my change affect that? OK, get feedback from
my buddies and throw up an RB, with RTC.

* is this a portion of the code that no one gives a rip about, or that's
new,
or that I know no one but me will care about? Then I'll just forge
forward, 
CTR, and then rock it.

I think we should be able to do both. RTC tends to block newer community
members out.
CTR doesn't and makes them feel all warm and fuzzy. Let's do both, but not
have a bunch
of bylaws, and mandates and etc. We're all in it to win it here.

If we need help:

http://www.apache.org/foundation/how-it-works.html

http://www.apache.org/dev/pmc.html

http://incubator.apache.org/guides/ppmc.html

http://www.apache.org/foundation/voting.html


And of course us mentors will help as much as possible too!

Cheers,
Chris


On 3/22/13 1:11 PM, "Kevin Minder" <km...@gmail.com> wrote:

>We'll first off I'd have created a Jira if Jira was setup.  That is the
>last piece of infra that we don't have yet.
>
>Second wrt CRT/RTC, this is something we should probably discuss. It
>feels to me like RTC could really hamper productivity.  The mentors
>probably have some strong opinions about this so I'd like to hear them.
>
>On 3/22/13 4:08 PM, Alan Gates wrote:
>> A question first before I try to answer your question:  Is Knox CTR or
>>RTC?  CTR (commit then review) is committers are allowed to commit and
>>other committers are expected to review within a few days if they have
>>concerns.  RTC (review then commit) is a committer needs a +1 from
>>another committer before committing (or in this case pushing) their
>>code.  CTR lends itself better to projects that are more worried about
>>speed and RTC works well in projects that want to be biased towards
>>stability at the cost of speed.
>>
>> If Knox is CTR, then no problem.  If it's RTC you technically should
>>pull out the change and wait for a +1.  Given that Larry has effectively
>>+1'd your change by saying "leave it", even if it's RTC I'd probably
>>leave it at this point.
>>
>> To answer the other question, coding changes like this don't generally
>>need an explicit vote.  When you post the patch you're giving people a
>>chance to vote up or down on the change on the JIRA.  And for code
>>changes it's lazy consensus (that is, if someone doesn't vote then
>>"silence implies consent").
>>
>> Which leads me to another question.  Is there a JIRA for this change?
>>I am not sure how the projects using git are integrating with JIRA.  But
>>having a JIRA ticket with code for the change posted on it is invaluable
>>for allowing others to see what you're doing and give their feedback.
>>
>> Alan.
>>
>> On Mar 22, 2013, at 12:16 PM, Kevin Minder wrote:
>>
>>> Uh Oh.
>>> I pushed by accident.  I know what you are all saying.  Sure it was an
>>>accident...  But it really was.
>>> What should I do now?  Try to figure how to revert it or only attempt
>>>that if people object?
>>> Kevin.
>>>
>>> On 3/22/13 12:36 PM, Kevin Minder wrote:
>>>> Thanks. Just feeling this out and trying to figure out how to go fast
>>>>without being ignoring the community.  I'll be interested in what the
>>>>mentors have to say on the topic.
>>>>
>>>> On 3/22/13 12:25 PM, larry mccay wrote:
>>>>> I say make it so.
>>>>>
>>>>> Is this any different than a refactoring of the source, really?
>>>>> I think that votes are probably required for things that affect the
>>>>> community like a release which goes to the outside world.
>>>>>
>>>>> A change that fundamentally changes the architecture in such a way
>>>>> that existing extensions from outside the project will be affected
>>>>> would be another thing that we would need a vote for.
>>>>>
>>>>> A change in the charter and vision of the project would probably
>>>>>warrant a vote.
>>>>>
>>>>> IMHO - this is more of an internal change that doesn't affect the
>>>>> community or any existing extensions and shouldn't be slowed down by
>>>>>a
>>>>> vote.
>>>>>
>>>>> That said...
>>>>>
>>>>> +1 to the proposed layout and I suggest that you just commit it once
>>>>>done.
>>>>> If you are unsure about it a review request would suffice.
>>>>>
>>>>> On Fri, Mar 22, 2013 at 11:45 AM, Kevin Minder
>>>>> <ke...@hortonworks.com> wrote:
>>>>>> So how does this work?
>>>>>>
>>>>>> I've spent the last 24 hours digging deep into Maven assemblies and
>>>>>>finally
>>>>>> have a working standalone prototype that can be used to implement
>>>>>>the second
>>>>>> model described below.
>>>>>> Both Larry and I prefer this model instead of the current model.
>>>>>>This
>>>>>> preferred model has individual jars as opposed to creating large
>>>>>>executable
>>>>>> jars that contain all dependencies.
>>>>>>
>>>>>> So my question is how long should I wait to implement?
>>>>>> I don't really expect much of an opinion from anyone other that
>>>>>>Larry at
>>>>>> this point BTW.
>>>>>>
>>>>>> Perhaps I'll do the work and submit a patch to the list for review
>>>>>>and if
>>>>>> nobody has input by say Monday morning apply the patch?
>>>>>>
>>>>>>
>>>>>> On 3/21/13 3:26 PM, larry mccay wrote:
>>>>>>>> The other option I can see is something like this where bin/ and
>>>>>>>>lib/
>>>>>>>> would
>>>>>>>> change
>>>>>>>>
>>>>>>>> bin/
>>>>>>>>       gateway.jar - Empty executable jar with manifest main class
>>>>>>>>and
>>>>>>>> class
>>>>>>>> path referring to JARs in lib/
>>>>>>>>       ldap.jar - Empty executable jar with manifest main class
>>>>>>>>and class
>>>>>>>> path
>>>>>>>> referring to JARs in lib/
>>>>>>>>       shell.jar - Empty executable jar with manifest main class
>>>>>>>>and class
>>>>>>>> path
>>>>>>>> referring to JARs in lib/
>>>>>>>> lib/
>>>>>>>>       gateway-server-0.2.0-SNAPSHOT.jar
>>>>>>>>       gateway-test-ldap-0.2.0-SNAPSHOT.jar
>>>>>>>>       gateway-shell-0.2.0-SNAPSHOT.jar
>>>>>>>>       commons-io-2.4.jar
>>>>>>>>       groovy-1.5.6.jar
>>>>>>>>       jetty-6.1.26.jar
>>>>>>>>       shiro-core-1.2.1.jar
>>>>>>>>       ... many more ...
>>>>>>>>
>>>>>>> I believe that this is my preference.
>>>>>>> We may also want to add a gateway-common module that can be pulled
>>>>>>>out
>>>>>>> as a separate jar so that shell doesn't need to depend on all of
>>>>>>> server in order for them to share internal dependencies.
>>>>>>>
>>>>>>> Anyway - this approach gets my +1.
>>>>>>>
>>>>>>> On Thu, Mar 21, 2013 at 12:10 PM, Kevin Minder
>>>>>>> <ke...@hortonworks.com> wrote:
>>>>>>>> Hi Everyone,
>>>>>>>>
>>>>>>>> I want to raise an issue I been thinking about regarding the
>>>>>>>>layout of
>>>>>>>> the
>>>>>>>> install.  In particular the layout of the JARs.  Currently the
>>>>>>>>build is
>>>>>>>> using the Maven Shade plugin to create a single executable JARs
>>>>>>>>for
>>>>>>>> things
>>>>>>>> like the server (bin/server-0.2.0-SNAPSHOT.jar), client shell
>>>>>>>> (bin/shell-0.2.0-SHAPSHOT.jar) and test LDAP server
>>>>>>>> (bin/ldap-0.2.0.SNAPSHOT.jar)
>>>>>>>>
>>>>>>>> On one had I like this because it is neat and tidy.
>>>>>>>>
>>>>>>>> On the other hand wearing my potential RM has it raises some
>>>>>>>>concerns.
>>>>>>>>
>>>>>>>> 1) It complicates the LICENSE and NOTICE file generation since it
>>>>>>>>is
>>>>>>>> difficult to see what the dependencies are other than from
>>>>>>>>reports.
>>>>>>>> 2) The server and the shell likely share some dependencies.
>>>>>>>>Creating self
>>>>>>>> contained JARs for each causes duplication and disk bloat.
>>>>>>>> 3) Does this cause or solve a patch issue?  Is it easier for
>>>>>>>>customer to
>>>>>>>> be
>>>>>>>> given a new server-0.2.1-SNAPSHOT.jar to use instead of
>>>>>>>>potentially a set
>>>>>>>> of
>>>>>>>> patched JARs?
>>>>>>>> 4) The Apache build env seems to be running Maven 2 and the shade
>>>>>>>>plugin
>>>>>>>> we
>>>>>>>> are using required Maven 3.
>>>>>>>>
>>>>>>>> So this is what the "install" looks like now
>>>>>>>>
>>>>>>>> bin/
>>>>>>>>       gateway-0.2.0-SNAPSHOT.jar
>>>>>>>>       ldap-0.2.0-SNAPSHOT.jar
>>>>>>>>       shell-0.2.0-SNAPSHOT.jar
>>>>>>>> lib/ - Empty but reserved for future use
>>>>>>>> ext/ - Empty but to be used by customers for custom extension
>>>>>>>> samples/ - Distributed sample files
>>>>>>>> templates/ - Distributed configuration templates
>>>>>>>> deployments/ - Location for customer topology deployments
>>>>>>>>
>>>>>>>> The other option I can see is something like this where bin/ and
>>>>>>>>lib/
>>>>>>>> would
>>>>>>>> change
>>>>>>>>
>>>>>>>> bin/
>>>>>>>>       gateway.jar - Empty executable jar with manifest main class
>>>>>>>>and
>>>>>>>> class
>>>>>>>> path referring to JARs in lib/
>>>>>>>>       ldap.jar - Empty executable jar with manifest main class
>>>>>>>>and class
>>>>>>>> path
>>>>>>>> referring to JARs in lib/
>>>>>>>>       shell.jar - Empty executable jar with manifest main class
>>>>>>>>and class
>>>>>>>> path
>>>>>>>> referring to JARs in lib/
>>>>>>>> lib/
>>>>>>>>       gateway-server-0.2.0-SNAPSHOT.jar
>>>>>>>>       gateway-test-ldap-0.2.0-SNAPSHOT.jar
>>>>>>>>       gateway-shell-0.2.0-SNAPSHOT.jar
>>>>>>>>       commons-io-2.4.jar
>>>>>>>>       groovy-1.5.6.jar
>>>>>>>>       jetty-6.1.26.jar
>>>>>>>>       shiro-core-1.2.1.jar
>>>>>>>>       ... many more ...
>>>>>>>>
>>>>>>>> Kevin.
>

Re: [DISCUSS] Installation JAR layout

["Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>]

Larry +1 we need to be able to do both, and it's usually scenario driven
at least in
my experience.

Cheers,
Chris


On 3/22/13 1:38 PM, "larry mccay" <la...@gmail.com> wrote:

>I would certainly lean toward CTR while we are in the early stages of
>the project and a small number of committers.
>We can easily review changes that look interesting as they go by.
>
>As we get close to a release it may make sense to switch to RTC until it
>ships.
>
>@Alan, do projects generally switch that way?
>
>Given half decent test coverage day to day changes shouldn't require RTC.
>Any time you feel like changes could use another set of eyes just send
>a review request.
>
>On Fri, Mar 22, 2013 at 4:11 PM, Kevin Minder <km...@gmail.com> wrote:
>> We'll first off I'd have created a Jira if Jira was setup.  That is the
>>last
>> piece of infra that we don't have yet.
>>
>> Second wrt CRT/RTC, this is something we should probably discuss. It
>>feels
>> to me like RTC could really hamper productivity.  The mentors probably
>>have
>> some strong opinions about this so I'd like to hear them.
>>
>>
>> On 3/22/13 4:08 PM, Alan Gates wrote:
>>>
>>> A question first before I try to answer your question:  Is Knox CTR or
>>> RTC?  CTR (commit then review) is committers are allowed to commit and
>>>other
>>> committers are expected to review within a few days if they have
>>>concerns.
>>> RTC (review then commit) is a committer needs a +1 from another
>>>committer
>>> before committing (or in this case pushing) their code.  CTR lends
>>>itself
>>> better to projects that are more worried about speed and RTC works
>>>well in
>>> projects that want to be biased towards stability at the cost of speed.
>>>
>>> If Knox is CTR, then no problem.  If it's RTC you technically should
>>>pull
>>> out the change and wait for a +1.  Given that Larry has effectively
>>>+1'd
>>> your change by saying "leave it", even if it's RTC I'd probably leave
>>>it at
>>> this point.
>>>
>>> To answer the other question, coding changes like this don't generally
>>> need an explicit vote.  When you post the patch you're giving people a
>>> chance to vote up or down on the change on the JIRA.  And for code
>>>changes
>>> it's lazy consensus (that is, if someone doesn't vote then "silence
>>>implies
>>> consent").
>>>
>>> Which leads me to another question.  Is there a JIRA for this change?
>>>I
>>> am not sure how the projects using git are integrating with JIRA.  But
>>> having a JIRA ticket with code for the change posted on it is
>>>invaluable for
>>> allowing others to see what you're doing and give their feedback.
>>>
>>> Alan.
>>>
>>> On Mar 22, 2013, at 12:16 PM, Kevin Minder wrote:
>>>
>>>> Uh Oh.
>>>> I pushed by accident.  I know what you are all saying.  Sure it was an
>>>> accident...  But it really was.
>>>> What should I do now?  Try to figure how to revert it or only attempt
>>>> that if people object?
>>>> Kevin.
>>>>
>>>> On 3/22/13 12:36 PM, Kevin Minder wrote:
>>>>>
>>>>> Thanks. Just feeling this out and trying to figure out how to go fast
>>>>> without being ignoring the community.  I'll be interested in what the
>>>>> mentors have to say on the topic.
>>>>>
>>>>> On 3/22/13 12:25 PM, larry mccay wrote:
>>>>>>
>>>>>> I say make it so.
>>>>>>
>>>>>> Is this any different than a refactoring of the source, really?
>>>>>> I think that votes are probably required for things that affect the
>>>>>> community like a release which goes to the outside world.
>>>>>>
>>>>>> A change that fundamentally changes the architecture in such a way
>>>>>> that existing extensions from outside the project will be affected
>>>>>> would be another thing that we would need a vote for.
>>>>>>
>>>>>> A change in the charter and vision of the project would probably
>>>>>> warrant a vote.
>>>>>>
>>>>>> IMHO - this is more of an internal change that doesn't affect the
>>>>>> community or any existing extensions and shouldn't be slowed down
>>>>>>by a
>>>>>> vote.
>>>>>>
>>>>>> That said...
>>>>>>
>>>>>> +1 to the proposed layout and I suggest that you just commit it once
>>>>>> done.
>>>>>> If you are unsure about it a review request would suffice.
>>>>>>
>>>>>> On Fri, Mar 22, 2013 at 11:45 AM, Kevin Minder
>>>>>> <ke...@hortonworks.com> wrote:
>>>>>>>
>>>>>>> So how does this work?
>>>>>>>
>>>>>>> I've spent the last 24 hours digging deep into Maven assemblies and
>>>>>>> finally
>>>>>>> have a working standalone prototype that can be used to implement
>>>>>>>the
>>>>>>> second
>>>>>>> model described below.
>>>>>>> Both Larry and I prefer this model instead of the current model.
>>>>>>>This
>>>>>>> preferred model has individual jars as opposed to creating large
>>>>>>> executable
>>>>>>> jars that contain all dependencies.
>>>>>>>
>>>>>>> So my question is how long should I wait to implement?
>>>>>>> I don't really expect much of an opinion from anyone other that
>>>>>>>Larry
>>>>>>> at
>>>>>>> this point BTW.
>>>>>>>
>>>>>>> Perhaps I'll do the work and submit a patch to the list for review
>>>>>>>and
>>>>>>> if
>>>>>>> nobody has input by say Monday morning apply the patch?
>>>>>>>
>>>>>>>
>>>>>>> On 3/21/13 3:26 PM, larry mccay wrote:
>>>>>>>>>
>>>>>>>>> The other option I can see is something like this where bin/ and
>>>>>>>>> lib/
>>>>>>>>> would
>>>>>>>>> change
>>>>>>>>>
>>>>>>>>> bin/
>>>>>>>>>       gateway.jar - Empty executable jar with manifest main class
>>>>>>>>> and
>>>>>>>>> class
>>>>>>>>> path referring to JARs in lib/
>>>>>>>>>       ldap.jar - Empty executable jar with manifest main class
>>>>>>>>>and
>>>>>>>>> class
>>>>>>>>> path
>>>>>>>>> referring to JARs in lib/
>>>>>>>>>       shell.jar - Empty executable jar with manifest main class
>>>>>>>>>and
>>>>>>>>> class
>>>>>>>>> path
>>>>>>>>> referring to JARs in lib/
>>>>>>>>> lib/
>>>>>>>>>       gateway-server-0.2.0-SNAPSHOT.jar
>>>>>>>>>       gateway-test-ldap-0.2.0-SNAPSHOT.jar
>>>>>>>>>       gateway-shell-0.2.0-SNAPSHOT.jar
>>>>>>>>>       commons-io-2.4.jar
>>>>>>>>>       groovy-1.5.6.jar
>>>>>>>>>       jetty-6.1.26.jar
>>>>>>>>>       shiro-core-1.2.1.jar
>>>>>>>>>       ... many more ...
>>>>>>>>>
>>>>>>>> I believe that this is my preference.
>>>>>>>> We may also want to add a gateway-common module that can be pulled
>>>>>>>> out
>>>>>>>> as a separate jar so that shell doesn't need to depend on all of
>>>>>>>> server in order for them to share internal dependencies.
>>>>>>>>
>>>>>>>> Anyway - this approach gets my +1.
>>>>>>>>
>>>>>>>> On Thu, Mar 21, 2013 at 12:10 PM, Kevin Minder
>>>>>>>> <ke...@hortonworks.com> wrote:
>>>>>>>>>
>>>>>>>>> Hi Everyone,
>>>>>>>>>
>>>>>>>>> I want to raise an issue I been thinking about regarding the
>>>>>>>>>layout
>>>>>>>>> of
>>>>>>>>> the
>>>>>>>>> install.  In particular the layout of the JARs.  Currently the
>>>>>>>>>build
>>>>>>>>> is
>>>>>>>>> using the Maven Shade plugin to create a single executable JARs
>>>>>>>>>for
>>>>>>>>> things
>>>>>>>>> like the server (bin/server-0.2.0-SNAPSHOT.jar), client shell
>>>>>>>>> (bin/shell-0.2.0-SHAPSHOT.jar) and test LDAP server
>>>>>>>>> (bin/ldap-0.2.0.SNAPSHOT.jar)
>>>>>>>>>
>>>>>>>>> On one had I like this because it is neat and tidy.
>>>>>>>>>
>>>>>>>>> On the other hand wearing my potential RM has it raises some
>>>>>>>>> concerns.
>>>>>>>>>
>>>>>>>>> 1) It complicates the LICENSE and NOTICE file generation since
>>>>>>>>>it is
>>>>>>>>> difficult to see what the dependencies are other than from
>>>>>>>>>reports.
>>>>>>>>> 2) The server and the shell likely share some dependencies.
>>>>>>>>>Creating
>>>>>>>>> self
>>>>>>>>> contained JARs for each causes duplication and disk bloat.
>>>>>>>>> 3) Does this cause or solve a patch issue?  Is it easier for
>>>>>>>>> customer to
>>>>>>>>> be
>>>>>>>>> given a new server-0.2.1-SNAPSHOT.jar to use instead of
>>>>>>>>>potentially
>>>>>>>>> a set
>>>>>>>>> of
>>>>>>>>> patched JARs?
>>>>>>>>> 4) The Apache build env seems to be running Maven 2 and the shade
>>>>>>>>> plugin
>>>>>>>>> we
>>>>>>>>> are using required Maven 3.
>>>>>>>>>
>>>>>>>>> So this is what the "install" looks like now
>>>>>>>>>
>>>>>>>>> bin/
>>>>>>>>>       gateway-0.2.0-SNAPSHOT.jar
>>>>>>>>>       ldap-0.2.0-SNAPSHOT.jar
>>>>>>>>>       shell-0.2.0-SNAPSHOT.jar
>>>>>>>>> lib/ - Empty but reserved for future use
>>>>>>>>> ext/ - Empty but to be used by customers for custom extension
>>>>>>>>> samples/ - Distributed sample files
>>>>>>>>> templates/ - Distributed configuration templates
>>>>>>>>> deployments/ - Location for customer topology deployments
>>>>>>>>>
>>>>>>>>> The other option I can see is something like this where bin/ and
>>>>>>>>> lib/
>>>>>>>>> would
>>>>>>>>> change
>>>>>>>>>
>>>>>>>>> bin/
>>>>>>>>>       gateway.jar - Empty executable jar with manifest main class
>>>>>>>>> and
>>>>>>>>> class
>>>>>>>>> path referring to JARs in lib/
>>>>>>>>>       ldap.jar - Empty executable jar with manifest main class
>>>>>>>>>and
>>>>>>>>> class
>>>>>>>>> path
>>>>>>>>> referring to JARs in lib/
>>>>>>>>>       shell.jar - Empty executable jar with manifest main class
>>>>>>>>>and
>>>>>>>>> class
>>>>>>>>> path
>>>>>>>>> referring to JARs in lib/
>>>>>>>>> lib/
>>>>>>>>>       gateway-server-0.2.0-SNAPSHOT.jar
>>>>>>>>>       gateway-test-ldap-0.2.0-SNAPSHOT.jar
>>>>>>>>>       gateway-shell-0.2.0-SNAPSHOT.jar
>>>>>>>>>       commons-io-2.4.jar
>>>>>>>>>       groovy-1.5.6.jar
>>>>>>>>>       jetty-6.1.26.jar
>>>>>>>>>       shiro-core-1.2.1.jar
>>>>>>>>>       ... many more ...
>>>>>>>>>
>>>>>>>>> Kevin.
>>
>>

Re: [DISCUSS] Installation JAR layout

[larry mccay <la...@gmail.com>]

I would certainly lean toward CTR while we are in the early stages of
the project and a small number of committers.
We can easily review changes that look interesting as they go by.

As we get close to a release it may make sense to switch to RTC until it ships.

@Alan, do projects generally switch that way?

Given half decent test coverage day to day changes shouldn't require RTC.
Any time you feel like changes could use another set of eyes just send
a review request.

On Fri, Mar 22, 2013 at 4:11 PM, Kevin Minder <km...@gmail.com> wrote:
> We'll first off I'd have created a Jira if Jira was setup.  That is the last
> piece of infra that we don't have yet.
>
> Second wrt CRT/RTC, this is something we should probably discuss. It feels
> to me like RTC could really hamper productivity.  The mentors probably have
> some strong opinions about this so I'd like to hear them.
>
>
> On 3/22/13 4:08 PM, Alan Gates wrote:
>>
>> A question first before I try to answer your question:  Is Knox CTR or
>> RTC?  CTR (commit then review) is committers are allowed to commit and other
>> committers are expected to review within a few days if they have concerns.
>> RTC (review then commit) is a committer needs a +1 from another committer
>> before committing (or in this case pushing) their code.  CTR lends itself
>> better to projects that are more worried about speed and RTC works well in
>> projects that want to be biased towards stability at the cost of speed.
>>
>> If Knox is CTR, then no problem.  If it's RTC you technically should pull
>> out the change and wait for a +1.  Given that Larry has effectively +1'd
>> your change by saying "leave it", even if it's RTC I'd probably leave it at
>> this point.
>>
>> To answer the other question, coding changes like this don't generally
>> need an explicit vote.  When you post the patch you're giving people a
>> chance to vote up or down on the change on the JIRA.  And for code changes
>> it's lazy consensus (that is, if someone doesn't vote then "silence implies
>> consent").
>>
>> Which leads me to another question.  Is there a JIRA for this change?  I
>> am not sure how the projects using git are integrating with JIRA.  But
>> having a JIRA ticket with code for the change posted on it is invaluable for
>> allowing others to see what you're doing and give their feedback.
>>
>> Alan.
>>
>> On Mar 22, 2013, at 12:16 PM, Kevin Minder wrote:
>>
>>> Uh Oh.
>>> I pushed by accident.  I know what you are all saying.  Sure it was an
>>> accident...  But it really was.
>>> What should I do now?  Try to figure how to revert it or only attempt
>>> that if people object?
>>> Kevin.
>>>
>>> On 3/22/13 12:36 PM, Kevin Minder wrote:
>>>>
>>>> Thanks. Just feeling this out and trying to figure out how to go fast
>>>> without being ignoring the community.  I'll be interested in what the
>>>> mentors have to say on the topic.
>>>>
>>>> On 3/22/13 12:25 PM, larry mccay wrote:
>>>>>
>>>>> I say make it so.
>>>>>
>>>>> Is this any different than a refactoring of the source, really?
>>>>> I think that votes are probably required for things that affect the
>>>>> community like a release which goes to the outside world.
>>>>>
>>>>> A change that fundamentally changes the architecture in such a way
>>>>> that existing extensions from outside the project will be affected
>>>>> would be another thing that we would need a vote for.
>>>>>
>>>>> A change in the charter and vision of the project would probably
>>>>> warrant a vote.
>>>>>
>>>>> IMHO - this is more of an internal change that doesn't affect the
>>>>> community or any existing extensions and shouldn't be slowed down by a
>>>>> vote.
>>>>>
>>>>> That said...
>>>>>
>>>>> +1 to the proposed layout and I suggest that you just commit it once
>>>>> done.
>>>>> If you are unsure about it a review request would suffice.
>>>>>
>>>>> On Fri, Mar 22, 2013 at 11:45 AM, Kevin Minder
>>>>> <ke...@hortonworks.com> wrote:
>>>>>>
>>>>>> So how does this work?
>>>>>>
>>>>>> I've spent the last 24 hours digging deep into Maven assemblies and
>>>>>> finally
>>>>>> have a working standalone prototype that can be used to implement the
>>>>>> second
>>>>>> model described below.
>>>>>> Both Larry and I prefer this model instead of the current model. This
>>>>>> preferred model has individual jars as opposed to creating large
>>>>>> executable
>>>>>> jars that contain all dependencies.
>>>>>>
>>>>>> So my question is how long should I wait to implement?
>>>>>> I don't really expect much of an opinion from anyone other that Larry
>>>>>> at
>>>>>> this point BTW.
>>>>>>
>>>>>> Perhaps I'll do the work and submit a patch to the list for review and
>>>>>> if
>>>>>> nobody has input by say Monday morning apply the patch?
>>>>>>
>>>>>>
>>>>>> On 3/21/13 3:26 PM, larry mccay wrote:
>>>>>>>>
>>>>>>>> The other option I can see is something like this where bin/ and
>>>>>>>> lib/
>>>>>>>> would
>>>>>>>> change
>>>>>>>>
>>>>>>>> bin/
>>>>>>>>       gateway.jar - Empty executable jar with manifest main class
>>>>>>>> and
>>>>>>>> class
>>>>>>>> path referring to JARs in lib/
>>>>>>>>       ldap.jar - Empty executable jar with manifest main class and
>>>>>>>> class
>>>>>>>> path
>>>>>>>> referring to JARs in lib/
>>>>>>>>       shell.jar - Empty executable jar with manifest main class and
>>>>>>>> class
>>>>>>>> path
>>>>>>>> referring to JARs in lib/
>>>>>>>> lib/
>>>>>>>>       gateway-server-0.2.0-SNAPSHOT.jar
>>>>>>>>       gateway-test-ldap-0.2.0-SNAPSHOT.jar
>>>>>>>>       gateway-shell-0.2.0-SNAPSHOT.jar
>>>>>>>>       commons-io-2.4.jar
>>>>>>>>       groovy-1.5.6.jar
>>>>>>>>       jetty-6.1.26.jar
>>>>>>>>       shiro-core-1.2.1.jar
>>>>>>>>       ... many more ...
>>>>>>>>
>>>>>>> I believe that this is my preference.
>>>>>>> We may also want to add a gateway-common module that can be pulled
>>>>>>> out
>>>>>>> as a separate jar so that shell doesn't need to depend on all of
>>>>>>> server in order for them to share internal dependencies.
>>>>>>>
>>>>>>> Anyway - this approach gets my +1.
>>>>>>>
>>>>>>> On Thu, Mar 21, 2013 at 12:10 PM, Kevin Minder
>>>>>>> <ke...@hortonworks.com> wrote:
>>>>>>>>
>>>>>>>> Hi Everyone,
>>>>>>>>
>>>>>>>> I want to raise an issue I been thinking about regarding the layout
>>>>>>>> of
>>>>>>>> the
>>>>>>>> install.  In particular the layout of the JARs.  Currently the build
>>>>>>>> is
>>>>>>>> using the Maven Shade plugin to create a single executable JARs for
>>>>>>>> things
>>>>>>>> like the server (bin/server-0.2.0-SNAPSHOT.jar), client shell
>>>>>>>> (bin/shell-0.2.0-SHAPSHOT.jar) and test LDAP server
>>>>>>>> (bin/ldap-0.2.0.SNAPSHOT.jar)
>>>>>>>>
>>>>>>>> On one had I like this because it is neat and tidy.
>>>>>>>>
>>>>>>>> On the other hand wearing my potential RM has it raises some
>>>>>>>> concerns.
>>>>>>>>
>>>>>>>> 1) It complicates the LICENSE and NOTICE file generation since it is
>>>>>>>> difficult to see what the dependencies are other than from reports.
>>>>>>>> 2) The server and the shell likely share some dependencies. Creating
>>>>>>>> self
>>>>>>>> contained JARs for each causes duplication and disk bloat.
>>>>>>>> 3) Does this cause or solve a patch issue?  Is it easier for
>>>>>>>> customer to
>>>>>>>> be
>>>>>>>> given a new server-0.2.1-SNAPSHOT.jar to use instead of potentially
>>>>>>>> a set
>>>>>>>> of
>>>>>>>> patched JARs?
>>>>>>>> 4) The Apache build env seems to be running Maven 2 and the shade
>>>>>>>> plugin
>>>>>>>> we
>>>>>>>> are using required Maven 3.
>>>>>>>>
>>>>>>>> So this is what the "install" looks like now
>>>>>>>>
>>>>>>>> bin/
>>>>>>>>       gateway-0.2.0-SNAPSHOT.jar
>>>>>>>>       ldap-0.2.0-SNAPSHOT.jar
>>>>>>>>       shell-0.2.0-SNAPSHOT.jar
>>>>>>>> lib/ - Empty but reserved for future use
>>>>>>>> ext/ - Empty but to be used by customers for custom extension
>>>>>>>> samples/ - Distributed sample files
>>>>>>>> templates/ - Distributed configuration templates
>>>>>>>> deployments/ - Location for customer topology deployments
>>>>>>>>
>>>>>>>> The other option I can see is something like this where bin/ and
>>>>>>>> lib/
>>>>>>>> would
>>>>>>>> change
>>>>>>>>
>>>>>>>> bin/
>>>>>>>>       gateway.jar - Empty executable jar with manifest main class
>>>>>>>> and
>>>>>>>> class
>>>>>>>> path referring to JARs in lib/
>>>>>>>>       ldap.jar - Empty executable jar with manifest main class and
>>>>>>>> class
>>>>>>>> path
>>>>>>>> referring to JARs in lib/
>>>>>>>>       shell.jar - Empty executable jar with manifest main class and
>>>>>>>> class
>>>>>>>> path
>>>>>>>> referring to JARs in lib/
>>>>>>>> lib/
>>>>>>>>       gateway-server-0.2.0-SNAPSHOT.jar
>>>>>>>>       gateway-test-ldap-0.2.0-SNAPSHOT.jar
>>>>>>>>       gateway-shell-0.2.0-SNAPSHOT.jar
>>>>>>>>       commons-io-2.4.jar
>>>>>>>>       groovy-1.5.6.jar
>>>>>>>>       jetty-6.1.26.jar
>>>>>>>>       shiro-core-1.2.1.jar
>>>>>>>>       ... many more ...
>>>>>>>>
>>>>>>>> Kevin.
>
>

Re: [DISCUSS] Installation JAR layout

["Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>]

+1 to JIRAsŠ
+1 to being able to do both CTR and RTC.

Cheers,
Chris

P.S. Sorry have been behind on email :(

On 3/22/13 1:36 PM, "Alan Gates" <ga...@hortonworks.com> wrote:

>
>On Mar 22, 2013, at 1:11 PM, Kevin Minder wrote:
>
>> We'll first off I'd have created a Jira if Jira was setup.  That is the
>>last piece of infra that we don't have yet.
>
>Hmm, bummer.  We definitely want JIRAs so we can track the changes.
>Unless the git based projects don't do it that way.  Any feedback from
>mentors who've been on a git based project would be appreciated here.
>
>> 
>> Second wrt CRT/RTC, this is something we should probably discuss. It
>>feels to me like RTC could really hamper productivity.  The mentors
>>probably have some strong opinions about this so I'd like to hear them.
>The only strong opinion I have is that the project needs to pick one so
>people know what to expect.  My personal opinion is that CTR works better
>when a project is young and needs to move quickly and RTC works better
>when a project is mature and wants to guard against instability.  But
>this should be decided by the project committers more than then mentors.
>
>Alan.
>
>> 
>> On 3/22/13 4:08 PM, Alan Gates wrote:
>>> A question first before I try to answer your question:  Is Knox CTR or
>>>RTC?  CTR (commit then review) is committers are allowed to commit and
>>>other committers are expected to review within a few days if they have
>>>concerns.  RTC (review then commit) is a committer needs a +1 from
>>>another committer before committing (or in this case pushing) their
>>>code.  CTR lends itself better to projects that are more worried about
>>>speed and RTC works well in projects that want to be biased towards
>>>stability at the cost of speed.
>>> 
>>> If Knox is CTR, then no problem.  If it's RTC you technically should
>>>pull out the change and wait for a +1.  Given that Larry has
>>>effectively +1'd your change by saying "leave it", even if it's RTC I'd
>>>probably leave it at this point.
>>> 
>>> To answer the other question, coding changes like this don't generally
>>>need an explicit vote.  When you post the patch you're giving people a
>>>chance to vote up or down on the change on the JIRA.  And for code
>>>changes it's lazy consensus (that is, if someone doesn't vote then
>>>"silence implies consent").
>>> 
>>> Which leads me to another question.  Is there a JIRA for this change?
>>>I am not sure how the projects using git are integrating with JIRA.
>>>But having a JIRA ticket with code for the change posted on it is
>>>invaluable for allowing others to see what you're doing and give their
>>>feedback.
>>> 
>>> Alan.
>>> 
>>> On Mar 22, 2013, at 12:16 PM, Kevin Minder wrote:
>>> 
>>>> Uh Oh.
>>>> I pushed by accident.  I know what you are all saying.  Sure it was
>>>>an accident...  But it really was.
>>>> What should I do now?  Try to figure how to revert it or only attempt
>>>>that if people object?
>>>> Kevin.
>>>> 
>>>> On 3/22/13 12:36 PM, Kevin Minder wrote:
>>>>> Thanks. Just feeling this out and trying to figure out how to go
>>>>>fast without being ignoring the community.  I'll be interested in
>>>>>what the mentors have to say on the topic.
>>>>> 
>>>>> On 3/22/13 12:25 PM, larry mccay wrote:
>>>>>> I say make it so.
>>>>>> 
>>>>>> Is this any different than a refactoring of the source, really?
>>>>>> I think that votes are probably required for things that affect the
>>>>>> community like a release which goes to the outside world.
>>>>>> 
>>>>>> A change that fundamentally changes the architecture in such a way
>>>>>> that existing extensions from outside the project will be affected
>>>>>> would be another thing that we would need a vote for.
>>>>>> 
>>>>>> A change in the charter and vision of the project would probably
>>>>>>warrant a vote.
>>>>>> 
>>>>>> IMHO - this is more of an internal change that doesn't affect the
>>>>>> community or any existing extensions and shouldn't be slowed down
>>>>>>by a
>>>>>> vote.
>>>>>> 
>>>>>> That said...
>>>>>> 
>>>>>> +1 to the proposed layout and I suggest that you just commit it
>>>>>>once done.
>>>>>> If you are unsure about it a review request would suffice.
>>>>>> 
>>>>>> On Fri, Mar 22, 2013 at 11:45 AM, Kevin Minder
>>>>>> <ke...@hortonworks.com> wrote:
>>>>>>> So how does this work?
>>>>>>> 
>>>>>>> I've spent the last 24 hours digging deep into Maven assemblies
>>>>>>>and finally
>>>>>>> have a working standalone prototype that can be used to implement
>>>>>>>the second
>>>>>>> model described below.
>>>>>>> Both Larry and I prefer this model instead of the current model.
>>>>>>>This
>>>>>>> preferred model has individual jars as opposed to creating large
>>>>>>>executable
>>>>>>> jars that contain all dependencies.
>>>>>>> 
>>>>>>> So my question is how long should I wait to implement?
>>>>>>> I don't really expect much of an opinion from anyone other that
>>>>>>>Larry at
>>>>>>> this point BTW.
>>>>>>> 
>>>>>>> Perhaps I'll do the work and submit a patch to the list for review
>>>>>>>and if
>>>>>>> nobody has input by say Monday morning apply the patch?
>>>>>>> 
>>>>>>> 
>>>>>>> On 3/21/13 3:26 PM, larry mccay wrote:
>>>>>>>>> The other option I can see is something like this where bin/ and
>>>>>>>>>lib/
>>>>>>>>> would
>>>>>>>>> change
>>>>>>>>> 
>>>>>>>>> bin/
>>>>>>>>>      gateway.jar - Empty executable jar with manifest main class
>>>>>>>>>and
>>>>>>>>> class
>>>>>>>>> path referring to JARs in lib/
>>>>>>>>>      ldap.jar - Empty executable jar with manifest main class
>>>>>>>>>and class
>>>>>>>>> path
>>>>>>>>> referring to JARs in lib/
>>>>>>>>>      shell.jar - Empty executable jar with manifest main class
>>>>>>>>>and class
>>>>>>>>> path
>>>>>>>>> referring to JARs in lib/
>>>>>>>>> lib/
>>>>>>>>>      gateway-server-0.2.0-SNAPSHOT.jar
>>>>>>>>>      gateway-test-ldap-0.2.0-SNAPSHOT.jar
>>>>>>>>>      gateway-shell-0.2.0-SNAPSHOT.jar
>>>>>>>>>      commons-io-2.4.jar
>>>>>>>>>      groovy-1.5.6.jar
>>>>>>>>>      jetty-6.1.26.jar
>>>>>>>>>      shiro-core-1.2.1.jar
>>>>>>>>>      ... many more ...
>>>>>>>>> 
>>>>>>>> I believe that this is my preference.
>>>>>>>> We may also want to add a gateway-common module that can be
>>>>>>>>pulled out
>>>>>>>> as a separate jar so that shell doesn't need to depend on all of
>>>>>>>> server in order for them to share internal dependencies.
>>>>>>>> 
>>>>>>>> Anyway - this approach gets my +1.
>>>>>>>> 
>>>>>>>> On Thu, Mar 21, 2013 at 12:10 PM, Kevin Minder
>>>>>>>> <ke...@hortonworks.com> wrote:
>>>>>>>>> Hi Everyone,
>>>>>>>>> 
>>>>>>>>> I want to raise an issue I been thinking about regarding the
>>>>>>>>>layout of
>>>>>>>>> the
>>>>>>>>> install.  In particular the layout of the JARs.  Currently the
>>>>>>>>>build is
>>>>>>>>> using the Maven Shade plugin to create a single executable JARs
>>>>>>>>>for
>>>>>>>>> things
>>>>>>>>> like the server (bin/server-0.2.0-SNAPSHOT.jar), client shell
>>>>>>>>> (bin/shell-0.2.0-SHAPSHOT.jar) and test LDAP server
>>>>>>>>> (bin/ldap-0.2.0.SNAPSHOT.jar)
>>>>>>>>> 
>>>>>>>>> On one had I like this because it is neat and tidy.
>>>>>>>>> 
>>>>>>>>> On the other hand wearing my potential RM has it raises some
>>>>>>>>>concerns.
>>>>>>>>> 
>>>>>>>>> 1) It complicates the LICENSE and NOTICE file generation since
>>>>>>>>>it is
>>>>>>>>> difficult to see what the dependencies are other than from
>>>>>>>>>reports.
>>>>>>>>> 2) The server and the shell likely share some dependencies.
>>>>>>>>>Creating self
>>>>>>>>> contained JARs for each causes duplication and disk bloat.
>>>>>>>>> 3) Does this cause or solve a patch issue?  Is it easier for
>>>>>>>>>customer to
>>>>>>>>> be
>>>>>>>>> given a new server-0.2.1-SNAPSHOT.jar to use instead of
>>>>>>>>>potentially a set
>>>>>>>>> of
>>>>>>>>> patched JARs?
>>>>>>>>> 4) The Apache build env seems to be running Maven 2 and the
>>>>>>>>>shade plugin
>>>>>>>>> we
>>>>>>>>> are using required Maven 3.
>>>>>>>>> 
>>>>>>>>> So this is what the "install" looks like now
>>>>>>>>> 
>>>>>>>>> bin/
>>>>>>>>>      gateway-0.2.0-SNAPSHOT.jar
>>>>>>>>>      ldap-0.2.0-SNAPSHOT.jar
>>>>>>>>>      shell-0.2.0-SNAPSHOT.jar
>>>>>>>>> lib/ - Empty but reserved for future use
>>>>>>>>> ext/ - Empty but to be used by customers for custom extension
>>>>>>>>> samples/ - Distributed sample files
>>>>>>>>> templates/ - Distributed configuration templates
>>>>>>>>> deployments/ - Location for customer topology deployments
>>>>>>>>> 
>>>>>>>>> The other option I can see is something like this where bin/ and
>>>>>>>>>lib/
>>>>>>>>> would
>>>>>>>>> change
>>>>>>>>> 
>>>>>>>>> bin/
>>>>>>>>>      gateway.jar - Empty executable jar with manifest main class
>>>>>>>>>and
>>>>>>>>> class
>>>>>>>>> path referring to JARs in lib/
>>>>>>>>>      ldap.jar - Empty executable jar with manifest main class
>>>>>>>>>and class
>>>>>>>>> path
>>>>>>>>> referring to JARs in lib/
>>>>>>>>>      shell.jar - Empty executable jar with manifest main class
>>>>>>>>>and class
>>>>>>>>> path
>>>>>>>>> referring to JARs in lib/
>>>>>>>>> lib/
>>>>>>>>>      gateway-server-0.2.0-SNAPSHOT.jar
>>>>>>>>>      gateway-test-ldap-0.2.0-SNAPSHOT.jar
>>>>>>>>>      gateway-shell-0.2.0-SNAPSHOT.jar
>>>>>>>>>      commons-io-2.4.jar
>>>>>>>>>      groovy-1.5.6.jar
>>>>>>>>>      jetty-6.1.26.jar
>>>>>>>>>      shiro-core-1.2.1.jar
>>>>>>>>>      ... many more ...
>>>>>>>>> 
>>>>>>>>> Kevin.
>> 
>

Re: [DISCUSS] Installation JAR layout

[Alan Gates <ga...@hortonworks.com>]

On Mar 22, 2013, at 1:11 PM, Kevin Minder wrote:

> We'll first off I'd have created a Jira if Jira was setup.  That is the last piece of infra that we don't have yet.

Hmm, bummer.  We definitely want JIRAs so we can track the changes.  Unless the git based projects don't do it that way.  Any feedback from mentors who've been on a git based project would be appreciated here.

> 
> Second wrt CRT/RTC, this is something we should probably discuss. It feels to me like RTC could really hamper productivity.  The mentors probably have some strong opinions about this so I'd like to hear them.
The only strong opinion I have is that the project needs to pick one so people know what to expect.  My personal opinion is that CTR works better when a project is young and needs to move quickly and RTC works better when a project is mature and wants to guard against instability.  But this should be decided by the project committers more than then mentors.

Alan.

> 
> On 3/22/13 4:08 PM, Alan Gates wrote:
>> A question first before I try to answer your question:  Is Knox CTR or RTC?  CTR (commit then review) is committers are allowed to commit and other committers are expected to review within a few days if they have concerns.  RTC (review then commit) is a committer needs a +1 from another committer before committing (or in this case pushing) their code.  CTR lends itself better to projects that are more worried about speed and RTC works well in projects that want to be biased towards stability at the cost of speed.
>> 
>> If Knox is CTR, then no problem.  If it's RTC you technically should pull out the change and wait for a +1.  Given that Larry has effectively +1'd your change by saying "leave it", even if it's RTC I'd probably leave it at this point.
>> 
>> To answer the other question, coding changes like this don't generally need an explicit vote.  When you post the patch you're giving people a chance to vote up or down on the change on the JIRA.  And for code changes it's lazy consensus (that is, if someone doesn't vote then "silence implies consent").
>> 
>> Which leads me to another question.  Is there a JIRA for this change?  I am not sure how the projects using git are integrating with JIRA.  But having a JIRA ticket with code for the change posted on it is invaluable for allowing others to see what you're doing and give their feedback.
>> 
>> Alan.
>> 
>> On Mar 22, 2013, at 12:16 PM, Kevin Minder wrote:
>> 
>>> Uh Oh.
>>> I pushed by accident.  I know what you are all saying.  Sure it was an accident...  But it really was.
>>> What should I do now?  Try to figure how to revert it or only attempt that if people object?
>>> Kevin.
>>> 
>>> On 3/22/13 12:36 PM, Kevin Minder wrote:
>>>> Thanks. Just feeling this out and trying to figure out how to go fast without being ignoring the community.  I'll be interested in what the mentors have to say on the topic.
>>>> 
>>>> On 3/22/13 12:25 PM, larry mccay wrote:
>>>>> I say make it so.
>>>>> 
>>>>> Is this any different than a refactoring of the source, really?
>>>>> I think that votes are probably required for things that affect the
>>>>> community like a release which goes to the outside world.
>>>>> 
>>>>> A change that fundamentally changes the architecture in such a way
>>>>> that existing extensions from outside the project will be affected
>>>>> would be another thing that we would need a vote for.
>>>>> 
>>>>> A change in the charter and vision of the project would probably warrant a vote.
>>>>> 
>>>>> IMHO - this is more of an internal change that doesn't affect the
>>>>> community or any existing extensions and shouldn't be slowed down by a
>>>>> vote.
>>>>> 
>>>>> That said...
>>>>> 
>>>>> +1 to the proposed layout and I suggest that you just commit it once done.
>>>>> If you are unsure about it a review request would suffice.
>>>>> 
>>>>> On Fri, Mar 22, 2013 at 11:45 AM, Kevin Minder
>>>>> <ke...@hortonworks.com> wrote:
>>>>>> So how does this work?
>>>>>> 
>>>>>> I've spent the last 24 hours digging deep into Maven assemblies and finally
>>>>>> have a working standalone prototype that can be used to implement the second
>>>>>> model described below.
>>>>>> Both Larry and I prefer this model instead of the current model. This
>>>>>> preferred model has individual jars as opposed to creating large executable
>>>>>> jars that contain all dependencies.
>>>>>> 
>>>>>> So my question is how long should I wait to implement?
>>>>>> I don't really expect much of an opinion from anyone other that Larry at
>>>>>> this point BTW.
>>>>>> 
>>>>>> Perhaps I'll do the work and submit a patch to the list for review and if
>>>>>> nobody has input by say Monday morning apply the patch?
>>>>>> 
>>>>>> 
>>>>>> On 3/21/13 3:26 PM, larry mccay wrote:
>>>>>>>> The other option I can see is something like this where bin/ and lib/
>>>>>>>> would
>>>>>>>> change
>>>>>>>> 
>>>>>>>> bin/
>>>>>>>>      gateway.jar - Empty executable jar with manifest main class and
>>>>>>>> class
>>>>>>>> path referring to JARs in lib/
>>>>>>>>      ldap.jar - Empty executable jar with manifest main class and class
>>>>>>>> path
>>>>>>>> referring to JARs in lib/
>>>>>>>>      shell.jar - Empty executable jar with manifest main class and class
>>>>>>>> path
>>>>>>>> referring to JARs in lib/
>>>>>>>> lib/
>>>>>>>>      gateway-server-0.2.0-SNAPSHOT.jar
>>>>>>>>      gateway-test-ldap-0.2.0-SNAPSHOT.jar
>>>>>>>>      gateway-shell-0.2.0-SNAPSHOT.jar
>>>>>>>>      commons-io-2.4.jar
>>>>>>>>      groovy-1.5.6.jar
>>>>>>>>      jetty-6.1.26.jar
>>>>>>>>      shiro-core-1.2.1.jar
>>>>>>>>      ... many more ...
>>>>>>>> 
>>>>>>> I believe that this is my preference.
>>>>>>> We may also want to add a gateway-common module that can be pulled out
>>>>>>> as a separate jar so that shell doesn't need to depend on all of
>>>>>>> server in order for them to share internal dependencies.
>>>>>>> 
>>>>>>> Anyway - this approach gets my +1.
>>>>>>> 
>>>>>>> On Thu, Mar 21, 2013 at 12:10 PM, Kevin Minder
>>>>>>> <ke...@hortonworks.com> wrote:
>>>>>>>> Hi Everyone,
>>>>>>>> 
>>>>>>>> I want to raise an issue I been thinking about regarding the layout of
>>>>>>>> the
>>>>>>>> install.  In particular the layout of the JARs.  Currently the build is
>>>>>>>> using the Maven Shade plugin to create a single executable JARs for
>>>>>>>> things
>>>>>>>> like the server (bin/server-0.2.0-SNAPSHOT.jar), client shell
>>>>>>>> (bin/shell-0.2.0-SHAPSHOT.jar) and test LDAP server
>>>>>>>> (bin/ldap-0.2.0.SNAPSHOT.jar)
>>>>>>>> 
>>>>>>>> On one had I like this because it is neat and tidy.
>>>>>>>> 
>>>>>>>> On the other hand wearing my potential RM has it raises some concerns.
>>>>>>>> 
>>>>>>>> 1) It complicates the LICENSE and NOTICE file generation since it is
>>>>>>>> difficult to see what the dependencies are other than from reports.
>>>>>>>> 2) The server and the shell likely share some dependencies. Creating self
>>>>>>>> contained JARs for each causes duplication and disk bloat.
>>>>>>>> 3) Does this cause or solve a patch issue?  Is it easier for customer to
>>>>>>>> be
>>>>>>>> given a new server-0.2.1-SNAPSHOT.jar to use instead of potentially a set
>>>>>>>> of
>>>>>>>> patched JARs?
>>>>>>>> 4) The Apache build env seems to be running Maven 2 and the shade plugin
>>>>>>>> we
>>>>>>>> are using required Maven 3.
>>>>>>>> 
>>>>>>>> So this is what the "install" looks like now
>>>>>>>> 
>>>>>>>> bin/
>>>>>>>>      gateway-0.2.0-SNAPSHOT.jar
>>>>>>>>      ldap-0.2.0-SNAPSHOT.jar
>>>>>>>>      shell-0.2.0-SNAPSHOT.jar
>>>>>>>> lib/ - Empty but reserved for future use
>>>>>>>> ext/ - Empty but to be used by customers for custom extension
>>>>>>>> samples/ - Distributed sample files
>>>>>>>> templates/ - Distributed configuration templates
>>>>>>>> deployments/ - Location for customer topology deployments
>>>>>>>> 
>>>>>>>> The other option I can see is something like this where bin/ and lib/
>>>>>>>> would
>>>>>>>> change
>>>>>>>> 
>>>>>>>> bin/
>>>>>>>>      gateway.jar - Empty executable jar with manifest main class and
>>>>>>>> class
>>>>>>>> path referring to JARs in lib/
>>>>>>>>      ldap.jar - Empty executable jar with manifest main class and class
>>>>>>>> path
>>>>>>>> referring to JARs in lib/
>>>>>>>>      shell.jar - Empty executable jar with manifest main class and class
>>>>>>>> path
>>>>>>>> referring to JARs in lib/
>>>>>>>> lib/
>>>>>>>>      gateway-server-0.2.0-SNAPSHOT.jar
>>>>>>>>      gateway-test-ldap-0.2.0-SNAPSHOT.jar
>>>>>>>>      gateway-shell-0.2.0-SNAPSHOT.jar
>>>>>>>>      commons-io-2.4.jar
>>>>>>>>      groovy-1.5.6.jar
>>>>>>>>      jetty-6.1.26.jar
>>>>>>>>      shiro-core-1.2.1.jar
>>>>>>>>      ... many more ...
>>>>>>>> 
>>>>>>>> Kevin.
> 

Re: [DISCUSS] Installation JAR layout

[Kevin Minder <km...@gmail.com>]

We'll first off I'd have created a Jira if Jira was setup.  That is the 
last piece of infra that we don't have yet.

Second wrt CRT/RTC, this is something we should probably discuss. It 
feels to me like RTC could really hamper productivity.  The mentors 
probably have some strong opinions about this so I'd like to hear them.

On 3/22/13 4:08 PM, Alan Gates wrote:
> A question first before I try to answer your question:  Is Knox CTR or RTC?  CTR (commit then review) is committers are allowed to commit and other committers are expected to review within a few days if they have concerns.  RTC (review then commit) is a committer needs a +1 from another committer before committing (or in this case pushing) their code.  CTR lends itself better to projects that are more worried about speed and RTC works well in projects that want to be biased towards stability at the cost of speed.
>
> If Knox is CTR, then no problem.  If it's RTC you technically should pull out the change and wait for a +1.  Given that Larry has effectively +1'd your change by saying "leave it", even if it's RTC I'd probably leave it at this point.
>
> To answer the other question, coding changes like this don't generally need an explicit vote.  When you post the patch you're giving people a chance to vote up or down on the change on the JIRA.  And for code changes it's lazy consensus (that is, if someone doesn't vote then "silence implies consent").
>
> Which leads me to another question.  Is there a JIRA for this change?  I am not sure how the projects using git are integrating with JIRA.  But having a JIRA ticket with code for the change posted on it is invaluable for allowing others to see what you're doing and give their feedback.
>
> Alan.
>
> On Mar 22, 2013, at 12:16 PM, Kevin Minder wrote:
>
>> Uh Oh.
>> I pushed by accident.  I know what you are all saying.  Sure it was an accident...  But it really was.
>> What should I do now?  Try to figure how to revert it or only attempt that if people object?
>> Kevin.
>>
>> On 3/22/13 12:36 PM, Kevin Minder wrote:
>>> Thanks. Just feeling this out and trying to figure out how to go fast without being ignoring the community.  I'll be interested in what the mentors have to say on the topic.
>>>
>>> On 3/22/13 12:25 PM, larry mccay wrote:
>>>> I say make it so.
>>>>
>>>> Is this any different than a refactoring of the source, really?
>>>> I think that votes are probably required for things that affect the
>>>> community like a release which goes to the outside world.
>>>>
>>>> A change that fundamentally changes the architecture in such a way
>>>> that existing extensions from outside the project will be affected
>>>> would be another thing that we would need a vote for.
>>>>
>>>> A change in the charter and vision of the project would probably warrant a vote.
>>>>
>>>> IMHO - this is more of an internal change that doesn't affect the
>>>> community or any existing extensions and shouldn't be slowed down by a
>>>> vote.
>>>>
>>>> That said...
>>>>
>>>> +1 to the proposed layout and I suggest that you just commit it once done.
>>>> If you are unsure about it a review request would suffice.
>>>>
>>>> On Fri, Mar 22, 2013 at 11:45 AM, Kevin Minder
>>>> <ke...@hortonworks.com> wrote:
>>>>> So how does this work?
>>>>>
>>>>> I've spent the last 24 hours digging deep into Maven assemblies and finally
>>>>> have a working standalone prototype that can be used to implement the second
>>>>> model described below.
>>>>> Both Larry and I prefer this model instead of the current model. This
>>>>> preferred model has individual jars as opposed to creating large executable
>>>>> jars that contain all dependencies.
>>>>>
>>>>> So my question is how long should I wait to implement?
>>>>> I don't really expect much of an opinion from anyone other that Larry at
>>>>> this point BTW.
>>>>>
>>>>> Perhaps I'll do the work and submit a patch to the list for review and if
>>>>> nobody has input by say Monday morning apply the patch?
>>>>>
>>>>>
>>>>> On 3/21/13 3:26 PM, larry mccay wrote:
>>>>>>> The other option I can see is something like this where bin/ and lib/
>>>>>>> would
>>>>>>> change
>>>>>>>
>>>>>>> bin/
>>>>>>>       gateway.jar - Empty executable jar with manifest main class and
>>>>>>> class
>>>>>>> path referring to JARs in lib/
>>>>>>>       ldap.jar - Empty executable jar with manifest main class and class
>>>>>>> path
>>>>>>> referring to JARs in lib/
>>>>>>>       shell.jar - Empty executable jar with manifest main class and class
>>>>>>> path
>>>>>>> referring to JARs in lib/
>>>>>>> lib/
>>>>>>>       gateway-server-0.2.0-SNAPSHOT.jar
>>>>>>>       gateway-test-ldap-0.2.0-SNAPSHOT.jar
>>>>>>>       gateway-shell-0.2.0-SNAPSHOT.jar
>>>>>>>       commons-io-2.4.jar
>>>>>>>       groovy-1.5.6.jar
>>>>>>>       jetty-6.1.26.jar
>>>>>>>       shiro-core-1.2.1.jar
>>>>>>>       ... many more ...
>>>>>>>
>>>>>> I believe that this is my preference.
>>>>>> We may also want to add a gateway-common module that can be pulled out
>>>>>> as a separate jar so that shell doesn't need to depend on all of
>>>>>> server in order for them to share internal dependencies.
>>>>>>
>>>>>> Anyway - this approach gets my +1.
>>>>>>
>>>>>> On Thu, Mar 21, 2013 at 12:10 PM, Kevin Minder
>>>>>> <ke...@hortonworks.com> wrote:
>>>>>>> Hi Everyone,
>>>>>>>
>>>>>>> I want to raise an issue I been thinking about regarding the layout of
>>>>>>> the
>>>>>>> install.  In particular the layout of the JARs.  Currently the build is
>>>>>>> using the Maven Shade plugin to create a single executable JARs for
>>>>>>> things
>>>>>>> like the server (bin/server-0.2.0-SNAPSHOT.jar), client shell
>>>>>>> (bin/shell-0.2.0-SHAPSHOT.jar) and test LDAP server
>>>>>>> (bin/ldap-0.2.0.SNAPSHOT.jar)
>>>>>>>
>>>>>>> On one had I like this because it is neat and tidy.
>>>>>>>
>>>>>>> On the other hand wearing my potential RM has it raises some concerns.
>>>>>>>
>>>>>>> 1) It complicates the LICENSE and NOTICE file generation since it is
>>>>>>> difficult to see what the dependencies are other than from reports.
>>>>>>> 2) The server and the shell likely share some dependencies. Creating self
>>>>>>> contained JARs for each causes duplication and disk bloat.
>>>>>>> 3) Does this cause or solve a patch issue?  Is it easier for customer to
>>>>>>> be
>>>>>>> given a new server-0.2.1-SNAPSHOT.jar to use instead of potentially a set
>>>>>>> of
>>>>>>> patched JARs?
>>>>>>> 4) The Apache build env seems to be running Maven 2 and the shade plugin
>>>>>>> we
>>>>>>> are using required Maven 3.
>>>>>>>
>>>>>>> So this is what the "install" looks like now
>>>>>>>
>>>>>>> bin/
>>>>>>>       gateway-0.2.0-SNAPSHOT.jar
>>>>>>>       ldap-0.2.0-SNAPSHOT.jar
>>>>>>>       shell-0.2.0-SNAPSHOT.jar
>>>>>>> lib/ - Empty but reserved for future use
>>>>>>> ext/ - Empty but to be used by customers for custom extension
>>>>>>> samples/ - Distributed sample files
>>>>>>> templates/ - Distributed configuration templates
>>>>>>> deployments/ - Location for customer topology deployments
>>>>>>>
>>>>>>> The other option I can see is something like this where bin/ and lib/
>>>>>>> would
>>>>>>> change
>>>>>>>
>>>>>>> bin/
>>>>>>>       gateway.jar - Empty executable jar with manifest main class and
>>>>>>> class
>>>>>>> path referring to JARs in lib/
>>>>>>>       ldap.jar - Empty executable jar with manifest main class and class
>>>>>>> path
>>>>>>> referring to JARs in lib/
>>>>>>>       shell.jar - Empty executable jar with manifest main class and class
>>>>>>> path
>>>>>>> referring to JARs in lib/
>>>>>>> lib/
>>>>>>>       gateway-server-0.2.0-SNAPSHOT.jar
>>>>>>>       gateway-test-ldap-0.2.0-SNAPSHOT.jar
>>>>>>>       gateway-shell-0.2.0-SNAPSHOT.jar
>>>>>>>       commons-io-2.4.jar
>>>>>>>       groovy-1.5.6.jar
>>>>>>>       jetty-6.1.26.jar
>>>>>>>       shiro-core-1.2.1.jar
>>>>>>>       ... many more ...
>>>>>>>
>>>>>>> Kevin.

Re: [DISCUSS] Installation JAR layout

[Alan Gates <ga...@hortonworks.com>]

A question first before I try to answer your question:  Is Knox CTR or RTC?  CTR (commit then review) is committers are allowed to commit and other committers are expected to review within a few days if they have concerns.  RTC (review then commit) is a committer needs a +1 from another committer before committing (or in this case pushing) their code.  CTR lends itself better to projects that are more worried about speed and RTC works well in projects that want to be biased towards stability at the cost of speed.

If Knox is CTR, then no problem.  If it's RTC you technically should pull out the change and wait for a +1.  Given that Larry has effectively +1'd your change by saying "leave it", even if it's RTC I'd probably leave it at this point.

To answer the other question, coding changes like this don't generally need an explicit vote.  When you post the patch you're giving people a chance to vote up or down on the change on the JIRA.  And for code changes it's lazy consensus (that is, if someone doesn't vote then "silence implies consent").

Which leads me to another question.  Is there a JIRA for this change?  I am not sure how the projects using git are integrating with JIRA.  But having a JIRA ticket with code for the change posted on it is invaluable for allowing others to see what you're doing and give their feedback.

Alan.

On Mar 22, 2013, at 12:16 PM, Kevin Minder wrote:

> Uh Oh.
> I pushed by accident.  I know what you are all saying.  Sure it was an accident...  But it really was.
> What should I do now?  Try to figure how to revert it or only attempt that if people object?
> Kevin.
> 
> On 3/22/13 12:36 PM, Kevin Minder wrote:
>> Thanks. Just feeling this out and trying to figure out how to go fast without being ignoring the community.  I'll be interested in what the mentors have to say on the topic.
>> 
>> On 3/22/13 12:25 PM, larry mccay wrote:
>>> I say make it so.
>>> 
>>> Is this any different than a refactoring of the source, really?
>>> I think that votes are probably required for things that affect the
>>> community like a release which goes to the outside world.
>>> 
>>> A change that fundamentally changes the architecture in such a way
>>> that existing extensions from outside the project will be affected
>>> would be another thing that we would need a vote for.
>>> 
>>> A change in the charter and vision of the project would probably warrant a vote.
>>> 
>>> IMHO - this is more of an internal change that doesn't affect the
>>> community or any existing extensions and shouldn't be slowed down by a
>>> vote.
>>> 
>>> That said...
>>> 
>>> +1 to the proposed layout and I suggest that you just commit it once done.
>>> If you are unsure about it a review request would suffice.
>>> 
>>> On Fri, Mar 22, 2013 at 11:45 AM, Kevin Minder
>>> <ke...@hortonworks.com> wrote:
>>>> So how does this work?
>>>> 
>>>> I've spent the last 24 hours digging deep into Maven assemblies and finally
>>>> have a working standalone prototype that can be used to implement the second
>>>> model described below.
>>>> Both Larry and I prefer this model instead of the current model. This
>>>> preferred model has individual jars as opposed to creating large executable
>>>> jars that contain all dependencies.
>>>> 
>>>> So my question is how long should I wait to implement?
>>>> I don't really expect much of an opinion from anyone other that Larry at
>>>> this point BTW.
>>>> 
>>>> Perhaps I'll do the work and submit a patch to the list for review and if
>>>> nobody has input by say Monday morning apply the patch?
>>>> 
>>>> 
>>>> On 3/21/13 3:26 PM, larry mccay wrote:
>>>>>> The other option I can see is something like this where bin/ and lib/
>>>>>> would
>>>>>> change
>>>>>> 
>>>>>> bin/
>>>>>>      gateway.jar - Empty executable jar with manifest main class and
>>>>>> class
>>>>>> path referring to JARs in lib/
>>>>>>      ldap.jar - Empty executable jar with manifest main class and class
>>>>>> path
>>>>>> referring to JARs in lib/
>>>>>>      shell.jar - Empty executable jar with manifest main class and class
>>>>>> path
>>>>>> referring to JARs in lib/
>>>>>> lib/
>>>>>>      gateway-server-0.2.0-SNAPSHOT.jar
>>>>>>      gateway-test-ldap-0.2.0-SNAPSHOT.jar
>>>>>>      gateway-shell-0.2.0-SNAPSHOT.jar
>>>>>>      commons-io-2.4.jar
>>>>>>      groovy-1.5.6.jar
>>>>>>      jetty-6.1.26.jar
>>>>>>      shiro-core-1.2.1.jar
>>>>>>      ... many more ...
>>>>>> 
>>>>> I believe that this is my preference.
>>>>> We may also want to add a gateway-common module that can be pulled out
>>>>> as a separate jar so that shell doesn't need to depend on all of
>>>>> server in order for them to share internal dependencies.
>>>>> 
>>>>> Anyway - this approach gets my +1.
>>>>> 
>>>>> On Thu, Mar 21, 2013 at 12:10 PM, Kevin Minder
>>>>> <ke...@hortonworks.com> wrote:
>>>>>> Hi Everyone,
>>>>>> 
>>>>>> I want to raise an issue I been thinking about regarding the layout of
>>>>>> the
>>>>>> install.  In particular the layout of the JARs.  Currently the build is
>>>>>> using the Maven Shade plugin to create a single executable JARs for
>>>>>> things
>>>>>> like the server (bin/server-0.2.0-SNAPSHOT.jar), client shell
>>>>>> (bin/shell-0.2.0-SHAPSHOT.jar) and test LDAP server
>>>>>> (bin/ldap-0.2.0.SNAPSHOT.jar)
>>>>>> 
>>>>>> On one had I like this because it is neat and tidy.
>>>>>> 
>>>>>> On the other hand wearing my potential RM has it raises some concerns.
>>>>>> 
>>>>>> 1) It complicates the LICENSE and NOTICE file generation since it is
>>>>>> difficult to see what the dependencies are other than from reports.
>>>>>> 2) The server and the shell likely share some dependencies. Creating self
>>>>>> contained JARs for each causes duplication and disk bloat.
>>>>>> 3) Does this cause or solve a patch issue?  Is it easier for customer to
>>>>>> be
>>>>>> given a new server-0.2.1-SNAPSHOT.jar to use instead of potentially a set
>>>>>> of
>>>>>> patched JARs?
>>>>>> 4) The Apache build env seems to be running Maven 2 and the shade plugin
>>>>>> we
>>>>>> are using required Maven 3.
>>>>>> 
>>>>>> So this is what the "install" looks like now
>>>>>> 
>>>>>> bin/
>>>>>>      gateway-0.2.0-SNAPSHOT.jar
>>>>>>      ldap-0.2.0-SNAPSHOT.jar
>>>>>>      shell-0.2.0-SNAPSHOT.jar
>>>>>> lib/ - Empty but reserved for future use
>>>>>> ext/ - Empty but to be used by customers for custom extension
>>>>>> samples/ - Distributed sample files
>>>>>> templates/ - Distributed configuration templates
>>>>>> deployments/ - Location for customer topology deployments
>>>>>> 
>>>>>> The other option I can see is something like this where bin/ and lib/
>>>>>> would
>>>>>> change
>>>>>> 
>>>>>> bin/
>>>>>>      gateway.jar - Empty executable jar with manifest main class and
>>>>>> class
>>>>>> path referring to JARs in lib/
>>>>>>      ldap.jar - Empty executable jar with manifest main class and class
>>>>>> path
>>>>>> referring to JARs in lib/
>>>>>>      shell.jar - Empty executable jar with manifest main class and class
>>>>>> path
>>>>>> referring to JARs in lib/
>>>>>> lib/
>>>>>>      gateway-server-0.2.0-SNAPSHOT.jar
>>>>>>      gateway-test-ldap-0.2.0-SNAPSHOT.jar
>>>>>>      gateway-shell-0.2.0-SNAPSHOT.jar
>>>>>>      commons-io-2.4.jar
>>>>>>      groovy-1.5.6.jar
>>>>>>      jetty-6.1.26.jar
>>>>>>      shiro-core-1.2.1.jar
>>>>>>      ... many more ...
>>>>>> 
>>>>>> Kevin.
>>>> 
>> 
> 

Re: [DISCUSS] Installation JAR layout

["Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>]

You're fine I think -- no need to revert.

Cheers,
Chris


On 3/22/13 12:16 PM, "Kevin Minder" <ke...@hortonworks.com> wrote:

>Uh Oh.
>I pushed by accident.  I know what you are all saying.  Sure it was an
>accident...  But it really was.
>What should I do now?  Try to figure how to revert it or only attempt
>that if people object?
>Kevin.
>
>On 3/22/13 12:36 PM, Kevin Minder wrote:
>> Thanks. Just feeling this out and trying to figure out how to go fast
>> without being ignoring the community.  I'll be interested in what the
>> mentors have to say on the topic.
>>
>> On 3/22/13 12:25 PM, larry mccay wrote:
>>> I say make it so.
>>>
>>> Is this any different than a refactoring of the source, really?
>>> I think that votes are probably required for things that affect the
>>> community like a release which goes to the outside world.
>>>
>>> A change that fundamentally changes the architecture in such a way
>>> that existing extensions from outside the project will be affected
>>> would be another thing that we would need a vote for.
>>>
>>> A change in the charter and vision of the project would probably
>>> warrant a vote.
>>>
>>> IMHO - this is more of an internal change that doesn't affect the
>>> community or any existing extensions and shouldn't be slowed down by a
>>> vote.
>>>
>>> That said...
>>>
>>> +1 to the proposed layout and I suggest that you just commit it once
>>> done.
>>> If you are unsure about it a review request would suffice.
>>>
>>> On Fri, Mar 22, 2013 at 11:45 AM, Kevin Minder
>>> <ke...@hortonworks.com> wrote:
>>>> So how does this work?
>>>>
>>>> I've spent the last 24 hours digging deep into Maven assemblies and
>>>> finally
>>>> have a working standalone prototype that can be used to implement
>>>> the second
>>>> model described below.
>>>> Both Larry and I prefer this model instead of the current model. This
>>>> preferred model has individual jars as opposed to creating large
>>>> executable
>>>> jars that contain all dependencies.
>>>>
>>>> So my question is how long should I wait to implement?
>>>> I don't really expect much of an opinion from anyone other that
>>>> Larry at
>>>> this point BTW.
>>>>
>>>> Perhaps I'll do the work and submit a patch to the list for review
>>>> and if
>>>> nobody has input by say Monday morning apply the patch?
>>>>
>>>>
>>>> On 3/21/13 3:26 PM, larry mccay wrote:
>>>>>> The other option I can see is something like this where bin/ and
>>>>>>lib/
>>>>>> would
>>>>>> change
>>>>>>
>>>>>> bin/
>>>>>>       gateway.jar - Empty executable jar with manifest main class
>>>>>>and
>>>>>> class
>>>>>> path referring to JARs in lib/
>>>>>>       ldap.jar - Empty executable jar with manifest main class and
>>>>>> class
>>>>>> path
>>>>>> referring to JARs in lib/
>>>>>>       shell.jar - Empty executable jar with manifest main class
>>>>>> and class
>>>>>> path
>>>>>> referring to JARs in lib/
>>>>>> lib/
>>>>>>       gateway-server-0.2.0-SNAPSHOT.jar
>>>>>>       gateway-test-ldap-0.2.0-SNAPSHOT.jar
>>>>>>       gateway-shell-0.2.0-SNAPSHOT.jar
>>>>>>       commons-io-2.4.jar
>>>>>>       groovy-1.5.6.jar
>>>>>>       jetty-6.1.26.jar
>>>>>>       shiro-core-1.2.1.jar
>>>>>>       ... many more ...
>>>>>>
>>>>> I believe that this is my preference.
>>>>> We may also want to add a gateway-common module that can be pulled
>>>>>out
>>>>> as a separate jar so that shell doesn't need to depend on all of
>>>>> server in order for them to share internal dependencies.
>>>>>
>>>>> Anyway - this approach gets my +1.
>>>>>
>>>>> On Thu, Mar 21, 2013 at 12:10 PM, Kevin Minder
>>>>> <ke...@hortonworks.com> wrote:
>>>>>> Hi Everyone,
>>>>>>
>>>>>> I want to raise an issue I been thinking about regarding the
>>>>>> layout of
>>>>>> the
>>>>>> install.  In particular the layout of the JARs.  Currently the
>>>>>> build is
>>>>>> using the Maven Shade plugin to create a single executable JARs for
>>>>>> things
>>>>>> like the server (bin/server-0.2.0-SNAPSHOT.jar), client shell
>>>>>> (bin/shell-0.2.0-SHAPSHOT.jar) and test LDAP server
>>>>>> (bin/ldap-0.2.0.SNAPSHOT.jar)
>>>>>>
>>>>>> On one had I like this because it is neat and tidy.
>>>>>>
>>>>>> On the other hand wearing my potential RM has it raises some
>>>>>> concerns.
>>>>>>
>>>>>> 1) It complicates the LICENSE and NOTICE file generation since it is
>>>>>> difficult to see what the dependencies are other than from reports.
>>>>>> 2) The server and the shell likely share some dependencies.
>>>>>> Creating self
>>>>>> contained JARs for each causes duplication and disk bloat.
>>>>>> 3) Does this cause or solve a patch issue?  Is it easier for
>>>>>> customer to
>>>>>> be
>>>>>> given a new server-0.2.1-SNAPSHOT.jar to use instead of
>>>>>> potentially a set
>>>>>> of
>>>>>> patched JARs?
>>>>>> 4) The Apache build env seems to be running Maven 2 and the shade
>>>>>> plugin
>>>>>> we
>>>>>> are using required Maven 3.
>>>>>>
>>>>>> So this is what the "install" looks like now
>>>>>>
>>>>>> bin/
>>>>>>       gateway-0.2.0-SNAPSHOT.jar
>>>>>>       ldap-0.2.0-SNAPSHOT.jar
>>>>>>       shell-0.2.0-SNAPSHOT.jar
>>>>>> lib/ - Empty but reserved for future use
>>>>>> ext/ - Empty but to be used by customers for custom extension
>>>>>> samples/ - Distributed sample files
>>>>>> templates/ - Distributed configuration templates
>>>>>> deployments/ - Location for customer topology deployments
>>>>>>
>>>>>> The other option I can see is something like this where bin/ and
>>>>>>lib/
>>>>>> would
>>>>>> change
>>>>>>
>>>>>> bin/
>>>>>>       gateway.jar - Empty executable jar with manifest main class
>>>>>>and
>>>>>> class
>>>>>> path referring to JARs in lib/
>>>>>>       ldap.jar - Empty executable jar with manifest main class and
>>>>>> class
>>>>>> path
>>>>>> referring to JARs in lib/
>>>>>>       shell.jar - Empty executable jar with manifest main class
>>>>>> and class
>>>>>> path
>>>>>> referring to JARs in lib/
>>>>>> lib/
>>>>>>       gateway-server-0.2.0-SNAPSHOT.jar
>>>>>>       gateway-test-ldap-0.2.0-SNAPSHOT.jar
>>>>>>       gateway-shell-0.2.0-SNAPSHOT.jar
>>>>>>       commons-io-2.4.jar
>>>>>>       groovy-1.5.6.jar
>>>>>>       jetty-6.1.26.jar
>>>>>>       shiro-core-1.2.1.jar
>>>>>>       ... many more ...
>>>>>>
>>>>>> Kevin.
>>>>
>>
>

Re: [DISCUSS] Installation JAR layout

[Kevin Minder <ke...@hortonworks.com>]

Uh Oh.
I pushed by accident.  I know what you are all saying.  Sure it was an 
accident...  But it really was.
What should I do now?  Try to figure how to revert it or only attempt 
that if people object?
Kevin.

On 3/22/13 12:36 PM, Kevin Minder wrote:
> Thanks. Just feeling this out and trying to figure out how to go fast 
> without being ignoring the community.  I'll be interested in what the 
> mentors have to say on the topic.
>
> On 3/22/13 12:25 PM, larry mccay wrote:
>> I say make it so.
>>
>> Is this any different than a refactoring of the source, really?
>> I think that votes are probably required for things that affect the
>> community like a release which goes to the outside world.
>>
>> A change that fundamentally changes the architecture in such a way
>> that existing extensions from outside the project will be affected
>> would be another thing that we would need a vote for.
>>
>> A change in the charter and vision of the project would probably 
>> warrant a vote.
>>
>> IMHO - this is more of an internal change that doesn't affect the
>> community or any existing extensions and shouldn't be slowed down by a
>> vote.
>>
>> That said...
>>
>> +1 to the proposed layout and I suggest that you just commit it once 
>> done.
>> If you are unsure about it a review request would suffice.
>>
>> On Fri, Mar 22, 2013 at 11:45 AM, Kevin Minder
>> <ke...@hortonworks.com> wrote:
>>> So how does this work?
>>>
>>> I've spent the last 24 hours digging deep into Maven assemblies and 
>>> finally
>>> have a working standalone prototype that can be used to implement 
>>> the second
>>> model described below.
>>> Both Larry and I prefer this model instead of the current model. This
>>> preferred model has individual jars as opposed to creating large 
>>> executable
>>> jars that contain all dependencies.
>>>
>>> So my question is how long should I wait to implement?
>>> I don't really expect much of an opinion from anyone other that 
>>> Larry at
>>> this point BTW.
>>>
>>> Perhaps I'll do the work and submit a patch to the list for review 
>>> and if
>>> nobody has input by say Monday morning apply the patch?
>>>
>>>
>>> On 3/21/13 3:26 PM, larry mccay wrote:
>>>>> The other option I can see is something like this where bin/ and lib/
>>>>> would
>>>>> change
>>>>>
>>>>> bin/
>>>>>       gateway.jar - Empty executable jar with manifest main class and
>>>>> class
>>>>> path referring to JARs in lib/
>>>>>       ldap.jar - Empty executable jar with manifest main class and 
>>>>> class
>>>>> path
>>>>> referring to JARs in lib/
>>>>>       shell.jar - Empty executable jar with manifest main class 
>>>>> and class
>>>>> path
>>>>> referring to JARs in lib/
>>>>> lib/
>>>>>       gateway-server-0.2.0-SNAPSHOT.jar
>>>>>       gateway-test-ldap-0.2.0-SNAPSHOT.jar
>>>>>       gateway-shell-0.2.0-SNAPSHOT.jar
>>>>>       commons-io-2.4.jar
>>>>>       groovy-1.5.6.jar
>>>>>       jetty-6.1.26.jar
>>>>>       shiro-core-1.2.1.jar
>>>>>       ... many more ...
>>>>>
>>>> I believe that this is my preference.
>>>> We may also want to add a gateway-common module that can be pulled out
>>>> as a separate jar so that shell doesn't need to depend on all of
>>>> server in order for them to share internal dependencies.
>>>>
>>>> Anyway - this approach gets my +1.
>>>>
>>>> On Thu, Mar 21, 2013 at 12:10 PM, Kevin Minder
>>>> <ke...@hortonworks.com> wrote:
>>>>> Hi Everyone,
>>>>>
>>>>> I want to raise an issue I been thinking about regarding the 
>>>>> layout of
>>>>> the
>>>>> install.  In particular the layout of the JARs.  Currently the 
>>>>> build is
>>>>> using the Maven Shade plugin to create a single executable JARs for
>>>>> things
>>>>> like the server (bin/server-0.2.0-SNAPSHOT.jar), client shell
>>>>> (bin/shell-0.2.0-SHAPSHOT.jar) and test LDAP server
>>>>> (bin/ldap-0.2.0.SNAPSHOT.jar)
>>>>>
>>>>> On one had I like this because it is neat and tidy.
>>>>>
>>>>> On the other hand wearing my potential RM has it raises some 
>>>>> concerns.
>>>>>
>>>>> 1) It complicates the LICENSE and NOTICE file generation since it is
>>>>> difficult to see what the dependencies are other than from reports.
>>>>> 2) The server and the shell likely share some dependencies. 
>>>>> Creating self
>>>>> contained JARs for each causes duplication and disk bloat.
>>>>> 3) Does this cause or solve a patch issue?  Is it easier for 
>>>>> customer to
>>>>> be
>>>>> given a new server-0.2.1-SNAPSHOT.jar to use instead of 
>>>>> potentially a set
>>>>> of
>>>>> patched JARs?
>>>>> 4) The Apache build env seems to be running Maven 2 and the shade 
>>>>> plugin
>>>>> we
>>>>> are using required Maven 3.
>>>>>
>>>>> So this is what the "install" looks like now
>>>>>
>>>>> bin/
>>>>>       gateway-0.2.0-SNAPSHOT.jar
>>>>>       ldap-0.2.0-SNAPSHOT.jar
>>>>>       shell-0.2.0-SNAPSHOT.jar
>>>>> lib/ - Empty but reserved for future use
>>>>> ext/ - Empty but to be used by customers for custom extension
>>>>> samples/ - Distributed sample files
>>>>> templates/ - Distributed configuration templates
>>>>> deployments/ - Location for customer topology deployments
>>>>>
>>>>> The other option I can see is something like this where bin/ and lib/
>>>>> would
>>>>> change
>>>>>
>>>>> bin/
>>>>>       gateway.jar - Empty executable jar with manifest main class and
>>>>> class
>>>>> path referring to JARs in lib/
>>>>>       ldap.jar - Empty executable jar with manifest main class and 
>>>>> class
>>>>> path
>>>>> referring to JARs in lib/
>>>>>       shell.jar - Empty executable jar with manifest main class 
>>>>> and class
>>>>> path
>>>>> referring to JARs in lib/
>>>>> lib/
>>>>>       gateway-server-0.2.0-SNAPSHOT.jar
>>>>>       gateway-test-ldap-0.2.0-SNAPSHOT.jar
>>>>>       gateway-shell-0.2.0-SNAPSHOT.jar
>>>>>       commons-io-2.4.jar
>>>>>       groovy-1.5.6.jar
>>>>>       jetty-6.1.26.jar
>>>>>       shiro-core-1.2.1.jar
>>>>>       ... many more ...
>>>>>
>>>>> Kevin.
>>>
>

Re: [DISCUSS] Installation JAR layout

["Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>]

Yep no need for a VOTE, and thanks for checking in! :)

Cheers,
Chris


On 3/22/13 9:36 AM, "Kevin Minder" <ke...@hortonworks.com> wrote:

>Thanks.  Just feeling this out and trying to figure out how to go fast
>without being ignoring the community.  I'll be interested in what the
>mentors have to say on the topic.
>
>On 3/22/13 12:25 PM, larry mccay wrote:
>> I say make it so.
>>
>> Is this any different than a refactoring of the source, really?
>> I think that votes are probably required for things that affect the
>> community like a release which goes to the outside world.
>>
>> A change that fundamentally changes the architecture in such a way
>> that existing extensions from outside the project will be affected
>> would be another thing that we would need a vote for.
>>
>> A change in the charter and vision of the project would probably
>>warrant a vote.
>>
>> IMHO - this is more of an internal change that doesn't affect the
>> community or any existing extensions and shouldn't be slowed down by a
>> vote.
>>
>> That said...
>>
>> +1 to the proposed layout and I suggest that you just commit it once
>>done.
>> If you are unsure about it a review request would suffice.
>>
>> On Fri, Mar 22, 2013 at 11:45 AM, Kevin Minder
>> <ke...@hortonworks.com> wrote:
>>> So how does this work?
>>>
>>> I've spent the last 24 hours digging deep into Maven assemblies and
>>>finally
>>> have a working standalone prototype that can be used to implement the
>>>second
>>> model described below.
>>> Both Larry and I prefer this model instead of the current model. This
>>> preferred model has individual jars as opposed to creating large
>>>executable
>>> jars that contain all dependencies.
>>>
>>> So my question is how long should I wait to implement?
>>> I don't really expect much of an opinion from anyone other that Larry
>>>at
>>> this point BTW.
>>>
>>> Perhaps I'll do the work and submit a patch to the list for review and
>>>if
>>> nobody has input by say Monday morning apply the patch?
>>>
>>>
>>> On 3/21/13 3:26 PM, larry mccay wrote:
>>>>> The other option I can see is something like this where bin/ and lib/
>>>>> would
>>>>> change
>>>>>
>>>>> bin/
>>>>>       gateway.jar - Empty executable jar with manifest main class and
>>>>> class
>>>>> path referring to JARs in lib/
>>>>>       ldap.jar - Empty executable jar with manifest main class and
>>>>>class
>>>>> path
>>>>> referring to JARs in lib/
>>>>>       shell.jar - Empty executable jar with manifest main class and
>>>>>class
>>>>> path
>>>>> referring to JARs in lib/
>>>>> lib/
>>>>>       gateway-server-0.2.0-SNAPSHOT.jar
>>>>>       gateway-test-ldap-0.2.0-SNAPSHOT.jar
>>>>>       gateway-shell-0.2.0-SNAPSHOT.jar
>>>>>       commons-io-2.4.jar
>>>>>       groovy-1.5.6.jar
>>>>>       jetty-6.1.26.jar
>>>>>       shiro-core-1.2.1.jar
>>>>>       ... many more ...
>>>>>
>>>> I believe that this is my preference.
>>>> We may also want to add a gateway-common module that can be pulled out
>>>> as a separate jar so that shell doesn't need to depend on all of
>>>> server in order for them to share internal dependencies.
>>>>
>>>> Anyway - this approach gets my +1.
>>>>
>>>> On Thu, Mar 21, 2013 at 12:10 PM, Kevin Minder
>>>> <ke...@hortonworks.com> wrote:
>>>>> Hi Everyone,
>>>>>
>>>>> I want to raise an issue I been thinking about regarding the layout
>>>>>of
>>>>> the
>>>>> install.  In particular the layout of the JARs.  Currently the build
>>>>>is
>>>>> using the Maven Shade plugin to create a single executable JARs for
>>>>> things
>>>>> like the server (bin/server-0.2.0-SNAPSHOT.jar), client shell
>>>>> (bin/shell-0.2.0-SHAPSHOT.jar) and test LDAP server
>>>>> (bin/ldap-0.2.0.SNAPSHOT.jar)
>>>>>
>>>>> On one had I like this because it is neat and tidy.
>>>>>
>>>>> On the other hand wearing my potential RM has it raises some
>>>>>concerns.
>>>>>
>>>>> 1) It complicates the LICENSE and NOTICE file generation since it is
>>>>> difficult to see what the dependencies are other than from reports.
>>>>> 2) The server and the shell likely share some dependencies. Creating
>>>>>self
>>>>> contained JARs for each causes duplication and disk bloat.
>>>>> 3) Does this cause or solve a patch issue?  Is it easier for
>>>>>customer to
>>>>> be
>>>>> given a new server-0.2.1-SNAPSHOT.jar to use instead of potentially
>>>>>a set
>>>>> of
>>>>> patched JARs?
>>>>> 4) The Apache build env seems to be running Maven 2 and the shade
>>>>>plugin
>>>>> we
>>>>> are using required Maven 3.
>>>>>
>>>>> So this is what the "install" looks like now
>>>>>
>>>>> bin/
>>>>>       gateway-0.2.0-SNAPSHOT.jar
>>>>>       ldap-0.2.0-SNAPSHOT.jar
>>>>>       shell-0.2.0-SNAPSHOT.jar
>>>>> lib/ - Empty but reserved for future use
>>>>> ext/ - Empty but to be used by customers for custom extension
>>>>> samples/ - Distributed sample files
>>>>> templates/ - Distributed configuration templates
>>>>> deployments/ - Location for customer topology deployments
>>>>>
>>>>> The other option I can see is something like this where bin/ and lib/
>>>>> would
>>>>> change
>>>>>
>>>>> bin/
>>>>>       gateway.jar - Empty executable jar with manifest main class and
>>>>> class
>>>>> path referring to JARs in lib/
>>>>>       ldap.jar - Empty executable jar with manifest main class and
>>>>>class
>>>>> path
>>>>> referring to JARs in lib/
>>>>>       shell.jar - Empty executable jar with manifest main class and
>>>>>class
>>>>> path
>>>>> referring to JARs in lib/
>>>>> lib/
>>>>>       gateway-server-0.2.0-SNAPSHOT.jar
>>>>>       gateway-test-ldap-0.2.0-SNAPSHOT.jar
>>>>>       gateway-shell-0.2.0-SNAPSHOT.jar
>>>>>       commons-io-2.4.jar
>>>>>       groovy-1.5.6.jar
>>>>>       jetty-6.1.26.jar
>>>>>       shiro-core-1.2.1.jar
>>>>>       ... many more ...
>>>>>
>>>>> Kevin.
>>>
>

Re: [DISCUSS] Installation JAR layout

[Kevin Minder <ke...@hortonworks.com>]

Thanks.  Just feeling this out and trying to figure out how to go fast 
without being ignoring the community.  I'll be interested in what the 
mentors have to say on the topic.

On 3/22/13 12:25 PM, larry mccay wrote:
> I say make it so.
>
> Is this any different than a refactoring of the source, really?
> I think that votes are probably required for things that affect the
> community like a release which goes to the outside world.
>
> A change that fundamentally changes the architecture in such a way
> that existing extensions from outside the project will be affected
> would be another thing that we would need a vote for.
>
> A change in the charter and vision of the project would probably warrant a vote.
>
> IMHO - this is more of an internal change that doesn't affect the
> community or any existing extensions and shouldn't be slowed down by a
> vote.
>
> That said...
>
> +1 to the proposed layout and I suggest that you just commit it once done.
> If you are unsure about it a review request would suffice.
>
> On Fri, Mar 22, 2013 at 11:45 AM, Kevin Minder
> <ke...@hortonworks.com> wrote:
>> So how does this work?
>>
>> I've spent the last 24 hours digging deep into Maven assemblies and finally
>> have a working standalone prototype that can be used to implement the second
>> model described below.
>> Both Larry and I prefer this model instead of the current model. This
>> preferred model has individual jars as opposed to creating large executable
>> jars that contain all dependencies.
>>
>> So my question is how long should I wait to implement?
>> I don't really expect much of an opinion from anyone other that Larry at
>> this point BTW.
>>
>> Perhaps I'll do the work and submit a patch to the list for review and if
>> nobody has input by say Monday morning apply the patch?
>>
>>
>> On 3/21/13 3:26 PM, larry mccay wrote:
>>>> The other option I can see is something like this where bin/ and lib/
>>>> would
>>>> change
>>>>
>>>> bin/
>>>>       gateway.jar - Empty executable jar with manifest main class and
>>>> class
>>>> path referring to JARs in lib/
>>>>       ldap.jar - Empty executable jar with manifest main class and class
>>>> path
>>>> referring to JARs in lib/
>>>>       shell.jar - Empty executable jar with manifest main class and class
>>>> path
>>>> referring to JARs in lib/
>>>> lib/
>>>>       gateway-server-0.2.0-SNAPSHOT.jar
>>>>       gateway-test-ldap-0.2.0-SNAPSHOT.jar
>>>>       gateway-shell-0.2.0-SNAPSHOT.jar
>>>>       commons-io-2.4.jar
>>>>       groovy-1.5.6.jar
>>>>       jetty-6.1.26.jar
>>>>       shiro-core-1.2.1.jar
>>>>       ... many more ...
>>>>
>>> I believe that this is my preference.
>>> We may also want to add a gateway-common module that can be pulled out
>>> as a separate jar so that shell doesn't need to depend on all of
>>> server in order for them to share internal dependencies.
>>>
>>> Anyway - this approach gets my +1.
>>>
>>> On Thu, Mar 21, 2013 at 12:10 PM, Kevin Minder
>>> <ke...@hortonworks.com> wrote:
>>>> Hi Everyone,
>>>>
>>>> I want to raise an issue I been thinking about regarding the layout of
>>>> the
>>>> install.  In particular the layout of the JARs.  Currently the build is
>>>> using the Maven Shade plugin to create a single executable JARs for
>>>> things
>>>> like the server (bin/server-0.2.0-SNAPSHOT.jar), client shell
>>>> (bin/shell-0.2.0-SHAPSHOT.jar) and test LDAP server
>>>> (bin/ldap-0.2.0.SNAPSHOT.jar)
>>>>
>>>> On one had I like this because it is neat and tidy.
>>>>
>>>> On the other hand wearing my potential RM has it raises some concerns.
>>>>
>>>> 1) It complicates the LICENSE and NOTICE file generation since it is
>>>> difficult to see what the dependencies are other than from reports.
>>>> 2) The server and the shell likely share some dependencies. Creating self
>>>> contained JARs for each causes duplication and disk bloat.
>>>> 3) Does this cause or solve a patch issue?  Is it easier for customer to
>>>> be
>>>> given a new server-0.2.1-SNAPSHOT.jar to use instead of potentially a set
>>>> of
>>>> patched JARs?
>>>> 4) The Apache build env seems to be running Maven 2 and the shade plugin
>>>> we
>>>> are using required Maven 3.
>>>>
>>>> So this is what the "install" looks like now
>>>>
>>>> bin/
>>>>       gateway-0.2.0-SNAPSHOT.jar
>>>>       ldap-0.2.0-SNAPSHOT.jar
>>>>       shell-0.2.0-SNAPSHOT.jar
>>>> lib/ - Empty but reserved for future use
>>>> ext/ - Empty but to be used by customers for custom extension
>>>> samples/ - Distributed sample files
>>>> templates/ - Distributed configuration templates
>>>> deployments/ - Location for customer topology deployments
>>>>
>>>> The other option I can see is something like this where bin/ and lib/
>>>> would
>>>> change
>>>>
>>>> bin/
>>>>       gateway.jar - Empty executable jar with manifest main class and
>>>> class
>>>> path referring to JARs in lib/
>>>>       ldap.jar - Empty executable jar with manifest main class and class
>>>> path
>>>> referring to JARs in lib/
>>>>       shell.jar - Empty executable jar with manifest main class and class
>>>> path
>>>> referring to JARs in lib/
>>>> lib/
>>>>       gateway-server-0.2.0-SNAPSHOT.jar
>>>>       gateway-test-ldap-0.2.0-SNAPSHOT.jar
>>>>       gateway-shell-0.2.0-SNAPSHOT.jar
>>>>       commons-io-2.4.jar
>>>>       groovy-1.5.6.jar
>>>>       jetty-6.1.26.jar
>>>>       shiro-core-1.2.1.jar
>>>>       ... many more ...
>>>>
>>>> Kevin.
>>

Re: [DISCUSS] Installation JAR layout

[larry mccay <la...@gmail.com>]

I say make it so.

Is this any different than a refactoring of the source, really?
I think that votes are probably required for things that affect the
community like a release which goes to the outside world.

A change that fundamentally changes the architecture in such a way
that existing extensions from outside the project will be affected
would be another thing that we would need a vote for.

A change in the charter and vision of the project would probably warrant a vote.

IMHO - this is more of an internal change that doesn't affect the
community or any existing extensions and shouldn't be slowed down by a
vote.

That said...

+1 to the proposed layout and I suggest that you just commit it once done.
If you are unsure about it a review request would suffice.

On Fri, Mar 22, 2013 at 11:45 AM, Kevin Minder
<ke...@hortonworks.com> wrote:
> So how does this work?
>
> I've spent the last 24 hours digging deep into Maven assemblies and finally
> have a working standalone prototype that can be used to implement the second
> model described below.
> Both Larry and I prefer this model instead of the current model. This
> preferred model has individual jars as opposed to creating large executable
> jars that contain all dependencies.
>
> So my question is how long should I wait to implement?
> I don't really expect much of an opinion from anyone other that Larry at
> this point BTW.
>
> Perhaps I'll do the work and submit a patch to the list for review and if
> nobody has input by say Monday morning apply the patch?
>
>
> On 3/21/13 3:26 PM, larry mccay wrote:
>>>
>>> The other option I can see is something like this where bin/ and lib/
>>> would
>>> change
>>>
>>> bin/
>>>      gateway.jar - Empty executable jar with manifest main class and
>>> class
>>> path referring to JARs in lib/
>>>      ldap.jar - Empty executable jar with manifest main class and class
>>> path
>>> referring to JARs in lib/
>>>      shell.jar - Empty executable jar with manifest main class and class
>>> path
>>> referring to JARs in lib/
>>> lib/
>>>      gateway-server-0.2.0-SNAPSHOT.jar
>>>      gateway-test-ldap-0.2.0-SNAPSHOT.jar
>>>      gateway-shell-0.2.0-SNAPSHOT.jar
>>>      commons-io-2.4.jar
>>>      groovy-1.5.6.jar
>>>      jetty-6.1.26.jar
>>>      shiro-core-1.2.1.jar
>>>      ... many more ...
>>>
>> I believe that this is my preference.
>> We may also want to add a gateway-common module that can be pulled out
>> as a separate jar so that shell doesn't need to depend on all of
>> server in order for them to share internal dependencies.
>>
>> Anyway - this approach gets my +1.
>>
>> On Thu, Mar 21, 2013 at 12:10 PM, Kevin Minder
>> <ke...@hortonworks.com> wrote:
>>>
>>> Hi Everyone,
>>>
>>> I want to raise an issue I been thinking about regarding the layout of
>>> the
>>> install.  In particular the layout of the JARs.  Currently the build is
>>> using the Maven Shade plugin to create a single executable JARs for
>>> things
>>> like the server (bin/server-0.2.0-SNAPSHOT.jar), client shell
>>> (bin/shell-0.2.0-SHAPSHOT.jar) and test LDAP server
>>> (bin/ldap-0.2.0.SNAPSHOT.jar)
>>>
>>> On one had I like this because it is neat and tidy.
>>>
>>> On the other hand wearing my potential RM has it raises some concerns.
>>>
>>> 1) It complicates the LICENSE and NOTICE file generation since it is
>>> difficult to see what the dependencies are other than from reports.
>>> 2) The server and the shell likely share some dependencies. Creating self
>>> contained JARs for each causes duplication and disk bloat.
>>> 3) Does this cause or solve a patch issue?  Is it easier for customer to
>>> be
>>> given a new server-0.2.1-SNAPSHOT.jar to use instead of potentially a set
>>> of
>>> patched JARs?
>>> 4) The Apache build env seems to be running Maven 2 and the shade plugin
>>> we
>>> are using required Maven 3.
>>>
>>> So this is what the "install" looks like now
>>>
>>> bin/
>>>      gateway-0.2.0-SNAPSHOT.jar
>>>      ldap-0.2.0-SNAPSHOT.jar
>>>      shell-0.2.0-SNAPSHOT.jar
>>> lib/ - Empty but reserved for future use
>>> ext/ - Empty but to be used by customers for custom extension
>>> samples/ - Distributed sample files
>>> templates/ - Distributed configuration templates
>>> deployments/ - Location for customer topology deployments
>>>
>>> The other option I can see is something like this where bin/ and lib/
>>> would
>>> change
>>>
>>> bin/
>>>      gateway.jar - Empty executable jar with manifest main class and
>>> class
>>> path referring to JARs in lib/
>>>      ldap.jar - Empty executable jar with manifest main class and class
>>> path
>>> referring to JARs in lib/
>>>      shell.jar - Empty executable jar with manifest main class and class
>>> path
>>> referring to JARs in lib/
>>> lib/
>>>      gateway-server-0.2.0-SNAPSHOT.jar
>>>      gateway-test-ldap-0.2.0-SNAPSHOT.jar
>>>      gateway-shell-0.2.0-SNAPSHOT.jar
>>>      commons-io-2.4.jar
>>>      groovy-1.5.6.jar
>>>      jetty-6.1.26.jar
>>>      shiro-core-1.2.1.jar
>>>      ... many more ...
>>>
>>> Kevin.
>
>

Re: [DISCUSS] Installation JAR layout

["Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>]

Hey Kevin,

How about creating a JIRA issue, and then attaching your patch there,
and/or 
simply committing the patch? I'm fine with Commit then Review, so long as
you guys who are doing the work are :)

Cheers,
Chris


On 3/22/13 8:45 AM, "Kevin Minder" <ke...@hortonworks.com> wrote:

>So how does this work?
>
>I've spent the last 24 hours digging deep into Maven assemblies and
>finally have a working standalone prototype that can be used to
>implement the second model described below.
>Both Larry and I prefer this model instead of the current model. This
>preferred model has individual jars as opposed to creating large
>executable jars that contain all dependencies.
>
>So my question is how long should I wait to implement?
>I don't really expect much of an opinion from anyone other that Larry at
>this point BTW.
>
>Perhaps I'll do the work and submit a patch to the list for review and
>if nobody has input by say Monday morning apply the patch?
>
>On 3/21/13 3:26 PM, larry mccay wrote:
>>> The other option I can see is something like this where bin/ and lib/
>>>would
>>> change
>>>
>>> bin/
>>>      gateway.jar - Empty executable jar with manifest main class and
>>>class
>>> path referring to JARs in lib/
>>>      ldap.jar - Empty executable jar with manifest main class and
>>>class path
>>> referring to JARs in lib/
>>>      shell.jar - Empty executable jar with manifest main class and
>>>class path
>>> referring to JARs in lib/
>>> lib/
>>>      gateway-server-0.2.0-SNAPSHOT.jar
>>>      gateway-test-ldap-0.2.0-SNAPSHOT.jar
>>>      gateway-shell-0.2.0-SNAPSHOT.jar
>>>      commons-io-2.4.jar
>>>      groovy-1.5.6.jar
>>>      jetty-6.1.26.jar
>>>      shiro-core-1.2.1.jar
>>>      ... many more ...
>>>
>> I believe that this is my preference.
>> We may also want to add a gateway-common module that can be pulled out
>> as a separate jar so that shell doesn't need to depend on all of
>> server in order for them to share internal dependencies.
>>
>> Anyway - this approach gets my +1.
>>
>> On Thu, Mar 21, 2013 at 12:10 PM, Kevin Minder
>> <ke...@hortonworks.com> wrote:
>>> Hi Everyone,
>>>
>>> I want to raise an issue I been thinking about regarding the layout of
>>>the
>>> install.  In particular the layout of the JARs.  Currently the build is
>>> using the Maven Shade plugin to create a single executable JARs for
>>>things
>>> like the server (bin/server-0.2.0-SNAPSHOT.jar), client shell
>>> (bin/shell-0.2.0-SHAPSHOT.jar) and test LDAP server
>>> (bin/ldap-0.2.0.SNAPSHOT.jar)
>>>
>>> On one had I like this because it is neat and tidy.
>>>
>>> On the other hand wearing my potential RM has it raises some concerns.
>>>
>>> 1) It complicates the LICENSE and NOTICE file generation since it is
>>> difficult to see what the dependencies are other than from reports.
>>> 2) The server and the shell likely share some dependencies. Creating
>>>self
>>> contained JARs for each causes duplication and disk bloat.
>>> 3) Does this cause or solve a patch issue?  Is it easier for customer
>>>to be
>>> given a new server-0.2.1-SNAPSHOT.jar to use instead of potentially a
>>>set of
>>> patched JARs?
>>> 4) The Apache build env seems to be running Maven 2 and the shade
>>>plugin we
>>> are using required Maven 3.
>>>
>>> So this is what the "install" looks like now
>>>
>>> bin/
>>>      gateway-0.2.0-SNAPSHOT.jar
>>>      ldap-0.2.0-SNAPSHOT.jar
>>>      shell-0.2.0-SNAPSHOT.jar
>>> lib/ - Empty but reserved for future use
>>> ext/ - Empty but to be used by customers for custom extension
>>> samples/ - Distributed sample files
>>> templates/ - Distributed configuration templates
>>> deployments/ - Location for customer topology deployments
>>>
>>> The other option I can see is something like this where bin/ and lib/
>>>would
>>> change
>>>
>>> bin/
>>>      gateway.jar - Empty executable jar with manifest main class and
>>>class
>>> path referring to JARs in lib/
>>>      ldap.jar - Empty executable jar with manifest main class and
>>>class path
>>> referring to JARs in lib/
>>>      shell.jar - Empty executable jar with manifest main class and
>>>class path
>>> referring to JARs in lib/
>>> lib/
>>>      gateway-server-0.2.0-SNAPSHOT.jar
>>>      gateway-test-ldap-0.2.0-SNAPSHOT.jar
>>>      gateway-shell-0.2.0-SNAPSHOT.jar
>>>      commons-io-2.4.jar
>>>      groovy-1.5.6.jar
>>>      jetty-6.1.26.jar
>>>      shiro-core-1.2.1.jar
>>>      ... many more ...
>>>
>>> Kevin.
>

Re: [DISCUSS] Installation JAR layout

[Kevin Minder <ke...@hortonworks.com>]

So how does this work?

I've spent the last 24 hours digging deep into Maven assemblies and 
finally have a working standalone prototype that can be used to 
implement the second model described below.
Both Larry and I prefer this model instead of the current model. This 
preferred model has individual jars as opposed to creating large 
executable jars that contain all dependencies.

So my question is how long should I wait to implement?
I don't really expect much of an opinion from anyone other that Larry at 
this point BTW.

Perhaps I'll do the work and submit a patch to the list for review and 
if nobody has input by say Monday morning apply the patch?

On 3/21/13 3:26 PM, larry mccay wrote:
>> The other option I can see is something like this where bin/ and lib/ would
>> change
>>
>> bin/
>>      gateway.jar - Empty executable jar with manifest main class and class
>> path referring to JARs in lib/
>>      ldap.jar - Empty executable jar with manifest main class and class path
>> referring to JARs in lib/
>>      shell.jar - Empty executable jar with manifest main class and class path
>> referring to JARs in lib/
>> lib/
>>      gateway-server-0.2.0-SNAPSHOT.jar
>>      gateway-test-ldap-0.2.0-SNAPSHOT.jar
>>      gateway-shell-0.2.0-SNAPSHOT.jar
>>      commons-io-2.4.jar
>>      groovy-1.5.6.jar
>>      jetty-6.1.26.jar
>>      shiro-core-1.2.1.jar
>>      ... many more ...
>>
> I believe that this is my preference.
> We may also want to add a gateway-common module that can be pulled out
> as a separate jar so that shell doesn't need to depend on all of
> server in order for them to share internal dependencies.
>
> Anyway - this approach gets my +1.
>
> On Thu, Mar 21, 2013 at 12:10 PM, Kevin Minder
> <ke...@hortonworks.com> wrote:
>> Hi Everyone,
>>
>> I want to raise an issue I been thinking about regarding the layout of the
>> install.  In particular the layout of the JARs.  Currently the build is
>> using the Maven Shade plugin to create a single executable JARs for things
>> like the server (bin/server-0.2.0-SNAPSHOT.jar), client shell
>> (bin/shell-0.2.0-SHAPSHOT.jar) and test LDAP server
>> (bin/ldap-0.2.0.SNAPSHOT.jar)
>>
>> On one had I like this because it is neat and tidy.
>>
>> On the other hand wearing my potential RM has it raises some concerns.
>>
>> 1) It complicates the LICENSE and NOTICE file generation since it is
>> difficult to see what the dependencies are other than from reports.
>> 2) The server and the shell likely share some dependencies. Creating self
>> contained JARs for each causes duplication and disk bloat.
>> 3) Does this cause or solve a patch issue?  Is it easier for customer to be
>> given a new server-0.2.1-SNAPSHOT.jar to use instead of potentially a set of
>> patched JARs?
>> 4) The Apache build env seems to be running Maven 2 and the shade plugin we
>> are using required Maven 3.
>>
>> So this is what the "install" looks like now
>>
>> bin/
>>      gateway-0.2.0-SNAPSHOT.jar
>>      ldap-0.2.0-SNAPSHOT.jar
>>      shell-0.2.0-SNAPSHOT.jar
>> lib/ - Empty but reserved for future use
>> ext/ - Empty but to be used by customers for custom extension
>> samples/ - Distributed sample files
>> templates/ - Distributed configuration templates
>> deployments/ - Location for customer topology deployments
>>
>> The other option I can see is something like this where bin/ and lib/ would
>> change
>>
>> bin/
>>      gateway.jar - Empty executable jar with manifest main class and class
>> path referring to JARs in lib/
>>      ldap.jar - Empty executable jar with manifest main class and class path
>> referring to JARs in lib/
>>      shell.jar - Empty executable jar with manifest main class and class path
>> referring to JARs in lib/
>> lib/
>>      gateway-server-0.2.0-SNAPSHOT.jar
>>      gateway-test-ldap-0.2.0-SNAPSHOT.jar
>>      gateway-shell-0.2.0-SNAPSHOT.jar
>>      commons-io-2.4.jar
>>      groovy-1.5.6.jar
>>      jetty-6.1.26.jar
>>      shiro-core-1.2.1.jar
>>      ... many more ...
>>
>> Kevin.

Re: [DISCUSS] Installation JAR layout

[larry mccay <la...@gmail.com>]

> The other option I can see is something like this where bin/ and lib/ would
> change
>
> bin/
>     gateway.jar - Empty executable jar with manifest main class and class
> path referring to JARs in lib/
>     ldap.jar - Empty executable jar with manifest main class and class path
> referring to JARs in lib/
>     shell.jar - Empty executable jar with manifest main class and class path
> referring to JARs in lib/
> lib/
>     gateway-server-0.2.0-SNAPSHOT.jar
>     gateway-test-ldap-0.2.0-SNAPSHOT.jar
>     gateway-shell-0.2.0-SNAPSHOT.jar
>     commons-io-2.4.jar
>     groovy-1.5.6.jar
>     jetty-6.1.26.jar
>     shiro-core-1.2.1.jar
>     ... many more ...
>

I believe that this is my preference.
We may also want to add a gateway-common module that can be pulled out
as a separate jar so that shell doesn't need to depend on all of
server in order for them to share internal dependencies.

Anyway - this approach gets my +1.

On Thu, Mar 21, 2013 at 12:10 PM, Kevin Minder
<ke...@hortonworks.com> wrote:
> Hi Everyone,
>
> I want to raise an issue I been thinking about regarding the layout of the
> install.  In particular the layout of the JARs.  Currently the build is
> using the Maven Shade plugin to create a single executable JARs for things
> like the server (bin/server-0.2.0-SNAPSHOT.jar), client shell
> (bin/shell-0.2.0-SHAPSHOT.jar) and test LDAP server
> (bin/ldap-0.2.0.SNAPSHOT.jar)
>
> On one had I like this because it is neat and tidy.
>
> On the other hand wearing my potential RM has it raises some concerns.
>
> 1) It complicates the LICENSE and NOTICE file generation since it is
> difficult to see what the dependencies are other than from reports.
> 2) The server and the shell likely share some dependencies. Creating self
> contained JARs for each causes duplication and disk bloat.
> 3) Does this cause or solve a patch issue?  Is it easier for customer to be
> given a new server-0.2.1-SNAPSHOT.jar to use instead of potentially a set of
> patched JARs?
> 4) The Apache build env seems to be running Maven 2 and the shade plugin we
> are using required Maven 3.
>
> So this is what the "install" looks like now
>
> bin/
>     gateway-0.2.0-SNAPSHOT.jar
>     ldap-0.2.0-SNAPSHOT.jar
>     shell-0.2.0-SNAPSHOT.jar
> lib/ - Empty but reserved for future use
> ext/ - Empty but to be used by customers for custom extension
> samples/ - Distributed sample files
> templates/ - Distributed configuration templates
> deployments/ - Location for customer topology deployments
>
> The other option I can see is something like this where bin/ and lib/ would
> change
>
> bin/
>     gateway.jar - Empty executable jar with manifest main class and class
> path referring to JARs in lib/
>     ldap.jar - Empty executable jar with manifest main class and class path
> referring to JARs in lib/
>     shell.jar - Empty executable jar with manifest main class and class path
> referring to JARs in lib/
> lib/
>     gateway-server-0.2.0-SNAPSHOT.jar
>     gateway-test-ldap-0.2.0-SNAPSHOT.jar
>     gateway-shell-0.2.0-SNAPSHOT.jar
>     commons-io-2.4.jar
>     groovy-1.5.6.jar
>     jetty-6.1.26.jar
>     shiro-core-1.2.1.jar
>     ... many more ...
>
> Kevin.

Re: [DISCUSS] Installation JAR layout

["Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>]

Hey Kevin,


On 3/21/13 9:10 AM, "Kevin Minder" <ke...@hortonworks.com> wrote:

>Hi Everyone,
>
>I want to raise an issue I been thinking about regarding the layout of
>the install.  In particular the layout of the JARs.  Currently the build
>is using the Maven Shade plugin to create a single executable JARs for
>things like the server (bin/server-0.2.0-SNAPSHOT.jar), client shell
>(bin/shell-0.2.0-SHAPSHOT.jar) and test LDAP server
>(bin/ldap-0.2.0.SNAPSHOT.jar)
>
>On one had I like this because it is neat and tidy.
>
>On the other hand wearing my potential RM has it raises some concerns.
>
>1) It complicates the LICENSE and NOTICE file generation since it is
>difficult to see what the dependencies are other than from reports.

Let's deal with this when we get to it unless you have some specific
concerns here.


>2) The server and the shell likely share some dependencies. Creating
>self contained JARs for each causes duplication and disk bloat.

We do this in OODT (helps ship independent servers). Disk is cheap, and
I'd 
favor independence over keeping the bloat down.

(my 2c)

>3) Does this cause or solve a patch issue?  Is it easier for customer to
>be given a new server-0.2.1-SNAPSHOT.jar to use instead of potentially a
>set of patched JARs?

Dunno :)

>4) The Apache build env seems to be running Maven 2 and the shade plugin
>we are using required Maven 3.

builds@apache.org can hopefully fix this for us (at least on some slave).

Cheers,
Chris

>
>So this is what the "install" looks like now
>
>bin/
>     gateway-0.2.0-SNAPSHOT.jar
>     ldap-0.2.0-SNAPSHOT.jar
>     shell-0.2.0-SNAPSHOT.jar
>lib/ - Empty but reserved for future use
>ext/ - Empty but to be used by customers for custom extension
>samples/ - Distributed sample files
>templates/ - Distributed configuration templates
>deployments/ - Location for customer topology deployments
>
>The other option I can see is something like this where bin/ and lib/
>would change
>
>bin/
>     gateway.jar - Empty executable jar with manifest main class and
>class path referring to JARs in lib/
>     ldap.jar - Empty executable jar with manifest main class and class
>path referring to JARs in lib/
>     shell.jar - Empty executable jar with manifest main class and class
>path referring to JARs in lib/
>lib/
>     gateway-server-0.2.0-SNAPSHOT.jar
>     gateway-test-ldap-0.2.0-SNAPSHOT.jar
>     gateway-shell-0.2.0-SNAPSHOT.jar
>     commons-io-2.4.jar
>     groovy-1.5.6.jar
>     jetty-6.1.26.jar
>     shiro-core-1.2.1.jar
>     ... many more ...
>
>Kevin.