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
customizations.
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.
[1] https://svn.apache.org/repos/asf/incubator/rave/trunk/rave-portal/pom.xml
[...]/asf/incubator/rave/trunk/rave-portal-resources/pom.xml
[...]/asf/incubator/rave/trunk/rave-portal-dependencies/pom.xml
