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