You're fine I think -- no need to revert. Cheers, Chris
On 3/22/13 12:16 PM, "Kevin Minder" <[email protected]> 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 >>> <[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. >>>> >> >
