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:[email protected]]
Sent: Friday, January 27, 2012 9:56 AM
To: [email protected]
Cc: [email protected]
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:[email protected]]
Sent: Tuesday, January 24, 2012 9:29 PM
To: [email protected]
Cc: [email protected]
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
