Re: Releasing Cocoon 2.2, finally!
Reinhard Poetz wrote: It's time to release Cocoon 2.2, finally! 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 to your release plan. 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. I think that I will be able to finish it by the end of next week. Sorry that i am late. Just back from holidays. I will do a license header check of those bits. -David
Re: Releasing Cocoon 2.2, finally!
David Crossley wrote:
Reinhard Poetz wrote:
It's time to release Cocoon 2.2, finally! 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 to your release plan.
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.
I think that I will be able to finish it by the end of next week.
Sorry that i am late. Just back from holidays.
I will do a license header check of those bits.
great to hear. Since Grek indicated that he will have a look into fixing the
problem with setting the status-code this weekend, I will wait with the creation
of the release artifacts and do it some time next week.
--
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: Releasing Cocoon 2.2, finally!
Reinhard Poetz pisze: great to hear. Since Grek indicated that he will have a look into fixing the problem with setting the status-code this weekend, I will wait with the creation of the release artifacts and do it some time next week. Yep, I'll start today's late evening. Some testing done by others will be needed. -- Grzegorz Kossakowski
Re: Releasing Cocoon 2.2, finally!
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
great to hear. Since Grek indicated that he will have a look into fixing
the problem with setting the status-code this weekend, I will wait with
the creation of the release artifacts and do it some time next week.
Yep, I'll start today's late evening. Some testing done by others will be
needed.
sure, I will do so.
--
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: Releasing Cocoon 2.2, finally!
Grzegorz Kossakowski pisze: Reinhard Poetz pisze: It's time to release Cocoon 2.2, finally! 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. I think that I will be able to finish it by the end of next week. There is a subtle problem I discovered few days ago but I haven't reported up to date because I hadn't enough free time to confirm if this problem really exist. Anyway, I think that cocoon-servlet-service-impl is not really Cocoon-independent because of this line: resolver = (SourceResolver) factory.getBean(SourceResolver.ROLE); of getResource() method from ServletServiceContext class. The problem I can see here is that if cocoon-servlet-service-impl is used outside the Cocoon there is no default implementation of SourceResolver registered as a Spring bean. It's not a big deal, because Excalibur provides such implementation but we would need to figure out how to register and properly set up this component. Actually, I see whole getResource() method flawed because it calculates contextPath when used first time and I think this code should belong to the setup (not runtime) phase of ServletServiceContext. I already tried to move this code (I paste the patch at the end of this e-mail) but stumbled across some NPEs for specific servlet bean configurations and I haven't had enough free time to dig into this. I planned to take care of it during upcoming weekend because I finally get done with all these exams at my university. The root motivation for me taking a look at this code was some experimentation with Micro Cocoon. Specifically, I tried to make CocoonSourceResolver casual Spring bean and due to flawed contextPath initialization I ran into cyclic dependency chain. To be honest, I don't have an idea if we should consider this a blocker. I lean towards not considering this a blocker but once we sort this out we will need to release 1.1.0 version of cocoon-servlet-service-impl. If I come up with the fix until Monday, do you think it's a good idea to commit it just before final release? (I think it shouldn't harm and I would give it very throughout testing) Since I got no feedback I decided to commit my changes. I gave it quite detailed testing and I don't think it may break anything. Anyway, if you have spare cycles, it would be great if you could test if everything still works ok. -- Grzegorz Kossakowski
Releasing Cocoon 2.2, finally!
It's time to release Cocoon 2.2, finally! 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.
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. 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.
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:
. What do we want to ship? A WAR file only, or a WAR file + a pre-configured
Jetty packaged as ZIP, etc?
. 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.
- o -
I know that there are still open isses but I don't see any blockers. Since this
will probably be the last time when our sub-projects, core and a lot of blocks
are released together, I think it will be easy to ship upgrades of one module as
soon as we have something better available without having to wait for all the
rest getting stable.
As soon as I'm ready for the actual release work, I will announce a partly code
freeze of our repository.
Any comments?
--
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: Releasing Cocoon 2.2, finally!
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? 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.. 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? 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 . 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? I think I'd like to see the basic minimal WAR for people who need nothing else and a complete Zip of everything you could possibly want for those who don't want to do multiple downloads. . 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. I know that there are still open isses but I don't see any blockers. Since this will probably be the last time when our sub-projects, core and a lot of blocks are released together, I think it will be easy to ship upgrades of one module as soon as we have something better available without having to wait for all the rest getting stable. As soon as I'm ready for the actual release work, I will announce a partly code freeze of our repository. +1 :-) -- Peter Hunsberger
Re: Releasing Cocoon 2.2, finally!
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ö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: Releasing Cocoon 2.2, finally!
Peter Hunsberger wrote:
On Thu, Mar 6, 2008 at 9:25 AM, Reinhard Poetz [EMAIL PROTECTED] wrote:
Peter Hunsberger wrote:
On Thu, Mar 6, 2008 at 7:58 AM, Reinhard Poetz [EMAIL PROTECTED] wrote:
snip/
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.
Sorry, I meant, what's the difference between Cocoon Configuration
and Cocoon Servlet-Service-Framework ?
see http://cocoon.apache.org/subprojects/
--
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: Releasing Cocoon 2.2, finally!
On Thu, Mar 6, 2008 at 9:25 AM, Reinhard Poetz [EMAIL PROTECTED] wrote: Peter Hunsberger wrote: On Thu, Mar 6, 2008 at 7:58 AM, Reinhard Poetz [EMAIL PROTECTED] wrote: snip/ 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. Sorry, I meant, what's the difference between Cocoon Configuration and Cocoon Servlet-Service-Framework ? snip/ -- Peter Hunsberger
Re: Releasing Cocoon 2.2, finally!
On Thu, Mar 6, 2008 at 9:45 AM, Reinhard Poetz [EMAIL PROTECTED] wrote: Peter Hunsberger wrote: On Thu, Mar 6, 2008 at 9:25 AM, Reinhard Poetz [EMAIL PROTECTED] wrote: Peter Hunsberger wrote: On Thu, Mar 6, 2008 at 7:58 AM, Reinhard Poetz [EMAIL PROTECTED] wrote: snip/ 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. Sorry, I meant, what's the difference between Cocoon Configuration and Cocoon Servlet-Service-Framework ? see http://cocoon.apache.org/subprojects/ Ah, ok, makes sense. Given I've seen both of these numerous times and didn't recognize the terminology I think you're going to need a very good explanation as to what they are and why you'd want to use them as part of the release announcements -- Peter Hunsberger
Re: Releasing Cocoon 2.2, finally!
Reinhard Poetz pisze: It's time to release Cocoon 2.2, finally! 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. I think that I will be able to finish it by the end of next week. There is a subtle problem I discovered few days ago but I haven't reported up to date because I hadn't enough free time to confirm if this problem really exist. Anyway, I think that cocoon-servlet-service-impl is not really Cocoon-independent because of this line: resolver = (SourceResolver) factory.getBean(SourceResolver.ROLE); of getResource() method from ServletServiceContext class. The problem I can see here is that if cocoon-servlet-service-impl is used outside the Cocoon there is no default implementation of SourceResolver registered as a Spring bean. It's not a big deal, because Excalibur provides such implementation but we would need to figure out how to register and properly set up this component. Actually, I see whole getResource() method flawed because it calculates contextPath when used first time and I think this code should belong to the setup (not runtime) phase of ServletServiceContext. I already tried to move this code (I paste the patch at the end of this e-mail) but stumbled across some NPEs for specific servlet bean configurations and I haven't had enough free time to dig into this. I planned to take care of it during upcoming weekend because I finally get done with all these exams at my university. The root motivation for me taking a look at this code was some experimentation with Micro Cocoon. Specifically, I tried to make CocoonSourceResolver casual Spring bean and due to flawed contextPath initialization I ran into cyclic dependency chain. To be honest, I don't have an idea if we should consider this a blocker. I lean towards not considering this a blocker but once we sort this out we will need to release 1.1.0 version of cocoon-servlet-service-impl. If I come up with the fix until Monday, do you think it's a good idea to commit it just before final release? (I think it shouldn't harm and I would give it very throughout testing) 2) The second phase is Cocoon Core and all the blocks that were released as release candidates. 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. 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: . What do we want to ship? A WAR file only, or a WAR file + a pre-configured Jetty packaged as ZIP, etc? . 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. - o - I know that there are still open isses but I don't see any blockers. Since this will probably be the last time when our sub-projects, core and a lot of blocks are released together, I think it will be easy to ship upgrades of one module as soon as we have something better available without having to wait for all the rest getting stable. As soon as I'm ready for the actual release work, I will announce a partly code freeze of our repository. Any comments? The overall plan looks very, very good. I regret that I brought bad news... -- Best regards, Grzegorz Kossakowski (being very sad because of failed Algebra exam...)
Re: Releasing Cocoon 2.2, finally!
Grzegorz Kossakowski pisze:
There is a subtle problem I discovered few days ago but I haven't reported up
to date because I
hadn't enough free time to confirm if this problem really exist. Anyway, I
think that
cocoon-servlet-service-impl is not really Cocoon-independent because of this
line:
resolver = (SourceResolver) factory.getBean(SourceResolver.ROLE);
of getResource() method from ServletServiceContext class. The problem I can
see here is that if
cocoon-servlet-service-impl is used outside the Cocoon there is no default
implementation of
SourceResolver registered as a Spring bean. It's not a big deal, because
Excalibur provides such
implementation but we would need to figure out how to register and properly
set up this component.
Actually, I see whole getResource() method flawed because it calculates
contextPath when used first
time and I think this code should belong to the setup (not runtime) phase of
ServletServiceContext.
I already tried to move this code (I paste the patch at the end of this
e-mail) but stumbled across
some NPEs for specific servlet bean configurations and I haven't had enough
free time to dig into
this.
Of course forgot to paste a patch:
diff --git
a/core/cocoon-servlet-service/cocoon-servlet-service-impl/src/main/java/org/apache/cocoon/servletservice/ServletServiceContext.java
b/core/cocoon-servlet-service/cocoon-servlet-service-impl/src/main/java/org/apache/cocoon/servletservice/ServletServiceContext.java
index ca07fbd..eabc5ce 100644
---
a/core/cocoon-servlet-service/cocoon-servlet-service-impl/src/main/java/org/apache/cocoon/servletservice/ServletServiceContext.java
+++
b/core/cocoon-servlet-service/cocoon-servlet-service-impl/src/main/java/org/apache/cocoon/servletservice/ServletServiceContext.java
@@ -102,36 +102,11 @@ public class ServletServiceContext extends
ServletContextWrapper implements Abso
}
public URL getResource(String path) throws MalformedURLException {
-// hack for getting a file protocol or other protocols that can be
used as context
-// path in the getResource method in the servlet context
-if (!(contextPath.startsWith(file:) || contextPath.startsWith(/)
- || contextPath.indexOf(':') == -1)) {
-SourceResolver resolver = null;
-Source source = null;
-try {
-BeanFactory factory =
WebApplicationContextUtils.getRequiredWebApplicationContext(this);
-resolver = (SourceResolver)
factory.getBean(SourceResolver.ROLE);
-source = resolver.resolveURI(contextPath);
-contextPath = source.getURI();
-} catch (IOException e) {
-throw new MalformedURLException(Could not resolve +
contextPath + due to + e);
-} finally {
-if (resolver != null) {
-resolver.release(source);
-}
-}
-}
-
// HACK: allow file:/ URLs for reloading of sitemaps during development
if (this.contextPath.startsWith(file:)) {
return new URL(file, null,
this.contextPath.substring(file:.length()) + path);
}
-if (this.contextPath.length() != 0 this.contextPath.charAt(0) !=
'/') {
-throw new MalformedURLException(The contextPath must be empty or
start with '/' +
-this.contextPath);
-}
-
// prefix the path with the servlet context resolve and resolve in the
embedding
// servlet context
return super.getResource(this.contextPath + path);
diff --git
a/core/cocoon-servlet-service/cocoon-servlet-service-impl/src/main/java/org/apache/cocoon/servletservice/spring/ServletFactoryBean.java
b/core/cocoon-servlet-service/cocoon-servlet-service-impl/src/main/java/org/apache/cocoon/servletservice/spring/ServletFactoryBean.java
index 74615b1..eb6e099 100644
---
a/core/cocoon-servlet-service/cocoon-servlet-service-impl/src/main/java/org/apache/cocoon/servletservice/spring/ServletFactoryBean.java
+++
b/core/cocoon-servlet-service/cocoon-servlet-service-impl/src/main/java/org/apache/cocoon/servletservice/spring/ServletFactoryBean.java
@@ -16,6 +16,8 @@
*/
package org.apache.cocoon.servletservice.spring;
+import java.io.IOException;
+import java.net.MalformedURLException;
import java.util.Enumeration;
import java.util.Map;
@@ -30,6 +32,8 @@ import org.aopalliance.intercept.MethodInterceptor;
import org.aopalliance.intercept.MethodInvocation;
import org.apache.cocoon.servletservice.Mountable;
import org.apache.cocoon.servletservice.ServletServiceContext;
+import org.apache.excalibur.source.Source;
+import org.apache.excalibur.source.SourceResolver;
import org.springframework.aop.framework.ProxyFactory;
import org.springframework.aop.support.DefaultIntroductionAdvisor;
import org.springframework.aop.support.DelegatingIntroductionInterceptor;
@@ -76,7 +80,6 @@ public
