You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Pötz <re...@apache.org> on 2008/08/01 11:12:16 UTC
Release subprojects
As announced some weeks ago, I want to release
. cocoon-servlet-service-impl-1.1.0
A new minor release is necessary because after some refactorings
the dependency on SourceResolve is gone.
. cocoon-jnet-1.0.0
Dynamically register URLStreamHandler factories with your JVM.
This module has been donated to Apache Commons and will be deprecated
as soon as it is officially released from there.
. cocoon-block-deployment-1.0.0
Deployment utilities for Cocoon Blocks. That's the first release as
a separate module.
. cocoon-spring-configurator-2.0.0
Block-deployment has been moved into a separate module. This requires
a major release of this module because an upgrade of an application
that relies on this feature requires more than replacing the library.
If I have some more time, I will also release cocoon-it-fw-1.0.0. It has
proven to be very useful.
Is there anything left to do before I can create the release artifacts?
--
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 reinhard@apache.org
________________________________________________________________________
Re: Release subprojects
Posted by Reinhard Pötz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Pötz pisze:
>> Grzegorz Kossakowski wrote:
>>> Reinhard Pötz pisze:
>>>>
>>>> As announced some weeks ago, I want to release
>>>>
>>>> . cocoon-servlet-service-impl-1.1.0
>>>> A new minor release is necessary because after some refactorings
>>>> the dependency on SourceResolve is gone.
>>>
>>> I thought that both SSF and Configurator are not back-compatible. Am
>>> I wrong?
>>
>> Here is the relevant change of
>> ServletServiceContext#getResource(String path)
>>
>> old implementation:
>> -------------------
>>
>> 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);
>> }
>>
>> new implementation:
>> -------------------
>>
>> public URL getResource(String path) throws MalformedURLException {
>> if (path == null || !path.startsWith("/")) {
>> throw new MalformedURLException("The path must begin " +
>> + "with a '/' and is interpreted "
>> + "as relative to the current context root.");
>> }
>>
>> // lazy initialization of the base URL
>> synchronized (this) {
>> if (this.contextPathURL == null) {
>> this.contextPathURL = new URL(this.contextPath);
>> }
>> }
>>
>> return new URL(this.contextPathURL, path.substring(1));
>> }
>>
>> The problem with the old SSF was that it _only_ worked, if it was used
>> together with Cocoon 2.2. After this change the SSF completely relies
>> on the standard URL handling and can really be used now in every
>> environment and not only together with Cocoon 2.2.
>
> Yes, as we can see in the old implementation SSF depended on
> SourceResolver for which the only implementation is the
> CocoonSourceResolver. That means basically, that SSF had a hidden
> dependency on cocoon-core.
>
>> This requires some changes in Cocoon (-> use JNet to resolve
>> blockcontext:/ URLs) but since we can be sure that nobody else than
>> Cocoon 2.2 was able to use the SSF 1.0, I think that a release of 1.1
>> is appropriate in this case.
>
> Isn't it that SSF depends now on JNet?
If you want to support other protocols than those that are supported by
the JVM you have to register them. JNet is one possibility.
> Even if there is a new dependency I would go with 1.1 version. We are
> not really breaking any kind of back-compatibility as there was hardly a
> defined contract that we are breaking. It's more that now we introduce
> one which deserves minor release.
Ok, then we agree on this :-)
>
>>> I've just committed missing entry describing ResourceFilter feature
>>> I've introduced. The missing items are:
>>> 1. Migration document that describes briefly how to migrate to 2.0.0
>>> of Configurator.
>>> 2. Documentation of ResourceFilter.
>>>
>>> Even if both of them are not blockers it would be nice if you could
>>> prepare migration document and I'll take care of the second one. If
>>> you are really busy, then I could write this migration document but
>>> that would involve some research on what back-incompatibilities have
>>> been introduced.
>>
>> I can't promise too much but I will see what I can do.
>
> Ok. Don't forget to change version of Xml Schema for Spring Configurator
> to 2.0.
thanks for the reminder!
>>> In short: go ahead and thanks! :)
>>
>> I will create the release artifacts tomorrow or on Tuesday.
>
> Great. Now I should follow with mine releases...
:-)
--
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 reinhard@apache.org
________________________________________________________________________
Re: Release subprojects
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Reinhard Pötz pisze:
> Grzegorz Kossakowski wrote:
>> Reinhard Pötz pisze:
>>>
>>> As announced some weeks ago, I want to release
>>>
>>> . cocoon-servlet-service-impl-1.1.0
>>> A new minor release is necessary because after some refactorings
>>> the dependency on SourceResolve is gone.
>>
>> I thought that both SSF and Configurator are not back-compatible. Am I
>> wrong?
>
> Here is the relevant change of ServletServiceContext#getResource(String
> path)
>
> old implementation:
> -------------------
>
> 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);
> }
>
> new implementation:
> -------------------
>
> public URL getResource(String path) throws MalformedURLException {
> if (path == null || !path.startsWith("/")) {
> throw new MalformedURLException("The path must begin " +
> + "with a '/' and is interpreted "
> + "as relative to the current context root.");
> }
>
> // lazy initialization of the base URL
> synchronized (this) {
> if (this.contextPathURL == null) {
> this.contextPathURL = new URL(this.contextPath);
> }
> }
>
> return new URL(this.contextPathURL, path.substring(1));
> }
>
> The problem with the old SSF was that it _only_ worked, if it was used
> together with Cocoon 2.2. After this change the SSF completely relies on
> the standard URL handling and can really be used now in every
> environment and not only together with Cocoon 2.2.
Yes, as we can see in the old implementation SSF depended on SourceResolver for which the only
implementation is the CocoonSourceResolver. That means basically, that SSF had a hidden dependency
on cocoon-core.
> This requires some changes in Cocoon (-> use JNet to resolve
> blockcontext:/ URLs) but since we can be sure that nobody else than
> Cocoon 2.2 was able to use the SSF 1.0, I think that a release of 1.1 is
> appropriate in this case.
Isn't it that SSF depends now on JNet?
Even if there is a new dependency I would go with 1.1 version. We are not really breaking any kind
of back-compatibility as there was hardly a defined contract that we are breaking. It's more that
now we introduce one which deserves minor release.
>> I've just committed missing entry describing ResourceFilter feature
>> I've introduced. The missing items are:
>> 1. Migration document that describes briefly how to migrate to 2.0.0
>> of Configurator.
>> 2. Documentation of ResourceFilter.
>>
>> Even if both of them are not blockers it would be nice if you could
>> prepare migration document and I'll take care of the second one. If
>> you are really busy, then I could write this migration document but
>> that would involve some research on what back-incompatibilities have
>> been introduced.
>
> I can't promise too much but I will see what I can do.
Ok. Don't forget to change version of Xml Schema for Spring Configurator to 2.0.
>> In short: go ahead and thanks! :)
>
> I will create the release artifacts tomorrow or on Tuesday.
Great. Now I should follow with mine releases...
--
Grzegorz Kossakowski
Re: Release subprojects
Posted by Reinhard Pötz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Pötz pisze:
>>
>> As announced some weeks ago, I want to release
>>
>> . cocoon-servlet-service-impl-1.1.0
>> A new minor release is necessary because after some refactorings
>> the dependency on SourceResolve is gone.
>
> I thought that both SSF and Configurator are not back-compatible. Am I
> wrong?
Here is the relevant change of ServletServiceContext#getResource(String
path)
old implementation:
-------------------
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);
}
new implementation:
-------------------
public URL getResource(String path) throws MalformedURLException {
if (path == null || !path.startsWith("/")) {
throw new MalformedURLException("The path must begin " +
+ "with a '/' and is interpreted "
+ "as relative to the current context root.");
}
// lazy initialization of the base URL
synchronized (this) {
if (this.contextPathURL == null) {
this.contextPathURL = new URL(this.contextPath);
}
}
return new URL(this.contextPathURL, path.substring(1));
}
The problem with the old SSF was that it _only_ worked, if it was used
together with Cocoon 2.2. After this change the SSF completely relies on
the standard URL handling and can really be used now in every
environment and not only together with Cocoon 2.2.
This requires some changes in Cocoon (-> use JNet to resolve
blockcontext:/ URLs) but since we can be sure that nobody else than
Cocoon 2.2 was able to use the SSF 1.0, I think that a release of 1.1 is
appropriate in this case.
>> . cocoon-jnet-1.0.0
>> Dynamically register URLStreamHandler factories with your JVM.
>> This module has been donated to Apache Commons and will be deprecated
>> as soon as it is officially released from there.
>
> Didn't know that there is some progress on this idea. Thanks for taking
> care of it!
I will synchronize our refactorings of JNet with the code in Apache
Commons - I hope that somebody else has some time to cut the actual release.
>> . cocoon-block-deployment-1.0.0
>> Deployment utilities for Cocoon Blocks. That's the first release as
>> a separate module.
>
> I guess one will have to add this dependency manually if sticks to
> Cocoon Core 2.2.0, right?
yes
>
>> . cocoon-spring-configurator-2.0.0
>> Block-deployment has been moved into a separate module. This requires
>> a major release of this module because an upgrade of an application
>> that relies on this feature requires more than replacing the library.
>>
>> If I have some more time, I will also release cocoon-it-fw-1.0.0. It
>> has proven to be very useful.
>
> Makes sense, it might be useful not only in Cocoon.
yes, definitely. I use it in all web projects, not only in my Cocoon
based ones.
>> Is there anything left to do before I can create the release artifacts?
>>
>
> I've just committed missing entry describing ResourceFilter feature I've
> introduced. The missing items are:
> 1. Migration document that describes briefly how to migrate to 2.0.0 of
> Configurator.
> 2. Documentation of ResourceFilter.
>
> Even if both of them are not blockers it would be nice if you could
> prepare migration document and I'll take care of the second one. If you
> are really busy, then I could write this migration document but that
> would involve some research on what back-incompatibilities have been
> introduced.
I can't promise too much but I will see what I can do.
> In short: go ahead and thanks! :)
I will create the release artifacts tomorrow or on Tuesday.
--
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 reinhard@apache.org
________________________________________________________________________
Re: Release subprojects
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Reinhard Pötz pisze:
>
> As announced some weeks ago, I want to release
>
> . cocoon-servlet-service-impl-1.1.0
> A new minor release is necessary because after some refactorings
> the dependency on SourceResolve is gone.
I thought that both SSF and Configurator are not back-compatible. Am I wrong?
> . cocoon-jnet-1.0.0
> Dynamically register URLStreamHandler factories with your JVM.
> This module has been donated to Apache Commons and will be deprecated
> as soon as it is officially released from there.
Didn't know that there is some progress on this idea. Thanks for taking care of it!
> . cocoon-block-deployment-1.0.0
> Deployment utilities for Cocoon Blocks. That's the first release as
> a separate module.
I guess one will have to add this dependency manually if sticks to Cocoon Core 2.2.0, right?
> . cocoon-spring-configurator-2.0.0
> Block-deployment has been moved into a separate module. This requires
> a major release of this module because an upgrade of an application
> that relies on this feature requires more than replacing the library.
>
> If I have some more time, I will also release cocoon-it-fw-1.0.0. It has
> proven to be very useful.
Makes sense, it might be useful not only in Cocoon.
> Is there anything left to do before I can create the release artifacts?
>
I've just committed missing entry describing ResourceFilter feature I've introduced. The missing
items are:
1. Migration document that describes briefly how to migrate to 2.0.0 of Configurator.
2. Documentation of ResourceFilter.
Even if both of them are not blockers it would be nice if you could prepare migration document and
I'll take care of the second one. If you are really busy, then I could write this migration document
but that would involve some research on what back-incompatibilities have been introduced.
In short: go ahead and thanks! :)
--
Grzegorz Kossakowski