Peter Hunsberger wrote:
On Thu, Mar 6, 2008 at 7:58 AM, Reinhard Poetz <[EMAIL PROTECTED]> wrote:
It's time to release Cocoon 2.2, finally!
Good news indeed.
We have been working on it for years
and I think it's time to ship the *final* release. I want to do this in three
phases:
1) During the first phase I will release our two sub-projects "Cocoon
Configuration" and "Cocoon Servlet-Service-Framework". This time I will create
the Maven 2 release artifacts and "normal" zip/tar release artifacts for
non-Maven users.
Can you explain exactly what the difference is between these?
The Maven release artifacts are those files deployed to repo1.maven.org, see
http://repo1.maven.org/maven2/org/apache/cocoon/cocoon-apples-impl/1.0.0-RC2/
for example.
A normal release artifact is a zip/tar archive that contains the sources, the
packaged binaries, the javadocs and the user documention.
I think that I will be able to finish it by the end of next week.
2) The second phase is Cocoon Core and all the blocks that were released as
release candidates.
Can you explain how this differs from the first two? I think I know, but..
Cocoon Configuration and Cocoon Servlet-Service-Framework are supposed to run
independently from Cocoon Core. We use them as the fundament for Cocoon Core 2.2.
Additionally I want to release the Cocoon Maven plugin
(milestone 2), the Cocoon integration test framework (milestone 1), our
archetypes and a starter package for non-Maven users.
Again, this time I will create "normal" zip/tar release artifacts, except those
cases where it doesn't make sense (e.g. the Maven plugin, the POM artifacts and
the archetypes).
I think that I will manage to finish this work by the end of March.
Guess the biggest question is what will the minimal package be to get started?
My idea was a block, a webapp and a minimal Ant script that builds both and runs
them. That's probably not good enough for an agile development process (-> you
have to redeploy all the time ...) but gives enough ideas to people who want to
integrate Cocoon 2.2 into their own web applications.
3) The third phase is releasing our samples. It would be great if somebody else
could help out with this task because I don't know if I will have the necessary
cycles anytime soon. I guess that there is some work left in order to get this
done and there are a couple of things to be discuessed before:
We'll need to package up our own code to drop into the base but really
we wouldn't need the samples for any other reason than to get ides on
the best way to do this....
yes, and since creating seperate packages for all our sample blocks is an aweful
lot of work, I don't think that this would be a good solution.
. What do we want to ship? A WAR file only, or a WAR file + a pre-configured
Jetty packaged as ZIP, etc?
Are the above "release" artifacts separate downloads?
yes, that would be my suggestion.
I think I'd
like to see the basic minimal WAR for people who need nothing else
the _blank_ Cocoon is the "starter package" from above. Maybe we should create a
blank web application that uses Cocoon in "legacy mode" without blocks at all.
and
a complete Zip of everything you could possibly want for those who
don't want to do multiple downloads.
Do you propose some kind of "super download" that contains core, all released
blocks and the subprojects?
. Do we ship snapshots of our blocks and samples? Or the released blocks and
the snapshots of the samples? Or do we want to release our samples
offically?
. Are there any open legal issues? (e.g. we have to make sure that all the
licenses of 3-party libs are added, etc.)
. Or, should we only provide nightly snapshots of our samples? (though we
would
still have to check what this means legally for us ...)
. etc.
Ideally I'd love to see each sample as a separate download complete
with some way of tracking version updates, but initially I'd settle
for a single download.
hmm, maybe that might be viable when we switch to another release mode that
doesn't ship the whole Cocoon with it's dozens of release artifacts every time.
If you only release e.g. a single block it isn't so much additional work to
create a samples release artifact too.
--
Reinhard Pötz Managing 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]
_________________________________________________________________________
