Re: [GSoC_2008] Project ideas
Grzegorz Kossakowski wrote:
Vadim Gritsenko pisze:
On Mar 13, 2008, at 11:54 AM, Reinhard Poetz wrote:
Yesterday I was introduced to an Austrian student who would be
interested in
working on a GSoC for the Cocoon project this year.
The best idea we've had so far was was an upgrade of cForms to Dojo
1.x (or
replacing it with something else if that is what the community is
interested in).
Yes that is a good one.
+1
Any other suggestions? (the deadline for project proposals is Monday,
17th of March)
Finish SSF implementation? There is a lot of TODOs in there last time
I've seen it.
+1
Optimize SSF? Get rid of buffering on service invocations - or at
least past SAX buffer around.
Actually, real streaming is not possible but using SAX buffer is a good
idea so: +1 for this proposal. I would add:
1. Migrate more stuff to Spring (like i18n transformer, databases stuff,
etc.)
2. Write complete Schema for all of our grammars (JX, Forms, Sitemap, etc.)
WDYT?
+1 for the ideas, but they are very specific and only for insiders like you.
Grzegorz, do you still consider applying for GSoC this year?
Another idea: Provide a command-line interface again, maybe by working together
with the Forrest folks so that they can migrate to 2.2?
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: [GSoC_2008] Project ideas
Reinhard Poetz pisze: +1 for the ideas, but they are very specific and only for insiders like you. Grzegorz, do you still consider applying for GSoC this year? Not sure. I'd love to apply and do some more Cocoon-related work during the summer but I'm really concerned about USD ratings. :-( All in all, I have to pay bills like everyone other and I think that these days I cannot trust USD anymore. However, I'm still considering prons and cons... Another idea: Provide a command-line interface again, maybe by working together with the Forrest folks so that they can migrate to 2.2? +100! I hope that you don't want to mimic our previous implementation of CLI that seriously impacted our APIs. I would like to see CLI implemented using external tools. -- Grzegorz Kossakowski
Re: Micro-Cocoon ... Corona
Reinhard Poetz pisze: First of all, there is not much to worry about. We're talking about 4.5 days worth of thinking, planning, and developing. That's not much compared to the about 10 days (3 days with 3-4 people) we spent here in Vienna in February. I believe the fact that I'm not a Cocoon commit is actually an advantage here. It allowed me to think out of the box and be unaffected by the current implementation. After all we're talking about a rewrite. Wouldn't make much sense, if we did everything the same way, would it. Of course this means some things are different than Cocoon is now. But I'm confident any Cocoon committer can easily understand Corona and draw parallels with the current Cocoon. The basic concept - like the sitemap, pipelines, etc. - are still the same, just reimplemented. The current code base consists of about 750 lines of code (according to Cobertura). So there isn't much code to be understood either. Well said, there isn't much to add. Grzegorz, I don't really understand what you are worried about. Is it because Steven is not (yet) an active member? Or is it because we developed Corona behind closed doors for about *4.5 days*? That not much time IMO. As Steven pointed out, we want to share the code with this community. It's not meant to be a finished piece of software where all contracts are cast in stone. It's rather the opposite. We would be more than happy to get detailed feedback on the chosen designs (The architecture is more or less the one of 2.x.) and we don't think that we got all things right at the first shot. We also don't have ego problems so that we couldn't take critisisms. I must admit I misunderstood the situation. I had different imagination (much exaggerated) of Corona compared to what it actually is. Now I'm glad to see that you want to share your work right from the beginning and let whole community participate in the effort (including me). I'm waiting impatiently to see this moving forward :-) Thinking further, in my opinion it is a great chance to attract new developers and users because one of the main goals of Corona is that it can be easily used from within different environments. This would mean that it may become attractive to many other (opensource) projects (again). I hope you (and many others) give Corona a chance and take a look at it. Agreed. What about officially announcing our effort at main site with simple manifesto? I have a feeling that we agree on fundamental goals so writing such a document shouldn't be a problem, right? I would like to see as many as possible people participating or at least aware of the move. -- Grzegorz Kossakowski
Re: Micro-Cocoon ... Corona
Grzegorz Kossakowski wrote: Reinhard Poetz pisze: snip/ Thinking further, in my opinion it is a great chance to attract new developers and users because one of the main goals of Corona is that it can be easily used from within different environments. This would mean that it may become attractive to many other (opensource) projects (again). I hope you (and many others) give Corona a chance and take a look at it. Agreed. What about officially announcing our effort at main site with simple manifesto? I have a feeling that we agree on fundamental goals so writing such a document shouldn't be a problem, right? I don't think this is a good idea. The cocoon.apache.org website is for our users, and talks about stable or upcoming releases, even if 2.2 has been upcoming for years ;-) Corona is a different thing, because it is an experiment started by some members of the community, that other members are interested in looking at, and *may* become something we release in an unknown future, or simply be trashed if we decide it's an effort not worth pursuing. So it is way too early to talk about it to the people visiting cocoon.apache.org, especially as 2.2 is close to be released as final. Releasing 2.2 and announcing a revolution would give a very disturbing message. I would like to see as many as possible people participating or at least aware of the move. The move isn't decided yet. But you can count on the people on this list to jump in if they find it worth it. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Micro-Cocoon ... Corona
Grzegorz Kossakowski wrote:
Now I'm glad to see that you want to share your work right from the
beginning and let whole community participate in the effort (including
me). I'm waiting impatiently to see this moving forward :-)
Steven and I will need some more time to tidy up Corona. If time permits we can
publish Corona on Wednesday, otherwise on Friday.
Thinking further, in my opinion it is a great chance to attract new
developers and users because one of the main goals of Corona is that
it can be easily used from within different environments. This would
mean that it may become attractive to many other (opensource) projects
(again).
I hope you (and many others) give Corona a chance and take a look at it.
Agreed. What about officially announcing our effort at main site with
simple manifesto? I have a feeling that we agree on fundamental goals so
writing such a document shouldn't be a problem, right?
I plan to write a blog entry about it so that the information gets spread to a
wider audiance. For a public announcement it's too early, especially so close
before we release 2.2.
And don't forget, for the time being it's just Steven and I who have been
contributing to it. Given others showed their interest and I'm *really happy*
about this, but to make it a community-driven effort, active involvement by
others is required. Then it's up to the Cocoon PMC to decide about the next steps.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Micro-Cocoon ... Corona
Reinhard Poetz pisze: Agreed. What about officially announcing our effort at main site with simple manifesto? I have a feeling that we agree on fundamental goals so writing such a document shouldn't be a problem, right? I plan to write a blog entry about it so that the information gets spread to a wider audiance. For a public announcement it's too early, especially so close before we release 2.2. Thanks Reinhard and Sylvain for reminding me rules and best-practices to be applied in such situations. I agree that it's better to spread by using blogosphere and personal contacts. My main intention was to bring here old committers and people trying to do more or less the same[1]. I'm really looking for your blog-entry Reinhard. And don't forget, for the time being it's just Steven and I who have been contributing to it. Given others showed their interest and I'm *really happy* about this, but to make it a community-driven effort, active involvement by others is required. Then it's up to the Cocoon PMC to decide about the next steps. Ok. I'm young committer that happened to contribute to Cocoon in rather calm days so I don't know procedures to be undertaken in such situations. [1] http://kauriproject.org/wiki/65-kauri.html -- Grzegorz Kossakowski
Re: Micro-Cocoon ... Corona
David Crossley wrote:
Reinhard Poetz wrote:
Of course we are! We only have to work out the details of how we do it. The
main question is, if we have to go through ASF IP clearance or not.
Since it's rather a proposal than a finished project (~700 lines of code),
I think it's enough if Steven sends in an CLA and attaches the code to a
Jira issue.
In the meantime (until Steven's CLA is recorded) we could prepare a
snapshot package of Corona that we make privatly available to the Cocoon
PMC.
Is this a viable procedure?
I consider that it is.
It is your creative work, so it is just contributed
under your Individual CLAs. You and Steven declare that
you have the rights to contribute it.
For your benefit, you might need the Corporate CLA
if your ability to contribute is not clear with respect to
your employment agreement. Probably okay in your case.
All people working for/with Indoqa are free (and of course encouraged) to
contribute to opensource projects. That's also being made explicit in our
individual contracts with the company.
Thanks for your reminder: In my role as managing directory, I will also send a
CCLA to the ASF secretry to make this explicit.
Thanks David for your confirmation!
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Test release artifacts - Legal requirements check
David Crossley wrote:
Reinhard Poetz wrote:
Reinhard Poetz wrote:
This time I will
create the Maven 2 release artifacts and normal zip/tar release
artifacts for non-Maven users.
I created release artifacts for the Servlet-Service framework using the old
RC1 release form October last year and published them to
http://people.apache.org/~reinhard/cocoon-staging/ssf/.
Could others please have a look and check if those release artifacts meet
all legal requirements?
I see that the META-INF/NOTICE.txt etc. files in each
of cocoon-components and impl directory, would correspond
with those from the sources. However where does top-level
NOTICE.txt file come from? Should it be generated as a
combination of the other two? The files in the sub-directories
could potentially be different.
The problem is that the release artifacts are sometimes collections of several
more focused artifacts, at least in the Maven 2 world they get distributed in
smaller units.
I guess that the correct solution is that each of those collection release
artifacts has to contain a hand-crafted NOTICE.txt file. The license should
because of the ASF policy always be the same.
I expected a top-level cocoon-servlet-service directory
to be created. Should it?
good suggestions. I will fix this in the script.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Test release artifacts - Legal requirements check
David Crossley wrote:
I saw that some committers have been using lowercase filenames
e.g. notice.txt, so the release-builder needs to handle that.
Is there some requirement that the file names of notice.txt and license.txt have
to be either lower or upper case? Or is it up to us?
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Normal release artifacts
Vadim Gritsenko wrote:
IMHO what's good a downloadable release if 'cocoon.sh run' does not
work?
I'm not sure if I understand your concerns here correctly. Maybe I wasn't clear
about what release artifacts I want to create. Here's the list:
1. cocoon-core-2.2.0.zip
cocoon-servlet-service-1.0.0.zip
cocoon-configuration-1.0.0.zip
2. cocoon-fop-1.0.0.zip
cocoon-forms-1.0.0.zip
... [all the other blocks]
3. cocoon-2.2-getting-started-1.0.0.zip
cocoon-2.2-legacy-getting-started-1.0.0.zip
4. cocoon-samples-1.0.0.zip
1. and 2. are the releases of our production ready sources (+ docs, +javadocs,
+binaries). If somebody wants to use Cocoon in one of his projects and doesn't
want to use Maven 2, Ivy or the Maven Ant tasks, he has to download them and add
the libraries to his (web) application.
To some extend it is even dangerous to add third-party libraries because this
might lead to the inclusion of conflicting versions (or at least to unintended
duplication) just because you add the libraries of several e.g. Cocoon blocks
that were created at different times.
The second purpose of 1. and 2. is providing a single release artifact of parts
that belong together (docs, apidocs, sources, binaries). As it was pointed out
several times by you and others, it feels strange to have only Maven 2 release
artifacts.
3. and 4. are different. 'cocoon-2.2-getting-started' is a suggestion how you
could organize a Cocoon project that uses blocks and that uses Ant as build
system. We could also have a 'cocon-2.2-legacy-getting-started' package, that
uses Cocoon the old way without using the SSF infrastructure.
'cocoon-samples' is the package for that the 'cocoon.sh run' proposal applies,
IMO.
One of the points of such release is to make it one stop shop, to
get everything up and running in one quick download.
Is 'cocoon-samples' good enough to be the one-stop-shop that you intend?
However, I would like add a big warning message, that it is not supposed to be
used as starting-point for a new Cocoon project.
So let me ask again: Do we need third-party libraries in 1. and 2. or not? (For
3. and 4. it's clear to me because they wouldn't be useable otherwise.)
WDYT?
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Normal release artifacts
David Crossley wrote:
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Reinhard Poetz wrote:
Finally, if we decide to ship 3rd party libs, one technical question:
Am I right that there is no automatic mechanism for Ant or Maven
that pulls together all license information of all 3rd-party libs?
That would be good. At Forrest, we have similar issues
not yet solved.
Is anybody aware of some code that helps in the ASF? Where could I ask such a
question? Is 'community@' the right forum?
And, if we decide to not ship 3rd party libs, am I right that we
don't have to add license files of them? (Otherwise all artifacts
on the central Maven repository would be legally broken ...)
Any comments?
Perhaps legal-discuss@ list can help.
ok, will do so?
Anyone?
If I don't hear anything I will *not* include any third-party stuff
(the only exception will be the getting-started stuff).
Users will have to download all libraries themselves.
IMHO what's good a downloadable release if 'cocoon.sh run' does not
work? One of the points of such release is to make it one stop shop,
to get everything up and running in one quick download. May be it's
just me. Shrug.
What does the getting-started stuff include?
Perhaps we include the bare minimum and list
exactly the other supporting products that they
need to go further.
yes, I intend to write a 'getting-started guide' for non-Maven 2 users.
Any supporting products that we do bundle,
need their source too.
right
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: [GSoC_2008] Project ideas
Yesterday I was introduced to an Austrian student who would be interested in working on a GSoC for the Cocoon project this year. The best idea we've had so far was was an upgrade of cForms to Dojo 1.x (or replacing it with something else if that is what the community is interested in). Yes that is a good one. +1 +1 for Dojo 1.x in CForms. best regards, gabriel
Re: [2.2] A simple CForms example doesn't work...
Grzegorz Kossakowski wrote: Luca Morandini pisze: Done: do you mind checking it and, in case, put it LIVE ? I've checked your changes and had to add some more because you missed some resource:// replacements with servlet:/. It's been put live now. It is only me, or the page has not been updated yet (cache issue ?) ? http://cocoon.apache.org/2.2/blocks/forms/1.0/478_1_1.html Reagrds, Luca Morandini www.lucamorandini.it
Re: Micro-Cocoon ... Corona
Grzegorz Kossakowski wrote: Reinhard Poetz pisze: Grzegorz Kossakowski wrote: Agreed. What about officially announcing our effort at main site with simple manifesto? I have a feeling that we agree on fundamental goals so writing such a document shouldn't be a problem, right? I plan to write a blog entry about it so that the information gets spread to a wider audiance. For a public announcement it's too early, especially so close before we release 2.2. Thanks Reinhard and Sylvain for reminding me rules and best-practices to be applied in such situations. The main thing is that we can only promote to users, stuff that we have released. I agree that it's better to spread by using blogosphere and personal contacts. My main intention was to bring here old committers and people trying to do more or less the same[1]. Grek also was seeking to clarify the goals of such efforts. We could have a developers' area of the website, or use the Cocoon Wiki, or just a README in the source. Label it as intended for developers. -David
