You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by Ate Douma <at...@douma.nu> on 2012/01/25 03:29:12 UTC
[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
FW: [PROPOSAL] Maven project enhancements to improve embedding and
extending shindig-server (for Apache Rave)
Posted by "Ciancetta, Jesse E." <jc...@mitre.org>.
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:ate@douma.nu]
>Sent: Friday, February 03, 2012 3:57 PM
>To: rave-dev@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:ate@douma.nu]
>>> Sent: Friday, January 27, 2012 9:56 AM
>>> To: dev@shindig.apache.org
>>> Cc: rave-dev@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: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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>
Re: [PROPOSAL] Maven project enhancements to improve embedding and
extending shindig-server (for Apache Rave)
Posted by Ate Douma <at...@douma.nu>.
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:ate@douma.nu]
>> Sent: Friday, January 27, 2012 9:56 AM
>> To: dev@shindig.apache.org
>> Cc: rave-dev@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: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
>>>>
>>>>
>>>>
>>>>
>>>
>
RE: [PROPOSAL] Maven project enhancements to improve embedding and
extending shindig-server (for Apache Rave)
Posted by "Ciancetta, Jesse E." <jc...@mitre.org>.
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:ate@douma.nu]
>Sent: Friday, January 27, 2012 9:56 AM
>To: dev@shindig.apache.org
>Cc: rave-dev@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: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
>>>
>>>
>>>
>>>
>>
RE: [PROPOSAL] Maven project enhancements to improve embedding and
extending shindig-server (for Apache Rave)
Posted by "Ciancetta, Jesse E." <jc...@mitre.org>.
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:ate@douma.nu]
>Sent: Friday, January 27, 2012 9:56 AM
>To: dev@shindig.apache.org
>Cc: rave-dev@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: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
>>>
>>>
>>>
>>>
>>
Re: [PROPOSAL] Maven project enhancements to improve embedding and
extending shindig-server (for Apache Rave)
Posted by Ate Douma <at...@douma.nu>.
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
>>
>>
>>
>>
>
Re: [PROPOSAL] Maven project enhancements to improve embedding and
extending shindig-server (for Apache Rave)
Posted by Ate Douma <at...@douma.nu>.
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
>>
>>
>>
>>
>
RE: [PROPOSAL] Maven project enhancements to improve embedding and
extending shindig-server (for Apache Rave)
Posted by "Ciancetta, Jesse E." <jc...@mitre.org>.
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
>
>
>
>
RE: [PROPOSAL] Maven project enhancements to improve embedding and
extending shindig-server (for Apache Rave)
Posted by "Ciancetta, Jesse E." <jc...@mitre.org>.
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
>
>
>
>