You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Grzegorz Kossakowski <gr...@tuffmail.com> on 2007/08/20 20:33:46 UTC
GSoC final report
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. ***
Re: GSoC final report
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* Jean-Baptiste Quenot:
> Congratulations for providing such a longly-awaited feature in
> such a short period of time, you rock! I hope you'll be attending
> the GetTogether, as I have to learn how to pronounce your name :-)
OK I'm still catching up, but looks like this « issue » has
already been adressed :-)
http://reflectingonthevicissitudes.wordpress.com/2007/04/22/pal-how-can-i-call-you/
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
Re: GSoC final report
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
Congratulations for providing such a longly-awaited feature in
such a short period of time, you rock! I hope you'll be attending
the GetTogether, as I have to learn how to pronounce your name :-)
Cheers,
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
Re: GSoC final report
Posted by Peter Hunsberger <pe...@gmail.com>.
On 8/20/07, Grzegorz Kossakowski <gr...@tuffmail.com> wrote:
<snip/>
Very nice, many thanks for all yoru hard work.
--
Peter Hunsberger
Re: GSoC final report
Posted by Antonio Gallardo <ag...@agssa.net>.
Grzegorz,
Thanks for your great contribution! :)
Best Regards,
Antonio Gallardo.
Re: GSoC final report
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Grzegorz Kossakowski pisze:
> Carsten Ziegeler pisze:
>> Really great work, Grzegorz!!
>
> Thanks for words of praise to you and others. It's really kind. :)
>
>> Cocoon has produced many really useful and cool stuff over the years.
>> Your work shows that it's possible to refactor this into reusable
>> modules which can be used outside of the traditional Cocoon framework
>> like the el stuff (or the spring configurator etc). And i think that
>> this is the way to go.
>
> Yes, I couldn't much more agree.
> I would like to help any effort aiming at making Cocoon more modular and
> could even drive such. First step is always getting rid of Avalon as it
> effectively stops us from having more declarative approach on
> joint-points between modules (see ObjectModelProvider and joint-point
> between cocoon-expression-language and cocoon-sitemap modules). Next
> thing is to move functionality in broad interest of other modules to
> separate module (see COCOON-2125 for example of such move).
Oh, and there is one more thing, if you use Eclipse you probably use mvn eclipse:eclipse command in
order to import all Cocoon modules to Eclipse. Apart from the fact that mvn eclipse:eclipse is buggy
it sucks miserably when it comes to refactoring, especially when new modules are created (or
generally dependencies are changed). Fortunately enough, there is another way to import project into
Eclipse.
I'm going to create a new post on my blog "How I work with Cocoon in Eclipse" or something like this
and explain how to work develop Cocoon effectively.
Now getting back to Math work.
--
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. ***
Re: GSoC final report
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Carsten Ziegeler pisze:
> Really great work, Grzegorz!!
Thanks for words of praise to you and others. It's really kind. :)
> Cocoon has produced many really useful and cool stuff over the years.
> Your work shows that it's possible to refactor this into reusable
> modules which can be used outside of the traditional Cocoon framework
> like the el stuff (or the spring configurator etc). And i think that
> this is the way to go.
Yes, I couldn't much more agree.
I would like to help any effort aiming at making Cocoon more modular and could even drive such.
First step is always getting rid of Avalon as it effectively stops us from having more declarative
approach on joint-points between modules (see ObjectModelProvider and joint-point between
cocoon-expression-language and cocoon-sitemap modules). Next thing is to move functionality in broad
interest of other modules to separate module (see COCOON-2125 for example of such move).
They are more trickier issues of course like pipeline's setup but Daniel already posted[1] some
ideas how to improve it.
[1] http://marc.info/?l=xml-cocoon-dev&m=118755548212158&w=2
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: GSoC final report
Posted by Carsten Ziegeler <cz...@apache.org>.
Really great work, Grzegorz!!
Cocoon has produced many really useful and cool stuff over the years.
Your work shows that it's possible to refactor this into reusable
modules which can be used outside of the traditional Cocoon framework
like the el stuff (or the spring configurator etc). And i think that
this is the way to go.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: GSoC final report
Posted by Torsten Curdt <tc...@apache.org>.
On 21.08.2007, at 23:56, Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
>> You have done an excellent work Grzegorz.
>
> +1
>
> <snip/>
>
>> While I have lot of expeience in teaching, coaching and mentoring
>> IRL, this is the first time I have mentored someone that I never
>> have met IRL, over email. I'm supprised that it has worked so
>> well. An important factor is that you have written so much on the
>> list so that I have been able to see what is going on.
>
> I also want to stress that your communication with the rest of the
> community was excellent and I don't think that you failed in this
> regard. Without having had the time to activly participate in every
> discussion, I think I have a good understanding of what you did and
> I want to thank you for it!
+1
cheers
--
Torsten
Re: GSoC final report
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> You have done an excellent work Grzegorz.
+1
<snip/>
> While I have lot of expeience in teaching, coaching and mentoring IRL,
> this is the first time I have mentored someone that I never have met
> IRL, over email. I'm supprised that it has worked so well. An important
> factor is that you have written so much on the list so that I have been
> able to see what is going on.
I also want to stress that your communication with the rest of the community was
excellent and I don't think that you failed in this regard. Without having had
the time to activly participate in every discussion, I think I have a good
understanding of what you did and I want to thank you for it!
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: GSoC final report
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Daniel Fagerstrom pisze:
> You have done an excellent work Grzegorz. Unified expressions will
> simplify usage of Cocoon and your refactoring will simplify
> development of Cocoon. Above that you have done a lot of good
> community and infrastructure work and helped revitalizing the
> community. Thanks to all your discussions Cocoon has been rather
> active during the summer.
>
> During GSoC you had to force yourself to go in to part of Cocoon where
> only the bravest dare to go, you killed some of the mosters that where
> lurking there making it safer for the rest of us and managed to
> survive the process ;)
Yes, those monsters was the hardest part. Thank you all for the support.
> I would guess that GSoC was both tougher and more rewarding than you
> had expected. During the summer you had to deal with the challange of
> applying theory on complex "real world" problems, to prioritze between
> what is important and what is not. Most of your co-students will not
> get these learnings until they do they master thesis or start to do
> work or research.
>
> It has been a pleasure to see how you have matured and grown in
> confidence both as a program developer and as a community participant.
>
> For me it has taken a lot of work to participate in all the technical
> discussions. But it has of course been very flattering to se my name
> and suggestions cited all the time ;) And to see my vague suggestion,
> be concretizied, improved and end up becomming working code.
>
> While I have lot of expeience in teaching, coaching and mentoring IRL,
> this is the first time I have mentored someone that I never have met
> IRL, over email. I'm supprised that it has worked so well. An
> important factor is that you have written so much on the list so that
> I have been able to see what is going on.
I really, really appreciate your and other's effort by participating in
these discussions. I wanted to discuss everything for two reasons:
1. I believe in collaboration. It proved so many times that other people
can help one crack really hard problems.
2. Whenever I work with Cocoon I always have open browser with our
mailing list archives ready for searching. Because of this unwritten
rule that we discuss all major changes to the code I could understand
why certain piece of code exists, what's its use, why it was done
exactly that way, etc. Especially when dealing with Cocoon internals it
was invaluable help! While working on new stuff I wanted to contribute
both to our code repository and mailing list archives. I believe it
equally matters.
> Thanks for you great work and dedication during this summer.
Thank you too!
Daniel, are you going to visit Rome in October?
--
Grzegorz Kossakowski
Re: GSoC final report
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
You have done an excellent work Grzegorz. Unified expressions will
simplify usage of Cocoon and your refactoring will simplify development
of Cocoon. Above that you have done a lot of good community and
infrastructure work and helped revitalizing the community. Thanks to all
your discussions Cocoon has been rather active during the summer.
During GSoC you had to force yourself to go in to part of Cocoon where
only the bravest dare to go, you killed some of the mosters that where
lurking there making it safer for the rest of us and managed to survive
the process ;)
I would guess that GSoC was both tougher and more rewarding than you had
expected. During the summer you had to deal with the challange of
applying theory on complex "real world" problems, to prioritze between
what is important and what is not. Most of your co-students will not get
these learnings until they do they master thesis or start to do work or
research.
It has been a pleasure to see how you have matured and grown in
confidence both as a program developer and as a community participant.
For me it has taken a lot of work to participate in all the technical
discussions. But it has of course been very flattering to se my name and
suggestions cited all the time ;) And to see my vague suggestion, be
concretizied, improved and end up becomming working code.
While I have lot of expeience in teaching, coaching and mentoring IRL,
this is the first time I have mentored someone that I never have met
IRL, over email. I'm supprised that it has worked so well. An important
factor is that you have written so much on the list so that I have been
able to see what is going on.
Thanks for you great work and dedication during this summer.
/Daniel
Re: GSoC final report
Posted by Stephen Rosman <fl...@gmail.com>.
>
>
> Cocoon internals are quite big, it includes:
> * treeprocessor (sitemap engine)
> * pipelines handling
> * enviornment handling
> * Avalon-Spring bridge
> and much, much more.
>
> What are you especially interested in? What's the goal behind getting to
> know about Cocoon internals?
>
>
Well I'm trying to use cocoon at work (I work at a Australian state
parliament - nothing
published yet but the first project is producing members information as
pdf/csv/web
pages etc).
There's a couple of areas where the documentation is a little lacking (e.g.
the esql logic
sheet) I'd like to be able to extend some parts (e.g. esql being able to
bind an array of
values to a parameter for an IN clause) and write some components (e.g. FO
to HWPF
serialiser).
Now although that doesn't sound like I need to know about the internals, I
could just
work on logic sheets etc. there's always Joel Spolsky's law of leaky
abstractions and
since the project has been so useful to me I'd like to be able to help,
which is not
entirely altruistic since if the project is healthy it's more likely to hang
around longer
and there will be more higher paid jobs around using it. :-)
Re: GSoC final report
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Stephen Rosman pisze:
> 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.
>
>
> I'd like to become more familiar with the internals of cocoon. What
> would be your
> advice on how to go about it?
Cocoon internals are quite big, it includes:
* treeprocessor (sitemap engine)
* pipelines handling
* enviornment handling
* Avalon-Spring bridge
and much, much more.
What are you especially interested in? What's the goal behind getting to know about Cocoon internals?
--
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. ***
Re: GSoC final report
Posted by Stephen Rosman <fl...@gmail.com>.
>
> 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.
>
I'd like to become more familiar with the internals of cocoon. What would
be your
advice on how to go about it?
Re: GSoC final report
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 8/21/07, Joerg Heinicke <jo...@gmx.de> wrote:
> ...Grek, in my opinion you did a great job in probably every aspect....
+1, very impressive!
-Bertrand
Re: GSoC final report
Posted by Joerg Heinicke <jo...@gmx.de>.
On 20.08.2007 14:33 Uhr, Grzegorz Kossakowski wrote:
> 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.
Grek, in my opinion you did a great job in probably every aspect. You
don't need to achieve every objective or be perfect in reporting -
that's not how open source works, even if you were on a special project
and get paid for it. I liked it a lot to discuss with you and others
which gave me more inside details as well.
I wish you much success with your exams! And I hope to see you back
afterwards with full power :)
Joerg