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.
