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. > >
