shindig-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
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.

Ate

>
> --Jesse
>
>> -----Original Message-----
>> From: Ate Douma [mailto:ate@douma.nu]
>> Sent: Tuesday, January 24, 2012 9:29 PM
>> To: dev@shindig.apache.org
>> Cc: rave-dev@incubator.apache.org
>> 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] 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
>>
>>
>>
>>
>


Mime
View raw message