shindig-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ciancetta, Jesse E." <jc...@mitre.org>
Subject RE: [PROPOSAL] Maven project enhancements to improve embedding and extending shindig-server (for Apache Rave)
Date Fri, 27 Jan 2012 13:21:09 GMT
Thanks Ate for taking the time to submit such a thorough proposal.

This all sounds good to me -- please submit the patch for review.

--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