shindig-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <>
Subject [PROPOSAL] Maven project enhancements to improve embedding and extending shindig-server (for Apache Rave)
Date Wed, 25 Jan 2012 02:29:12 GMT
Hi Shindig team,

At Apache Rave (Incubating) we're embedding and extending the shindig-server 
module and build our own rave-shindig war using a war overlay configuration.

While that kind of works for now, using the current Shindig server war module as 
an overlay isn't really optimal, as Maven cannot do (transitive) dependency 
resolution analysis on war modules.

Effectively this means we'll either have to exclude all embedded jars within the 
shindig-server war and then manually (re)define the same dependencies ourselves 
again, or we have to (at least) manually check and trace the shindig-server 
internal dependencies and do our own sanity check on them. The latter really is 
dangerous as it easily can lead to 'duplicate jars' hell...

For the record, at Apache Rave we currently use the latter solution, but in the 
end that is not maintainable and too easy to break.

In addition to this, the shindig-server also comes with its own sample container 
code, which means those classes end up directly in the WEB-INF/classes folder of 
the war. These classes are thereby also completely 'hidden' from our own 
rave-shindig classpath and thus not 'usable' from a developers perspective 
(other than forking/cloning them ourselves, and/or excluding them from the war 
overlay through configuration).

It would be much easier for downstream projects as Apache Rave, or even further 
down the chain, if the shindig-server module would be a bit more modularized by 
separating the 'base' war resources, the sample container code and the server 
war dependencies into separate modules, which then are (re)bundled by the final 
shindig-server war module.

This would have zero impact on current shindig-server usages (effectively the 
produced war ends up being the same), but helps downstream projects enormously 
with a better and more transparent manageable custom Maven shindig configuration.

At Apache Rave we already provide a similar modularization of our rave-portal 
war module [1] for the same purpose: to make it easier for downstream 

In short, my proposal is the following (and I have a patch ready for review):

a) Move java/server/src/main/java/* (sample container code)
    to new jar module java/sample-container
b) Move java/server/src/main/webapps/*
    to new (shallow) war module java/server-resources
c) Move resources currently merged into server module from ./../content and
    ../../config also into new (shallow) war module java/server-resources
d) Add new pom module java/server-dependencies which (only) defines
    the runtime dependencies needed for the shindig-server module
    Note: this should also add new dependency on shindig-sample-container
e) The remainder of the shindig-server module then only needs to have
    dependencies on the shindig-server-resources (war overlay) and
    shindig-server-dependencies (pom), as well as some needed test only
    dependencies for the remaining "endtoend" unit-tests

The end result of the above will again be a shindig-server war equal to the 
current shindig-server war but now downstream users can more easily embed and 
extend it, with proper maven (transitive) dependency resolution support.

The above changes really are quite trivial and will have zero impact for 
development and current end usages.

If there are no objections for the above proposal, I'll create a JIRA ticket and 
provide a patch for it for review.

And as Shindig 3.0.0 is close to getting wrapped up, it would be great if this 
then can be reviewed, and if accepted, be applied before the release tag.

Thanks, Ate
Apache Rave PMC

p.s. A different but more critical topic, I just noticed that the NOTICE and 
LICENSE files embedded in the shindig-server war (and probably other modules 
too) are not proper, e.g. completely missing the required 3rd party notices and 
licenses! I do see better versions of these in the root and the java folder, but 
these don't end up in the build and released artifacts as they should...
I'll follow up on this later (probably tomorrow) in a separate email and see if 
I can provide a fix/patch for that as well.


View raw message