shindig-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <>
Subject Re: [PROPOSAL] Maven project enhancements to improve embedding and extending shindig-server (for Apache Rave)
Date Fri, 27 Jan 2012 14:55:50 GMT
On 01/27/2012 02:21 PM, Ciancetta, Jesse E. wrote:
> Thanks Ate for taking the time to submit such a thorough proposal.
> This all sounds good to me -- please submit the patch for review.

Cool, will do.


> --Jesse
>> -----Original Message-----
>> From: Ate Douma []
>> Sent: Tuesday, January 24, 2012 9:29 PM
>> To:
>> Cc:
>> Subject: [PROPOSAL] Maven project enhancements to improve embedding
>> and extending shindig-server (for Apache Rave)
>> 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]
>> portal/pom.xml
>>      [...]/asf/incubator/rave/trunk/rave-portal-resources/pom.xml
>>      [...]/asf/incubator/rave/trunk/rave-portal-dependencies/pom.xml

View raw message