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" <[email protected]> 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
>> <[email protected]> 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.
>

Reply via email to