Hi Ate, I've spent some time today trying to replicate the changes in your patch in my own local repository and so far haven't had much luck. I'm wondering if instead of submitting a patch which tries to show the end result, if maybe you wouldn't mind specifying the SVN move commands one would need to execute to shuffle things around and then also attaching a patch just showing the files that are truly new/modified (probably just pom.xml files I'm guessing). I've also got a few questions/comments about the structure you proposed (sorry if some of this is obvious -- I haven't ever really tried to restructure anything in SVN and am not all that familiar with Maven)... I'm going to copy/paste your proposal below and add my questions/comments inline:
>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 So I think this would be: svn move --parents java/server/src/main/java java/sample-container/src/main/java >b) Move java/server/src/main/webapps/* > to new (shallow) war module java/server-resources And: svn move --parents java/server/src/main/webapp java/server-resources/src/main/webapp >c) Move resources currently merged into server module from ./../content and > ../../config also into new (shallow) war module java/server-resources I don't think we want to move these resources under a java/ path -- I think these resources are also shared by shindig-php. >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 I don't think I saw the new pom.xml for this in your last patch, could you please include it? >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 And just to be sure I fully understand the problem we're solving here -- right now people can't create their own version of what the current shindig-server module produces on their own because some of the resources required to do that are only part of the shindig-server module, right? And right now that module is only built/provided as a WAR? Thanks, --Jesse >-----Original Message----- >From: Ate Douma [mailto:a...@douma.nu] >Sent: Friday, January 27, 2012 9:56 AM >To: dev@shindig.apache.org >Cc: rave-...@incubator.apache.org >Subject: Re: [PROPOSAL] Maven project enhancements to improve >embedding and extending shindig-server (for Apache Rave) > >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:a...@douma.nu] >>> Sent: Tuesday, January 24, 2012 9:29 PM >>> To: dev@shindig.apache.org >>> Cc: rave-...@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 >>> >>> >>> >>> >>
