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.
