Ate replied to me last week but it looks like it only went to rave-dev@ -- forwarding to dev@shindig too...
>-----Original Message----- >From: Ate Douma [mailto:a...@douma.nu] >Sent: Friday, February 03, 2012 3:57 PM >To: rave-...@incubator.apache.org >Subject: Re: [PROPOSAL] Maven project enhancements to improve >embedding and extending shindig-server (for Apache Rave) > >On 02/03/2012 05:56 PM, Ciancetta, Jesse E. wrote: >> 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. >Ugh, I'm sorry for the trouble I caused. >I really thought I had the patch fixed the second time around, but of course I >should have tried it out locally on a clean checkout first, mea culpa. > >> 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 >> >Yes, that indeed will make it much easier. Providing diff patches for svn tree >moves simply doesn't work :( > >I've already created a new patch, to be applied *first* and thereafter you only >need to execute almost the same commands as you give above: > > $ svn move --parents java/server/src/main/java >java/sample-container/src/main/java > $ svn move --parents java/server/src/main java/server-resources/src/main > >The difference being the last commands moves the entire remaining >server/src/main folder (not just the webapp folder underneath). > >I'll upload the new patch for review shortly, with the comment to execute >these >commands *afterwards* to end up with the desired result. > >>> 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. >Definitely. My wording wasn't clear enough: I didn't mean to move the >sources, >but the merging of the sources, e.g. move it from server/pom.xml to >server-resources/pom.xml >This change is taken care of in the patch. > >> >>> 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? >Right, that's were the second patch weirdly went wrong. Strangely enough I >still >have the modified source tree locally and when I recreated the patch anew it >*does* have this new pom.xml in there. Nevermind, I'll upload a new patch >which >contains it, but without the tree moves. >> >>> 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? > >That is correct. > >The problem is that with only a war artifact, containing everything, >customizing >and extending shindig-server is difficult if not downright brittle. >Maven simply doesn't understand war files from a transitive dependency POV >and >thus you easily end up with duplicate jars (different versions of the same >artifact) in the end result (like we already did with rave-shindig). > >Furthermore, because shindig-server also contains (sample) java code, there >is >no way you can easily *not* use those without having to write maven-war- >plugin >filters to exclude the embedded class files, nor could you write and compile >extensions on those java classes as they are not available from any classpath >at >build time. > >By modularizing shindig-server into server-resources, server-dependencies >and >the java code into sample-container, (re)assembling shindig-server becomes >trivial, and thereby equally trivial for custom projects like rave-shindig. > >Thanks for looking into the patch Jesse, the next fix should be smooth :) > >Regards, Ate > >> >> 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 >>>>> >>>>> >>>>> >>>>> >>>> >>
