Hello,
I would like to present final report on my GSoC final progress to you. Before going into details, I
would like to thank you all who helped me by giving advices, suggestions and useful criticism. I
would like to give special thanks to Daniel who accepted to be my mentor.
While working on Uunified Object Model and unified handling of expression langues I created and
resolved eighteen JIRA issues:
Key Summary
COCOON-2125 Remove dependency on cocoon-pipeline-impl in
cocoon-expression-language-impl
COCOON-2124 Change scope of Object Model to pipelineComponent
COCOON-2122 Implement pipeline component scope
COCOON-2121 Servlets mounted at "/" are handled improperly.
COCOON-2120 Move sitemap.xmap and other stuff from cocoon-webapp to it's own
block
COCOON-2117 Put sitemap variables on Object Model
COCOON-2115 Implement evaluation of sitemap expressions in a class implementing
StringTemplateParser interface
COCOON-2113 Switch pluggable String parsers from Avalon to Spring
COCOON-2112 Move pluggable string parsers from cocoon-template to
cocoon-expression
COCOON-2110 Evaluate expressions defined in cocooon-expression-language-api
in Sitemap engine
COCOON-2103 Replace Initialization of Object Model by helper classes with
more solid mechanisms
COCOON-2095 Make Object Model a Spring bean
COCOON-2094 Get rid of ExpressionContext usage
COCOON-2092 Switch to new Object Model implementation in cocoon-template
COCOON-2086 Invent API for Object Model and use it in template block
COCOON-2085 Implement new, universal Object Model
COCOON-2082 Get rid of Avalon dependencies in cocoon-expression-language code
COCOON-2081 Move api and implementation of expression languages to separate
module
All generated 163 commits in our repository.
Since a while I believe in saying "Show me dependencies of your code and I'll tell you how good it
is." :-)
Le'ts take a look at dependencies of cocoon-language-expression-impl:
* org.apache.cocoon:cocoon-expression-language-impl:jar
o org.apache.cocoon:cocoon-expression-language-api:jar
o org.apache.cocoon:cocoon-xml-util:jar
+ xml-apis:xml-apis:jar
o commons-lang:commons-lang:jar
o commons-collections:commons-collections:jar
o commons-jexl:commons-jexl:jar
o commons-jxpath:commons-jxpath:jar
+ commons-logging:commons-logging:jar
# log4j:log4j:jar
# logkit:logkit:jar
# avalon-framework:avalon-framework:jar
o rhino:js:jar
o org.springframework:spring-beans:jar
+ org.springframework:spring-core:jar
o javax.servlet:servlet-api:jar
o xmlunit:xmlunit:jar
o junit:junit:jar
(this list includes all transitive dependencies, generated by mvn
project-info-reports:dependencies)
I must admit that I'm very proud of this list, as you see there is no other Cocoon module here.
There is no Avalon (except weird dependency of commons-logging) dependencies here because I got rid
of all Avalon code while moving/creating code in EL modules. Some of you may don't like that this
module depends on Rhino or JXPath. It's not a big deal with current structure of EL module and
dependencies between classes. If you want to factor out e.g. Javascript expression langauge it's
really matter of creating new Maven module and moving few files, only.
Next thing is that I managed to fully switch cocoon-template to new expression languages and remove
complicated and error-prone code responsible for initialization of Object Model. Situation has been
improved dramatically because all initialization happens in beans implementing ObjectModelProvider
interface that itself is very lightweight (it contains one method only). What's more important,
various object model providers are in responsibility of parts of Cocoon that actually handle exposed
data. For example, $cocoon variable in Object Model gives access to environmental data like request.
Since Request interface and implementation is in cocoon-sitemap-* modules, Object Model provider is
also there.
In fact, it was Daniel's suggestion to do it that way and following this practise I could quickly
remove most of crappy dependencies that coupled various modules together. I guess that similar
practises would help us to cut dependencies amongst Cocoon modules in general. When we are at
reducing dependencies, I think I managed to remove most of code relying on Avalon from
cocoon-template so it should be quite easy to switch it from Avalon to Spring. Any volunteers? :-)
Next thing I managed to do is to make sitemap variable resolution pluggable. Again, following
Daniel's suggestion I created special VariableResolver that delegates parsing and resolution of
string templates to the classes implementing StringTemplateParser interface. Now it's matter of one
line of configuration file to switch sitemap to new expression language handling code and start to
use exactly the same Object Model and ELs as in templates. I must give a word of caution here: I
tested this functionality briefly with new ELs so there may be some bugs and if you are going to try
it out don't hesitate to ask question. I'll be very happy to help.
Last big thing I managed to do is introduction of pipeline component scope. It was really tricky
subject for me (and as we have seen, for others too) and I'm very happy with my current solution
that, even needs adjustments, in general is very convenient and elegant IMHO. Now, if you want to
put parameters on Object Model it's few lines of code in class implementing MethodInterceptor
interface (you just need to catch calls to the setup() method and put parameters on ObjectModel there).
Now I would like to focus on things that I didn't managed to do. First of all, I didn't implement
convertor concept. At the beginning I was lost a little bit in thread discussing possible reuse of
code from Spring. Then I thought that it should not have a high priority because it's a concept that
will be easy to implement later and it's more important to focus on things that are more
effort-demanding and involve expertise in lots of Cocoon areas. That was the main reason why I
decided to finish off OM initialization code and sitemap refactorings. It really took handful amount
of time (and stress sometimes) to feel comfortable and productive in these areas. I did want to
provide solid basis for other enhancements that can be built on top of it.
I also didn't touch Forms even I really wanted. There was only one reason for this: lack of time.
When planning things I was going to do I really wasn't aware of how how hard it would be to get
familiar with all Cocoon guts. In short: I planned to do too much underestimating my goals. While
planning I did take into account that there is a real life out there and sometime I couldn't
hack/learn all the day. There were also extremely annoying issues like my ISP behaviour that forced
me to put this ugly disclaimer on my e-mail's signature.
Approaching the end of this e-mail I must admit that I failed on even one more thing: communication.
I promised to give weekly reports on progress but I didn't manage to do it. It was mainly because I
didn't want to write about highly technical, detailed things that occurred while refactoring old
code. I've been also very confused for many times and didn't know if it's right time to report on
progress. Complexity of the task was so high for me sometimes that I was just lost and wouldn't
report anything with confidence, at all ;)
Thinking about it further, GSoC organizers constantly say that GSoC isn't just about deliverables
and thousands of lines of code. It's a chance for students to get involved into OS project, to
gather enough knowledge and excitement to stay with project after GSoC period ends. You can be sure
that I'm excited and I'm going to continue my work. However, remember that it's no longer GSoC work
so it's really desirable that others will join the effort. I would really like to avoid one-man show.
When talking about continuation of my work I should say that I'll not be able to do much until 15th
of September because I'm going to have exams at university and I'll really, really need to focus on
this now. Up to this date I'll limit my activity to occasional discussing and helping others if
there is some problem with my recent work.
Thank you for cooperation.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
*** My Internet Service Provider breaks my internet connection
***
*** incessantly so I'll not be able to respond to e-mails
***
*** regularly and my work will be somehow irregular.
***
*** I'm already trying to switch ISP but it will take handful amount of time.
***
