Yep no need for a VOTE, and thanks for checking in! :) Cheers, Chris
On 3/22/13 9:36 AM, "Kevin Minder" <[email protected]> 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 >> <[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. >>> >
