Re: [DISCUSS] Release plan
On 11/18/2012 11:40 AM, Robby Pelssers wrote: Hi, Did anyone read any of these OSGI books by any chance? http://www.manning.com/hall/ http://www.manning.com/cummins/ http://www.manning.com/alves/ I am interested in buying one of these to get more acquainted and perhaps help out in the future. I don't know if another alternative is helpful to you but in the case, I recently came across OSGi Starter (http://www.packtpub.com/open-services-gateway-initiative-starter/book). -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [DISCUSS] Release plan
On 11/12/2012 10:25 AM, Francesco Chicchiriccò wrote: Finally, we have some outstanding proposals for improving the pipeline APIs from Simone [4] and Reinhard [5]: I'd push this anyway to C3 3.1.0. No problem for me, +1 for a release. -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: BlockContextURLConnection is not context safe
On 09/19/2012 03:17 PM, Francesco Chicchiriccò wrote: Anyway, what if we try to use cocoon-jnet [2] for handling blockcontext:// ? AFAIK it is only used for servlet:// ATM. JNet was my first thought too ... -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [VOTE] Javier Puerto as cocoon committer
On 05/28/2012 10:26 AM, Thorsten Scherler wrote: Hello all, I propose Javier Puerto as a new Cocoon committer and PMC member. I am working with Javier since over 5 years now in different teams for different clients. Our projects include all version of cocoon and he contributed many qualified patches over the years. He is an ASF committer in Apache Droids and I think he would make a great addition to our team. He contributes now on a regular base and lately as well started to dig into many issues that are critical for the c3 release. That shows that his interest in Cocoon is longer-term. This vote ends one week from today, i.e. midnight UTC on Sunday 2012-06-04 Please cast your votes. +1 welcome! -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [C3] Time to define a roadmap
On 05/21/2012 08:58 AM, Francesco Chicchiriccò wrote: On 20/05/2012 16:54, Reinhard Pötz wrote: On 05/14/2012 09:04 AM, Francesco Chicchiriccò wrote: Hi all, it's been quite a while since our latest C3 release (July 1st, 2011) [1]; even though I personally believe we should at least fix some aspects before cutting next release, I also think it would be nice to provide a roadmap for all people - including me - that are already using C3 on some of their own projects. Hence: 1. what will we include in beta-1? Is JIRA updated in this respect [2]? There are quite some other unplanned issues [3]. 2. what will we plan after beta-1? beta-2? and afterwards? 3. do we want to consider some milestone release (M1 / M2 / ...) instead, maybe even BEFORE beta-1, so that we can provide some stable reference for external project relying upon C3? IMO the most important missing thing before going beta is supporting alternative output types than OutputStream and to get rid of throws Exception which is actually of no value. The latter is rather simple to achieve, the first change needs (a lot of) more work, especially regarding caching. Steven and I have started to work on a proposal for dynamic output types but we haven't had enough time yet to commit it to the whiteboard and write a proposal email. Reinhard, I see your point: do you think it would be possible to release something like a milestone in the meanwhile? We would be able, in this way, to either not yet fall into beta and to provide C3 users out there with a rather stable reference for their projects. Yes, the milestone / release candidate scheme has worked very well for us in the past and is currently also used by e.g. Eclipse, Spring or Wicket. Many users should be familiar with that. -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [C3] Time to define a roadmap
On 05/14/2012 09:04 AM, Francesco Chicchiriccò wrote: Hi all, it's been quite a while since our latest C3 release (July 1st, 2011) [1]; even though I personally believe we should at least fix some aspects before cutting next release, I also think it would be nice to provide a roadmap for all people - including me - that are already using C3 on some of their own projects. Hence: 1. what will we include in beta-1? Is JIRA updated in this respect [2]? There are quite some other unplanned issues [3]. 2. what will we plan after beta-1? beta-2? and afterwards? 3. do we want to consider some milestone release (M1 / M2 / ...) instead, maybe even BEFORE beta-1, so that we can provide some stable reference for external project relying upon C3? IMO the most important missing thing before going beta is supporting alternative output types than OutputStream and to get rid of throws Exception which is actually of no value. The latter is rather simple to achieve, the first change needs (a lot of) more work, especially regarding caching. Steven and I have started to work on a proposal for dynamic output types but we haven't had enough time yet to commit it to the whiteboard and write a proposal email. -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [DISCUSS] Moving subprojects tools under /
On 04/09/2012 11:23 AM, Francesco Chicchiriccò wrote: HI all, a while ago [1] we discussed (and almost agreed) a new structure for our SVN, even though we haven't yet been able to agree on a schedule for performing all related activities. A part of [1] was about moving some modules, used by both C2.2 and C3, to an independent place. Recently I also proposed to apply some pending changes to some of such modules (cocoon-xml, cocoon-servlet-service, ...). Hence, I would like to move modules under [2], [3] and [4] under a new directory [5], create separate trunk, branches and tags subdirs, and modify POMs in order to make each module independent. Do you see any issue with this? no, looks good. -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [c3] sitemap SelectNode has no SELECT_CATEGORY, why?
On 03/23/2012 10:19 AM, Thorsten Scherler wrote: Hi all, I need the exist selector [1] in our project to use it in one general match. However I found out that SelectNode has no SELECT_CATEGORY so making it impossible to have different types of select. Is this a design decission or is just TBD? The reason had been that there was no need for it. I still think that map:select value=[expression] is powerful enough for all kind of queries. I think you only have to extend the available object model or provide an alternative expression language tailored for your use case. -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [C3] Merge parent and cocoon-docs [WAS Re: [DISCUSS] online APIs doc]
On 03/23/2012 09:12 PM, Simone Tripodi wrote: Hi Francesco, thanks a lot once again for the HARD work! I agree that this is not the nicer solution, we can do a little step better: IMHO the root parent pom has to become the parent. It allows listing all the modules just once and we can simplify the structure, see Apache Any23 or Apache Amber or Apache DirectMemory. thoughts? The original structure of our Maven build system was often influcenced by some Maven limitations (or bugs) that once existed but have either been fixed or mitigated in the meantime. So go ahead with your improvements! -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [c3] Action how to configure them from the sitemap
On 03/23/2012 12:16 PM, Thorsten Scherler wrote:
Hi all,
I was trying to use an action instead of a selector, but now I find that
actions are not providing setConfiguration. Meaning I cannot do
map:act type=exists src=resources/screens/{map:../2}.xml
map:parameter name=src value=resources/screens/{map:../2}.xml /
map:parameter name=isUser value={shiro:authenticated} /
/map:act
The first @src is ignored and the map:parameter approach is neither
working since setConfiguration are not called on actions.
So now my question is how am I suppossed to pass parameters from the
sitemap to the action?
When we started to work on Cocoon 3 we were not sure whether we should
migrate actions at all since they are often used to introduce some side
effects or to implement logic that should actually become a matcher or
to work around some other limitations that should be solved differently.
Hence I guess
setConfiguration(MapString, ? extends Object configuration)
is missing because nobody has needed it yet.
--
Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch
http://www.indoqa.com/people/reinhard-poetz.html
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
Furthermore, I think Oracle has to honor the JSPA agreement.
http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: cocoon-spring-configurator issue
On 02/28/2012 09:59 PM, Leszek Gawron wrote:
Hello,
I tried to upgrade my cocoon based product to use spring 3.0 new
features. One of those is @Value(${propertyName}) annotation.
This feature works for context:property-placeholder/ but does not for
cocoon's configurator:settings/. This is slightly weird as coocon
configurator theoreticaly bases on PropertyPlaceholderConfigurer.
The issue lies in this code (I used :
cocoon-spring-configurator-1.0.2\src\main\java\org\apache\cocoon\spring\configurator\impl\AbstractSettingsBeanFactoryPostProcessor.java
/**
* @see
org.springframework.beans.factory.config.PropertyPlaceholderConfigurer#processProperties(org.springframework.beans.factory.config.ConfigurableListableBeanFactory,
java.util.Properties)
*/
protected void processProperties(ConfigurableListableBeanFactory
beanFactoryToProcess,
Properties props)
throws BeansException {
final BeanDefinitionVisitor visitor = new
CocoonSettingsResolvingBeanDefinitionVisitor(this.settings);
String[] beanNames = beanFactoryToProcess.getBeanDefinitionNames();
for (int i = 0; i beanNames.length; i++) {
BeanDefinition bd = beanFactoryToProcess.getBeanDefinition(beanNames[i]);
try {
visitor.visitBeanDefinition(bd);
} catch (BeanDefinitionStoreException e) {
throw new BeanDefinitionStoreException(bd.getResourceDescription(),
beanNames[i], e);
}
}
}
protected class CocoonSettingsResolvingBeanDefinitionVisitor extends
BeanDefinitionVisitor {
protected final Properties props;
protected final Set visitedPlaceholders = new HashSet();
public CocoonSettingsResolvingBeanDefinitionVisitor( Settings settings
) {
this.props = new SettingsProperties( settings );
}
protected String resolveStringValue( String strVal ) {
return parseStringValue( strVal,
this.props,
visitedPlaceholders );
}
}
This method completely rewrites the super method (from
PropertyPlaceholderConfigurer) which looks like this:
@Override
protected void processProperties(ConfigurableListableBeanFactory
beanFactoryToProcess, Properties props)
throws BeansException {
StringValueResolver valueResolver = new
PlaceholderResolvingStringValueResolver(props);
BeanDefinitionVisitor visitor = new BeanDefinitionVisitor(valueResolver);
String[] beanNames = beanFactoryToProcess.getBeanDefinitionNames();
for (String curName : beanNames) {
// Check that we're not parsing our own bean definition,
// to avoid failing on unresolvable placeholders in properties file
locations.
if (!(curName.equals(this.beanName)
beanFactoryToProcess.equals(this.beanFactory))) {
BeanDefinition bd = beanFactoryToProcess.getBeanDefinition(curName);
try {
visitor.visitBeanDefinition(bd);
}
catch (Exception ex) {
throw new BeanDefinitionStoreException(bd.getResourceDescription(),
curName, ex.getMessage());
}
}
}
// New in Spring 2.5: resolve placeholders in alias target names and
aliases as well.
beanFactoryToProcess.resolveAliases(valueResolver);
// New in Spring 3.0: resolve placeholders in embedded values such as
annotation attributes.
beanFactoryToProcess.addEmbeddedValueResolver(valueResolver);
}
As you see new features completely got disabled.
What I actually did was the easiest solution of all:
/**
* @see
org.springframework.beans.factory.config.PropertyPlaceholderConfigurer#processProperties(org.springframework.beans.factory.config.ConfigurableListableBeanFactory,
* java.util.Properties)
*/
protected void processProperties( ConfigurableListableBeanFactory
beanFactoryToProcess, Properties props ) throws BeansException {
super.processProperties( beanFactoryToProcess,
new SettingsProperties( this.settings ) );
}
and @Value works as expected. Still I am not aware if the original
solution was a mistake or was thought out for some other use case.
If noone objects I'd like to commit my change.
Go ahead! I will test with our projects in order to give feedback about
unwanted side effects.
--
Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch
http://www.indoqa.com/people/reinhard-poetz.html
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
Furthermore, I think Oracle has to honor the JSPA agreement.
http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
[c3] Pipeline API refactoring
As I mentioned several times I think we should polish the pipeline API before we do our first beta release of Cocoon 3. Especially the enforced resutl type OutputStream and the exception handling need some improvements. For that purpose I created a branch c3-pipeline-api-refactoring in our whiteboard (https://svn.apache.org/repos/asf/cocoon/whiteboard/c3-pipeline-api-refactoring/) so that our discussions don't become too theoretical ;-) That branch only contains a minimum set of classes so that we see the effects of a proposed change on real code but don't have to change the whole codebase just for some examples that might be thrown away. Steven and I plan to continue our work some time next week. We will commit our changes then and explain them on the mailing list for further discussions. -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [JIRA] add more karma to Cedric and Robby
On 01/10/2012 11:17 AM, Simone Tripodi wrote: Good morning all, I'm here to kindly ask if some of us has enough powers to give more karma on JIRA to our new PMC members Cedric (cedric) and Robby (robbypelssers). I cc-ed Reinhard because he added Francesco and I so at 90% he can help us (sorry for the noise Reinhard!) Many thanks in advance, all the best! done -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [C3] cocoon-sample / cocoon-archetype-block and rcl
On 01/03/2012 10:41 AM, Francesco Chicchiriccò wrote: Hi devs, cocoon-sample and cocoon-archetype-block do use cocoon-maven-plugin to prepare and deploy a block to a local jetty, featuring some class reloading feature. It could be an idea to remove cocoon-maven-plugin and profit from class reloading features of Tomcat 7 [1] (for instance) with support of Cargo for managing and configuring Tomcat instance. We may, of course, continue (actually, start again) support for cocoon-maven-plugin. but I have more a feeling that we could better concentrate on C3 development, instead. What's the problem with the cocoon-maven-plugin? -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [C3] Error handling in REST controller
On 12/19/2011 06:47 PM, Andreas Hartmann wrote: Hi all, I just noticed that if a handler method in a RESTController throws an exception and the sitemap doesn't contain an error handler, an empty response with status code 200 is returned. IMO this is not good. I see two approaches to improve it: A) The SpringRESTController sets the status code to 500 if an exception was thrown by the controller implementation. B) The sitemap processor should catch the exception (I'm not familiar with the implementation details yet) and send an appropriate response (on a side note, it would be nice to be able to set the status-code attribute for a Reader). I have to admit that the whole concept how the REST controller in combination with the sitemap should handle the request-response cycle is a bit unclear to me. Is the REST controller always in charge of the whole request-response cycle, up to setting the response status code? Is the handle-errors element in the sitemap obsolete when the REST controller is used? IMO this would make sense, since the REST controller is much closer to the HTTP details than classic G-T-S pipelines, where more stuff happened in the sitemap (selectors for HTTP methods, serializers with status-code attributes). Anyways, there should be a clear contract between the sitemap and the REST controller, something like: * The REST controller is responsible for setting up the response, including error handling. * The handle-errors clause kicks in if an error occurs in the REST controller itself. I'm not sure if we should introduce special error handling for REST controllers. Wouldn't we have to do the same for all other sitemap components either? If the author of a sitemap decides that he doesn't want to provide proper error handling, we should catch the error in o.a.c.servlet.RequestProcessor.sendSitemapResponse() and send 500 Internal Server Error so that the status code is correct. We should also log the exception there because AFAICS this isn't done anywhere else. Additionally we can give a hint in the log files that an error has occurred but wasn't handled properly by the sitemap o.a.c.sitemap.node.PipelineNode.handleException(). -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [VOTE] Require Java 1.6 for Cocoon3
On 09/19/2011 11:03 PM, Nathaniel, Alfred wrote: Hi all, A few weeks ago we had a discussion [1] whether to increase for Cocoon3 the minimum Java version from 1.5 to 1.6. There were a number of advantages identified to be gained by using Java6, which I don’t want to repeat here, The only downside is the exclusion of potential C3 users locked in to Java5. A survey on the user list [2] asking users to step forward if that really applied to anybody did not yield any response. Therefore I’ call the vote on Code Modification [3]: +1 = Yes, Cocoon3 shall require Java 1.6 -1 = No, Cocoon3 must remain usable with Java 1.5 (with justification for the veto) This change is targeted only at Cocoon3. Cocoon2.1 and Cocoon2.2 are not affected. Please cast your votes before Mon 3 Oct 06:00 UTC. +1 -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: help needed for migrating Cocoon2.2 to Spring 3
On 09/16/2011 01:18 PM, Gabriel Gruber wrote: What I remember of one of the talks with Reinhard is that the switch to Spring 3 is actually just a problem of the RCL plugin... This problem should be fixed by the latest release of the Cocoon Maven plugin (1.0.0). -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: A couple of issues with JIRA
On 08/10/2011 10:03 AM, Francesco Chicchiriccò wrote: Hello, I think we should fix a couple of things related to Cocoon JIRA: 1. Versions At the moment [1] alpha-2 and alpha-3 are shown as unreleased and beta-1 is missing: this makes rather impossible to make good ticket assignments to versions and also to plan next releases. Who have enough rights to fix this? I have. I've just created 3.0.0-beta-1 2. Notifications Some months ago, the discussion [2] about how to re-enable this has stopped with an unanswered question: What do we have to do in order to get the notification mails back? Can we just open a ticket to the infrastructure team about this? Yes please. TIA! -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: Cocoon GetTogether?
On 08/04/2011 05:08 PM, Simone Tripodi wrote: Hi all guys and sorry for have overlooked that discussion. A GT is what I really wish see realized :) I spoke also with Francesco via chat and we both agreed/wish on give new energy to C3 promoting a GT. I tried to go to Vienna last year to meet Reinhard and Steven, but unfortunately didn't have enough budget to go (here in Italy salaries are not at EU level - unless you are a Politician :P) :( I would like - just my wish - to propose the University of L'Aquila (Italy) as next Cocoon3 GT for 2 main reason (3, since it is the city when I was born :P ): * on April 6, 2009, it was partially destroyed by a earthquake[1] and it's still in terrible conditions - so organizing a so great event would hopefully attract the interest * because of it, the University lost a lot of students, we could maybe help them attracting guys It is just a prototypal idea, I should speak with people I'm still in touch there before doing a real proposal... anyway, how does it sound? TIA, all the best!!! It would be great to have another CocoonGT in Italy. +1 from me! -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [proposal] cocoonstuff.org
On 07/19/2011 12:17 AM, Sylvain Wallez wrote: Le 18/07/11 20:56, Reinhard Pötz a écrit : On 07/13/2011 09:30 AM, Steven Dolg wrote: We should take a look at introducing topic specific modules. I fear that the optional module turns into a giant clump of all things unrelated. Generally +1 to topic specific modules. As Steven already knows from Indoqa projects, I'm a fan of many small modules ;-) In regard to the still small C3 community (not in terms of people but rather in terms of SVN changes and mailing list activity) we should think about having a Cocoon Stuff project (analogous to Wicket Stuff) where everybody that is interested gets commit rights. This also clearly indicates what we as Apache Cocoon community consider being officially maintained. (BTW, the Wicket community is very restrictive in moving code from wicketstuff.org into the wicket-core codebase because of the mentioned maintenance reasons). The wicket folks had a vote between hosting their stuff project either at Github or at Apache-Extras (powered by Google Code). Github won and the result can be found at http://wicketstuff.org/ and https://github.com/wicketstuff/core But there is also a downside: - Cocoon release will become (slightly) more work in the future because two code bases have to be released - cocoonstuff.org releases are not ASF releases and we can't rely on the ASF litigation protection mechanisms anymore (which is also true for most opensource software out there) (NB: That is the reason why we need 3 +1 votes of PMC members before we can do a release and tag it with the Apache name) - that the transition has to be done: * contact the Apache Board about reserving the cocoonstuff.org domain * decide what goes to cocoonstuff.org and what remains at cocoon.apache.org * rename all packages accordingly * create a cocoonstuff-samples module * decide whether we (the Cocoon PMC) want to enforce the AL 2.0 for all cocoonstuff modules * decide about the release voting precedure * setup a cocoonstuff.org website (if we use Github we could also use it for hosting static websites) * find out how to get the Maven artifacts deployed to the central Maven repository * find a solution for continuous integration (Jenkins) and providing snapshot releases (Nexus?) But IMO there is also an additional benefit: Creating cocoonstuff would lower the barrier for contributions and could attract more people to get involved with C3. WDOT? Hmm... I definitely agree that modules specific to a 3rd party library or a JSR that's not included in the JDK are to be packaged as separate artifacts. As Steven rightfully points out, it's a real pain to download and package a huge load of libraries you don't need. And this what has been done in Cocoon since 2.0 with the large collection of blocks. Now hosting these modules away from apache.org is a different thing that has strong implications on community dynamics. The C3 community is slowly growing after having been almost dormant for months (years?), which is a very good thing, and I fear that a cocoonstuff.org would just harm this nascent effort by splitting the still brittle community. Also, a separate environment comes with additional time spent in administrative stuff (look at your long task list!) that could probably be used more wisely to build a stable C3. So if the purpose is to lower the barrier for contribution, then why not just having a contrib directory in SVN, clearly showing that these aren't core modules, but still under the oversight of the PMC and the ASF at large? Of course, managing Git pull requests would be more convenient than applying patches in Jira, but still, at this point, this is probably easier than having a completely separate infrastructure. After reading Torsten's and your comments I agree that setting up cocoonstuff.org is too early. Nevertheless C3 already counts more than 20 subdirectories which is discouraging for people that want to get familiar with the code base. Especially if you don't need all the webapp/REST stuff you only need cocoon-pipeline, cocoon-sax, parent and maybe cocoon-optional. One could say that this problem can be solved with good documentation but the psychological barrier doesn't go away. Maybe it would be good enough to restructure the directory tree so that everybody can decide what he needs: cocoon3/trunk/pipeline . plain Java pipelines cocoon3/trunk/sitemap .. sitemap implementation (currently only the XMLSitemap impl) cocoon3/trunk/webapp ... using C3 for web applications cocoon3/trunk/[stuff]* . all additional stuff that is clearly marked as not being ready for prime time (*) needs a better name I don't know what to do with . documentation (split it into the three sections or have one central directory), . the parent POM (one for each section or one global parent POM. However, one parent POM has the disadvantage, that you couldn't
Re: Jira notifications
On 07/17/2011 06:21 PM, Jasha Joachimsthal wrote: On 15 July 2011 17:34, Reinhard Pötz reinh...@apache.org mailto:reinh...@apache.org wrote: Does anybody know why we don't see any JIRA notifications on the dev list anymore? For security reasons infra cancelled all Jira subscriptions for (public) mailing lists. They did that around Feb 16 and notified the committers about it. Ah right, remember again now. What do we have to do in order to get the notification mails back? -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
[proposal] cocoonstuff.org
On 07/13/2011 09:30 AM, Steven Dolg wrote: We should take a look at introducing topic specific modules. I fear that the optional module turns into a giant clump of all things unrelated. Generally +1 to topic specific modules. As Steven already knows from Indoqa projects, I'm a fan of many small modules ;-) In regard to the still small C3 community (not in terms of people but rather in terms of SVN changes and mailing list activity) we should think about having a Cocoon Stuff project (analogous to Wicket Stuff) where everybody that is interested gets commit rights. This also clearly indicates what we as Apache Cocoon community consider being officially maintained. (BTW, the Wicket community is very restrictive in moving code from wicketstuff.org into the wicket-core codebase because of the mentioned maintenance reasons). The wicket folks had a vote between hosting their stuff project either at Github or at Apache-Extras (powered by Google Code). Github won and the result can be found at http://wicketstuff.org/ and https://github.com/wicketstuff/core But there is also a downside: - Cocoon release will become (slightly) more work in the future because two code bases have to be released - cocoonstuff.org releases are not ASF releases and we can't rely on the ASF litigation protection mechanisms anymore (which is also true for most opensource software out there) (NB: That is the reason why we need 3 +1 votes of PMC members before we can do a release and tag it with the Apache name) - that the transition has to be done: * contact the Apache Board about reserving the cocoonstuff.org domain * decide what goes to cocoonstuff.org and what remains at cocoon.apache.org * rename all packages accordingly * create a cocoonstuff-samples module * decide whether we (the Cocoon PMC) want to enforce the AL 2.0 for all cocoonstuff modules * decide about the release voting precedure * setup a cocoonstuff.org website (if we use Github we could also use it for hosting static websites) * find out how to get the Maven artifacts deployed to the central Maven repository * find a solution for continuous integration (Jenkins) and providing snapshot releases (Nexus?) But IMO there is also an additional benefit: Creating cocoonstuff would lower the barrier for contributions and could attract more people to get involved with C3. WDOT? -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: @Logger in RestController or independent?
On 07/13/2011 08:12 PM, Thorsten Scherler wrote:
Hi all,
I developed a small @Logger annotation for a customer project which I
would like to contribute. The question is ATM what is the best way?
ATM I have implemented the annotation based on an independent
BeanPostProcessor which I then invoke with adding
!-- logger annotation implementation --
bean class=org.apache.cocoon.common.LoggerInjector/
Basically the class is doing:
if (field.getAnnotation(Logger.class) != null) {
Log log = LogFactory.getLog(bean.getClass());
field.set(bean, log);
}
I saw SpringRESTController and I wonder whether we should add it there
in getController as populateLogger(configuration, unpackedController,
annotatedFields);
or to leave it independent to allow usages as well in REST independent
components such as generators, etc.
Injection logger instances is already supported. You can use the
org.apache.cocoon.rest.controller.annotation.Inject annotation on a
field of type org.apache.commons.logging.Log.
BTW, in the beta phase we should move our codebase to slf4j ...
--
Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch
http://www.indoqa.com/people/reinhard-poetz.html
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
Furthermore, I think Oracle has to honor the JSPA agreement.
http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: question regarding the Cocoon 3 API
On 07/07/2011 12:09 PM, Robby Pelssers wrote: Hi, Are my following assumptions right? -setConfiguration is typically used when using sitemap yes -but for setup(params) method the API states that this is the shared map for all components… so it should not be called directly but it gets indirectly called when executing pipeline.setup(outputstream, params)? yes, see o.a.c.pipeline.AbstractPipeline#setupComponents If it was not intended this way, then https://issues.apache.org/jira/browse/COCOON3-68 applies. -But I still can see the need that different components need to be able to be setup with different maps of parameters. Suppose both components need a “id” parameter but for the generator this needs to be value ‘x’ and for e.g. the transformer value ‘y’. Then using a shared map will not work. If you use the Java API directly, you can pass any parameter by using the constructor or a custom setter method to your component. There should be no need to call the setup method yourself. -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Jira notifications
Does anybody know why we don't see any JIRA notifications on the dev list anymore? -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
[c3] Dependency management
On 07/02/2011 02:48 AM, thors...@apache.org wrote: Author: thorsten Date: Sat Jul 2 00:48:39 2011 New Revision: 1142134 URL: http://svn.apache.org/viewvc?rev=1142134view=rev Log: Fixing fop test which was failing because of missing class org/apache/xmlgraphics/util/uri/CommonURIResolver Modified: cocoon/cocoon3/trunk/cocoon-optional/pom.xml Modified: cocoon/cocoon3/trunk/cocoon-optional/pom.xml URL: http://svn.apache.org/viewvc/cocoon/cocoon3/trunk/cocoon-optional/pom.xml?rev=1142134r1=1142133r2=1142134view=diff == --- cocoon/cocoon3/trunk/cocoon-optional/pom.xml (original) +++ cocoon/cocoon3/trunk/cocoon-optional/pom.xml Sat Jul 2 00:48:39 2011 @@ -92,6 +92,11 @@ optionaltrue/optional /dependency dependency +groupIdorg.apache.xmlgraphics/groupId +artifactIdxmlgraphics-commons/artifactId +version1.4/version +/dependency +dependency groupIdorg.apache.cocoon/groupId artifactIdcocoon-serializers-charsets/artifactId optionaltrue/optional Please use the dependency management section of the parent POM to set version numbers so that they are the same for one artifact throughout our codebase. Thanks! -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: Improved C3 infrastructure
On 06/30/2011 05:31 PM, Francesco Chicchiriccò wrote: On 30/06/2011 17:25, Simone Tripodi wrote: Hi all guys, we now have new terrific toys available for C3 :) * Sonar - https://analysis.apache.org/dashboard/index/org.apache.cocoon.root:cocoon-root * Nexus - https://repository.apache.org/content/repositories/snapshots/org/apache/cocoon/ * Jenkins - https://builds.apache.org/job/Cocoon-trunk/ See http://www.apache.org/dev/publishing-maven-artifacts.html for more infos how to configure your settings.xml to deploy on Nexus (the Jenkins job should do it for us). I already uploaded the beta-1-snapshot just to test it. Parent POM already updated, have fun!!! Great job, Simone, well done! +1! -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [C3] Passing parameters from sitemap to generator
On 07/01/2011 10:25 AM, Francesco Chicchiriccò wrote: Hi all, recently I have been in the situation for which I need to parametrize an XML file of my application; I thought there was a simpler way but I ended up by using an additional XSLT transformation step (since the XSLTTransformer can accep parameters from the pipeline). With C2.1 I used to put in place the JXGenerator [1] (or JXTransformer [2] depending on the case): this saved me, in many cases, from an additional transformation step in the pipeline. Even though it is true that everything you could do with JXGenerator can always be done with XMLGenerator + XSLTTransformer, do you think that such component can be a nice to have in C3? So far there is only the StringTemplateGenerator component, that dynamically generates XML based on a template. There are also no 'build-in' objects like request, session, etc. which were supported by the JXGenerator or the VelocityGenerator in Cocoon 2.x I have no strong opinion on what should be migrated to C3 as long as it goes into a new module or the cocoon-optional module ;-) I suggest that you choose that technology that fits your requirements and your time constraints (VelocityGenerator should be rather straight forward, migrating JX* is definitly more-timeconsuming) best. -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Publishing the C3 javadocs
On 07/01/2011 11:26 AM, simonetrip...@apache.org wrote: Author: simonetripodi Date: Fri Jul 1 09:26:08 2011 New Revision: 1141888 URL: http://svn.apache.org/viewvc?rev=1141888view=rev Log: described how to release apidocs Modified: cocoon/cocoon3/trunk/RELEASE_HOWTO.txt Modified: cocoon/cocoon3/trunk/RELEASE_HOWTO.txt URL: http://svn.apache.org/viewvc/cocoon/cocoon3/trunk/RELEASE_HOWTO.txt?rev=1141888r1=1141887r2=1141888view=diff == --- cocoon/cocoon3/trunk/RELEASE_HOWTO.txt (original) +++ cocoon/cocoon3/trunk/RELEASE_HOWTO.txt Fri Jul 1 09:26:08 2011 @@ -1,8 +1,6 @@ HOWTO RELEASE COCOON 3: Preparations -Note: The Cocoon release process still uploads the artifacts to people.apache.org:/x1/www/people.apache.org/builds/cocoon/ This should be changed to use the Apache Nexus installation - * check your workstation's settings as described at http://cocoon.apache.org/1199_1_1.html (step 1) * update src/main/changes/changes.xml and src/main/site/apt/download.apt in the 'cocoon-docs' module @@ -62,11 +60,19 @@ HOWTO RELEASE COCOON 3: After a successf and call 'svn up'. - -* update the website * upload the Javadocs + That's a manual operation, once created the release package, compress the + + cocoon-all/target/apidocs + + Then upload the compressed file on p.a.o: + +scp apidocs.zip asfusername@p.a.o:/x1/www/cocoon.apache.org/3.0 + + Then login on remote machine and decompress + FYI: The javadocs are also added to the distribution artifacts and automatically contain the correct version number. -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [C3] Cocoon Spring Configurator, sitemap reload and exception unroll
On 06/28/2011 10:29 AM, Francesco Chicchiriccò wrote: Gents, Cocoon 3 is using Cocoon Spring Configurator 2.1[1]; by default this is triggered by an empty configurator:settings/ in main applicationContext.xml. In my project I need to: 1. always reload sitemap.xmap from the filesystem during development Am I right that you use C3 within a Wicket application and can't use the default reloading classloader stuff based on the Cocoon Maven Plugin (mvn cocoon:prepare)? 2. catch the real cause of a ProcessingException (I was inspired by [2]) yes, makes sense. Hence I set something like as configurator:settings configurator:property name=org.apache.cocoon.reloading.sitemap value=true/ configurator:property name=org.apache.cocoon.exception.ProcessingException.unroll value=true/ /configurator:settings Then, I modified [3] and [4] in order to handle this kind of configuration: the patch is attached to this e-mail. Do you think this could be useful in general? If so I would commit gladly. If my C3 within Wicket assumption is right, I'm fine with your suggestions. -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [C3] Spring 3
On 06/28/2011 10:38 AM, Francesco Chicchiriccò wrote: Hi all, in my project's pom.xml I am using without any issue the latest stable version of Spring 3 (3.0.5) with cocoon3 artifacts. I would like to upgrade the current 2.5.6 to 3.0.5 in all the source code: do you see any particular issue? No, I just forgot to do it myself after the release of the Cocoon Maven Plugin 1.0.0 which was the prerequisite for the Spring upgrade. -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [C3] Intra-pipeline calls
On 06/27/2011 09:43 AM, Francesco Chicchiriccò wrote: Hi all, in these days I am working quite intensively in building an overalyable, Cocoon 3 based, web application. Looking at the sample code, it seems that the only way to make intra-pipeline calls is by using the servlet: protocol, hence the Servlet service. Is that correct? If so, would this mean that the cocoon-sample-wicket-webapp cannot make intra-pipeline calls because the Servlet service (namely the DispatcherServlet) is not in place - we have a catch-all Wicket-style filter there? Unfortunately you are right. I also don't have a good solution on hand ATM ... -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: Permission denied when copying Maven artifacts
On 06/27/2011 09:01 AM, Simone Tripodi wrote: Hi Reinhard, I had a quick chat on irc with infra guys, looks like they had to restart something (don't ask me what please) which down caused the lose of sudo superpowers. Anyway, I'm not a sudo-er, can you give yet another try? The artifacts are already available on the Central Maven Repository although I still get the 'permission denied' messages. I guess they mean something different ;-) IMO you can continue with the release procedure (copying the distribution artifacts, update the site, announcement mails, etc.) -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
[c3] cocoon-utils
I'd like to create a 'cocoon-utils' module. We have some classes (without any non RT.jar dependencies) like the WildcardMatcherHelper, the URLConnectionUtils and the MurmurHash implementation that is also useful for projects that don't need the actual Cocoon functionality. WDOT? Any objections? -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: Permission denied when copying Maven artifacts
On 06/20/2011 11:45 AM, Simone Tripodi wrote: Hi all guys, can anyone please help me on finalizing the release? when copying the Maven artifacts to the Apache sync repository (people.apache.org) I get the following error: $ cp -R /x1/www/people.apache.org/builds/cocoon/ /x1/www/people.apache.org/repo/m2-ibiblio-rsync-repository/ cp: /x1/www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/cocoon/cocoon-tools-modules/8/cocoon-tools-modules-8.pom.asc: Permission denied simonetripodi@x1:~$ Many thanks in advance, have a nice day! I tried it but I don't have any luck either :-( While I was at it, I cleaned up the /x1/www/people.apache.org/builds/cocoon/ by removing previous release builds and the cocoon-all artifacts which don't need to be copied to maven-central. You can find the distribution artifacts in /home/reinhard/apache-cocoon-3.0.0-alpha-3-dist. A backup of the cocoon build directory before I removed any files can be found in /home/reinhard/apache-cocoon-3.0.0-alpha-3-complete You'll need to get in contact with Apache infra to get the problem sorted out. -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [C3] Deploying Snapshots Was: Re: [C3] XSLTTransformer cache
On 06/22/2011 05:52 PM, Francesco Chicchiriccò wrote: On 22/06/2011 17:47, Simone Tripodi wrote: Hi Grosso! I think that, in order to simplify also the release process - I'm stuck because I don't have the permissions to copy c3 artifacts on main sync repo - we should move our distribution management to Apache Nexus[1] in order to have SNAPSHOTs and simplified release process. Agreed. At that point I'd suggest ato have also a Jenkins job on ASF's Jenkins[2] in order to have fresh SNAPSHOTs as soon as code is modified. This would be even better. If these two items are acceptable by other people as well, how should we apply for ASF Nexus and Jenkins? Yes, that's a good idea (and long overdue). -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [VOTE] Release Apache Cocoon 3.0.0-alpha-3
On 06/09/2011 11:22 PM, Reinhard Pötz wrote: On 06/09/2011 07:06 PM, Simone Tripodi wrote: [ ] +1, let's release Apache Cocoon 3.0.0-alpha-3 [x] +/- 0 [ ] -1, because (explain the reason why) Thanks for your great efforts! There are two things that need to be done before I can vote with +1 a) Please add you PGP key to http://www.apache.org/dist/cocoon/KEYS b) We also need a non-Maven (yes, there are still people that don't use the central Maven repo) distribution. You don't have to redo the release for that reason. Checkout the release tag, go to cocoon-all/pom.xml and apply the changes that I've just comitted to your working copy. Then run mvn clean package -P apache-release which will create the release artifacts. At this point the PGP signature files are missing because the creation of the release artifacts doesn't happen as part of the Maven release procedure. Hence sign the created .zip and .tar.gz files manually (gpg -sba [filename] should to the trick, at least with Linux GPG) and upload them to your people.apache.org public html folder so that others can check them before they cast their votes. Otherwise the Maven release artifacts are fine AFAICS. I've updated my Cocoon 3 projects and they all work well with alpha-3. Checked the hashcodes and the GPG signatures of http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-3/*dist* Also the Maven release artifacts and the SVN tags look good. Here's my +1 -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [VOTE] Release Apache Cocoon 3.0.0-alpha-3
On 06/10/2011 10:10 AM, Simone Tripodi wrote: Hi Reinhard! just a couple of minor questions for now: a) where I can find the KEYS file on svn? I'm pretty sure I updated it once, but can't remember if it was the cocoon or commons one that I'm referring... thanks in advance! :P I think you have to update it directly in our release directory on people.apache.org. David, is this correct? b) artifacts in http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-3/ are the ones automatically updated by maven, that's why there is some missing... anyway, since they already have been signed by gpg-plugin, can we reuse them with signatures/md5/sha attached? Unfortunately not this time because the generated distribution artifacts don't contain the docs and one or two modules. But for the next release this should work as expected. For the creation of the distribution artifacts please follow the instructions from my previous mail. Thanks! -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [VOTE] Release Apache Cocoon 3.0.0-alpha-3
On 06/09/2011 07:06 PM, Simone Tripodi wrote: [ ] +1, let's release Apache Cocoon 3.0.0-alpha-3 [x] +/- 0 [ ] -1, because (explain the reason why) Thanks for your great efforts! There are two things that need to be done before I can vote with +1 a) Please add you PGP key to http://www.apache.org/dist/cocoon/KEYS b) We also need a non-Maven (yes, there are still people that don't use the central Maven repo) distribution. You don't have to redo the release for that reason. Checkout the release tag, go to cocoon-all/pom.xml and apply the changes that I've just comitted to your working copy. Then run mvn clean package -P apache-release which will create the release artifacts. At this point the PGP signature files are missing because the creation of the release artifacts doesn't happen as part of the Maven release procedure. Hence sign the created .zip and .tar.gz files manually (gpg -sba [filename] should to the trick, at least with Linux GPG) and upload them to your people.apache.org public html folder so that others can check them before they cast their votes. Otherwise the Maven release artifacts are fine AFAICS. I've updated my Cocoon 3 projects and they all work well with alpha-3. -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Checking the release artifacts (Cocoon 3.0.0-alpha-3)
On 06/09/2011 07:06 PM, Simone Tripodi wrote: Hi all guys, I'm here to propose the release of Apache Cocoon 3.0.0-alpha-3. snip/ For those who want to check/test the Maven release artifacts, here are a some instructions: * use the new artifacts in projects that depend on previous or SNAPSHOT versions. Add the Cocoon staging repository profile to your ~/.m2/settings.xml ?xml version=1.0 encoding=UTF-8? settings xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd; profiles profile idcocoon-staging/id repositories repository idcocoon.staging/id nameCocoon staging repository/name urlhttp://people.apache.org/builds/cocoon/url /repository /repositories pluginRepositories pluginRepository idcocoon.staging/id nameCocoon staging repository/name urlhttp://people.apache.org/builds/cocoon/url /pluginRepository /pluginRepositories /profile /profiles /settings and use it: e.g. mvn install -P cocoon-staging * use all archetypes: mvn org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7:create -DarchetypeGroupId=org.apache.cocoon.archetype-sample -DarchetypeArtifactId=cocoon-archetype-sample -DarchetypeVersion=3.0.0-alpha-3 -DgroupId=com.mycompany -DartifactId=mysample -DremoteRepositories=http://people.apache.org/builds/cocoon/ mvn org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7:create -DarchetypeGroupId=org.apache.cocoon.archetype-block -DarchetypeArtifactId=cocoon-archetype-block -DarchetypeVersion=3.0.0-alpha-3 -DgroupId=com.mycompany -DartifactId=mysite -DremoteRepositories=http://people.apache.org/builds/cocoon/ mvn org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7:create -DarchetypeGroupId=org.apache.cocoon.archetype-parent -DarchetypeArtifactId=cocoon-archetype-parent -DarchetypeVersion=3.0.0-alpha-3 -DgroupId=com.mycompany -DartifactId=myparent -DremoteRepositories=http://people.apache.org/builds/cocoon/ mvn org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7:create -DarchetypeGroupId=org.apache.cocoon.archetype-webapp -DarchetypeArtifactId=cocoon-archetype-webapp -DarchetypeVersion=3.0.0-alpha-3 -DgroupId=com.mycompany -DartifactId=mywebapp -DremoteRepositories=http://people.apache.org/builds/cocoon/ -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [VOTE] Release Apache Cocoon 3.0.0-alpha-3
On 06/09/2011 11:22 PM, Reinhard Pötz wrote: On 06/09/2011 07:06 PM, Simone Tripodi wrote: [ ] +1, let's release Apache Cocoon 3.0.0-alpha-3 [x] +/- 0 [ ] -1, because (explain the reason why) Thanks for your great efforts! There are two things that need to be done before I can vote with +1 a) Please add you PGP key to http://www.apache.org/dist/cocoon/KEYS b) We also need a non-Maven (yes, there are still people that don't use the central Maven repo) distribution. You don't have to redo the release for that reason. Checkout the release tag, go to cocoon-all/pom.xml and apply the changes that I've just comitted to your working copy. Then run mvn clean package -P apache-release which will create the release artifacts. At this point the PGP signature files are missing because the creation of the release artifacts doesn't happen as part of the Maven release procedure. Hence sign the created .zip and .tar.gz files manually (gpg -sba [filename] should to the trick, at least with Linux GPG) and upload them to your people.apache.org public html folder so that others can check them before they cast their votes. Otherwise the Maven release artifacts are fine AFAICS. I've updated my Cocoon 3 projects and they all work well with alpha-3. One thing I forgot to mention: There are distribution release artifacts in http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-3/ but they are lacking the docs and some submodules. Sorry, I haven't thought sooner of it :-( One final note: The distribution release artifacts don't need to be copied to the central Maven repository sync folder when the vote is completed. I've just updated the release notes. -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [C3] Fwd: [Hippo-cms7-user] Cocoon 3 based frontend
On 06/08/2011 12:08 PM, Francesco Chicchiriccò wrote: Hi there, fist of all, sorry for the cross-posting. You can find below an e-mail that I've just sent to the Hippo CMS mailing list. There is some concrete possibility to use Cocoon 3 in a (rather small, as said) production environment. I would basically like to build a JCR SAX transformer (similar in functions to the Cocoon 2.1 WebDAV transformer) but I would also need, for example, some caching and i18n features. Do you see any particular issues besides the obvious risk of using an Alpha-2 (not yet Alpha-3) software for production? ;-) No, not that I know of any than the mentioned ones. Reinhard -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [C3] Release process clarification needed
On 06/08/2011 09:16 PM, Simone Tripodi wrote: Hi Reinhard/all, can someone explain me please what the third point in the RELEASE_HOWTO.txt means: * set all versions in the generated pom.xml files of all archetypes I didn't see where poms have been generated... thanks in advance!!! I've just updated the RELEASE_HOWTO.txt. HTH I also fixed the sample and the block archetype. To make things clearer for cocoon-archetype-sample: the sample-archetype uses a Groovy script to generate the assembly descriptor on the fly based on the content of cocoon-sample and copies all relevant resources to src/main/resources/archetype-resources Maybe there are better ways to achieve this goal with 'standard' Maven plugins in the meantime ... -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [C3] Release process clarification needed
On 06/08/2011 11:26 PM, Simone Tripodi wrote: thanks a lot for your kind help Reinhard!!! sorry for my lack of knowledge of Groovy, but... do I need an interpreter to install to execute it? Many thanks in advance!!! No, that's done by the GMaven plugin automatically for you. See the pom.xml of the cocoon-archetype-sample module. -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [C3] replacing the logging framework
On 04/27/2011 09:25 AM, Simone Tripodi wrote: I can take care of making the release - any advice before I start? :) see https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/RELEASE_HOWTO.txt you can also contact me via Skype if you have any questions. Good luck ;-) -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: svn commit: r1096155 - in /cocoon/cocoon3/trunk/cocoon-optional/src: main/java/org/apache/cocoon/optional/pipeline/components/sax/jaxb/ test/java/org/apache/cocoon/optional/pipeline/components/sax
On 04/23/2011 04:49 PM, simonetrip...@apache.org wrote: Author: simonetripodi Date: Sat Apr 23 14:49:10 2011 New Revision: 1096155 URL: http://svn.apache.org/viewvc?rev=1096155view=rev Log: fix for COCOON3-58: The org.apache.cocoon.optional.pipeline.components.sax.jaxb.JAXBGenerator is incomplete test cases included Unfortunately this commit breaks the build: --- Test set: org.apache.cocoon.optional.pipeline.components.sax.jaxb.JAXBGeneratorTestCase --- Tests run: 6, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.802 sec FAILURE! testPipelineWithUncountableNamedBean(org.apache.cocoon.optional.pipeline.components.sax.jaxb.JAXBGeneratorTestCase) Time elapsed: 0.004 sec ERROR! java.lang.IndexOutOfBoundsException: No group 1 at java.util.regex.Matcher.group(Matcher.java:470) at java.util.regex.Matcher.appendReplacement(Matcher.java:737) at java.util.regex.Matcher.replaceFirst(Matcher.java:861) at org.apache.cocoon.optional.pipeline.components.sax.jaxb.PluralStemmer.toPlural(PluralStemmer.java:187) snip/ -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [C3] replacing the logging framework
On 04/23/2011 04:56 PM, Simone Tripodi wrote: Hi all guys, Reinhard, Francesco and I had a quick chat on tweeter about replacing the logging framework in C3 and we all agreed on migrating to SLF4J + Logback. IMHO it is an operation simple enough that can be completed before proceeding to next release, what does someone else think about it? If there isn't any objection, I can take easily take care of it, just let me know! I guess you're right with the pipeline and sitemap modules, but I expect it to be more difficult for the servlet module. The question _for now_ is whether we have to replace the logging framework there at all and keep the Spring configurator's log4j integration instead. Changing the servlet module to use the slf4j/log4j binding could be done later. But I'm not sure if this plan works as expected ... -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [C3] Releasing alpha-3 (and beyond)?
On 04/18/2011 01:44 PM, Steven Dolg wrote: Hey, picking up some speed would be really great for this project. Seeing that some of the issues are older than a year and the rest approaching their first anniversary very soon feels almost awkward. As mentioned in his email, Reinhard and I are working on something for the Pipeline API that might change some things, but introduce very interesting opportunities - well at least opportunities we'd like to have. The goal is obviously to not break anything but it's a fundamental change, of course. We certainly need to wrap this up in a nice, little package and somehow present it here. I just don't know how fast we can manage to do that. But besides that: What can we do to get the next release out? How do we go about addressing those issues? IMO none of the issues is blocking a release, especially not an alpha release. We should set a date (e.g. April, 25th) and freeze the codebase for the alpha-3 release. All code that is committed by then is part of the release, everything else has to wait for beta-1. WDYT? BTW, does somebody else want to take the role of the release manager? I wrote a summary at https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/RELEASE_HOWTO.txt that explains all necessary steps. Thanks to Maven it shouldn't be too hard ... -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [C3] Releasing alpha-3 (and beyond)?
Francesco, thank you very much for working towards a release! Comments in-line. On 04/15/2011 09:23 AM, Francesco Chicchiriccò wrote: Hi all, taking a look at [1], it seems that the only issue currently blocking the alpha-3 release of Cocoon 3 is COCOON3-58 [2]. Actually, that issue has been already fixed by Simone Tripodi (look at the patch attached to the ticket); there are, though, still some doubts about copyright issues [3]. In my opinion - as already expressed there - if the possible TM issue is limited to regexp patterns, I don't think there could be anything to claim about. I think so too. Having said that, and taking into account the need that still seems to be around of having a stable Cocoon 3 release as soon as possible, what do you think if we close COCOON3-58 and do a fresh alpha-3 release? yes, that would be great Moreover, only 8 issues (including the above-mentioned COCOON3-58) are still open [4], so we could catch the chance to try to fix them and do a clamorous beta release! What do you think about this? I would like to see an alpha-3 release before and aim for a beta release in about two or three months. The reason is that I want to discuss (and fix) the result type of pipelines before (http://cocoon.markmail.org/message/ew3pnsyz6g5a6ho3). Steven and I have experimented with some API changes that go beyond that what I proposed back in December 2008 but we haven't had enough time to write down our thoughts and send them to this list. Since there are multiple options to solve this problem I expect that the discussions will take some time and shouldn't prevent an alpha -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: Plural Stemmer/Inflactor - part 2
On 04/02/2011 12:26 PM, Francesco Chicchiriccò wrote: On 02/04/2011 12:03, Simone Tripodi wrote: Hi all guys, I (maybe) fixed the issue, can you please check legal issues we could have on the attached patch as reported on COCOON3-58, please? I am not at all a legal expert but if the possible TM issue is limited to regexp patterns, I don't think there could be anything to claim about. I think so too. -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [c3] Log*Transformer
On 03/02/2011 10:38 AM, Francesco Chicchiriccò wrote: About this, do you know how can I ask to align my current JIRA account (ilgrosso) to my recent committer rights? Thanks. done -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [c3] Log*Transformer
On 02/28/2011 09:28 AM, Simone Tripodi wrote: Hi again, Francesco, did you receive your account activation? If not...: Reinhard, do you know who I have to ping? It's not unusual if it takes a week or two to get an account created ... -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [c3] Log*Transformer
On 02/21/2011 11:32 AM, Francesco Chicchiriccò wrote: On 21/feb/2011, at 10.56, Simone Tripodi wrote: Hi all, I'd tend agree with Reinhard if the CloseShield functionality is not simple (and I mean very simple, almost silly) to replicate into our module. I'm sure the CloseShield in the IO takes care of more general PrintStream use cases rather then just the sysout, so I'm worried that the proposed patch is not enough... For the sake of clarity: I've proposed that naive patch mainly because I think that Log*Transformers are there to be used only for dev purpose, where System.out or FileOutpuStream are the only viable candidates. Anyway, I've taken a quick look to http://s.apache.org/commons-io-close-shield-outputstream and its parent class http://bit.ly/h7AolY: it seems to me that it would be quite easy to embed these two classes in order to have a CloseShield functionality in cocoon3-sax. If you think that it could be useful to have such functionality there (also for usage by other classes than just Log*Transformers), please let me know. I think the patch with the simple approach is good enough in this case because the class encapsulates the usage of the output stream completely. (It would be different if an output stream was passed to the transformer ...) Since you get commit access to the repository soon, you can apply the patch yourself ;-) Congratulations BTW! -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
[c3] Log*Transformer
I had to comment the usage of the Log*Transformers in the sample sitemap because they break the integration tests (run it.sh or it.bat from C3's root directory). The problem is that the logfile is written to the file system which doesn't work in a multi-module build (map:parameter name=logfile value=target/logasxml.log / - there is no target directory at the base directory). IMO the best idea would be changing the transformer configurations to use System.out but the current implementations close the output stream in their finish methods. That's of course useful for FileOutputStreams but mustn't happen for System.out. IMO the best solution would be wrapping the usage of System.out with Commons IO's CloseShieldOutputStream (http://s.apache.org/commons-io-close-shield-outputstream). However, this would introduce a dependency of cocoon-sax on commons-io which should be avoided for a minor use case like this. I see two possible solutions: a) move the Log*Transformers to cocoon-optional and wrap the usage of System.out with the CloseShieldOutputStream b) implement the CloseShield functionality ourselves and leave them where they are. I would prefer option a) because it's the simpler solution and leads to less code. WDYT? -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
[result][vote] Release Cocoon JNet 1.2.0, Cocoon Maven Plugin 1.0.0 Cocoon Maven Site Skin 1.0.0
On 01/18/2011 06:22 PM, Reinhard Pötz wrote: I created release artifacts for following modules: * Cocoon JNet 1.2.0 * Cocoon Maven Plugin 1.0.0 * Cocoon Maven Site Skin 1.0.0 The vote passed with 4 binding +1 votes. Thanks to all for your reviews and votes. I will take care of the synchronization of the release artifacts with the central Maven repository and the Apache distribution area. Then I will update the docs and send out the official announcement mails. -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [vote] Release Cocoon JNet 1.2.0, Cocoon Maven Plugin 1.0.0 Cocoon Maven Site Skin 1.0.0
On 01/29/2011 06:03 AM, David Crossley wrote: Reinhard Pötz wrote: I created release artifacts for following modules: * Cocoon JNet 1.2.0 SVN: http://s.apache.org/cocoon-jnet-1.2.0 Maven artifacts: http://s.apache.org/cocoon-jnet-1.2.0-maven Distribution files: http://people.apache.org/~reinhard/cocoon-staging/cocoon-jnet/ Changes: http://s.apache.org/cocoon-jnet-1.2.0-changes +1 for Cocoon JNet 1.2.0 MD5(cocoon-jnet-1.2.0.tar.gz)= a58a8f8727c4603377f15d7e1a3847b5 * Cocoon Maven Plugin 1.0.0 SVN: http://s.apache.org/cocoon-maven-plugin-1.0.0 http://s.apache.org/cocoon-rcl-spring-reloader-1.0.0 http://s.apache.org/cocoon-rcl-webapp-wrapper-1.0.0 Maven artifacts: http://s.apache.org/cocoon-maven-plugin-1.0.0-maven http://s.apache.org/cocoon-rcl-spring-reloader-1.0.0-maven http://s.apache.org/cocoon-rcl-webapp-wrapper-1.0.0-maven Distribution files: a Maven release only (doesn't make sense to use it ouside the scope of Maven) Changes: Support Spring 3.0 +1 for Cocoon Maven Plugin 1.0.0 MD5(cocoon-maven-plugin-1.0.0-sources.jar)= 9564e956381e7c47b025ffe5a4270bfc MD5(cocoon-rcl-spring-reloader-1.0.0-sources.jar)= 534cc5d27e2cba208146d848e70b1f56 MD5(cocoon-rcl-webapp-wrapper-1.0.0-sources.jar)= 5c086d4b8918b213d3aee909f5fc93f4 * Cocoon Maven Site Skin 1.0.0 SVN: http://s.apache.org/cocoon-thien-maven-site-skin-1.0.0 Maven artifacts: http://s.apache.org/cocoon-thien-maven-site-skin-1.0.0-maven Distribution files: a Maven release only (doesn't make sense to use it ouside the scope of Maven) Changes: initial release I cannot see the iCLA recorded for Thien. You did ask for it in this thread and it looked like follow-through, but i cannot find it in the iclas.txt file. http://s.apache.org/bYK Date: Tue, 23 Jan 2007 Subject: Re: Artwork for cocoon.apache.org - next steps -1 for Cocoon Maven Site Skin 1.0.0 MD5(cocoon-thien-maven-site-skin-1.0.0-sources.jar)= e397a0c3eecf42bd7a2b1d1feeb1a24b Due to the missing CLA. Otherwise okay. Ouch, sorry for not looking into this vote thread until now. Thanks for voting. Concerning Thien's CLA I will answer on private@ because it contains personal information about Thien and I'm not sure if he wants to see it being published on a public mailing list. -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: Going emeritus
On 01/28/2011 12:04 AM, Grzegorz Kossakowski wrote: Hi, I would like to go emeritus. I've been hesitating for quite long time because I'm still emotionally connected to this project. Cocoon was the first open source project that I contributed to and it's amazing community shaped me as professional programmer. I literally grew up with you guys learning how to create great software, foster great community and how to communicate long before I got enrolled into university. You've been really influential on how I perceived and continue to perceive open source. Also, I enjoyed your company as a group of great people. I would like to especially thank Daniel Fagerstrom, Reinhard Potz and David Crossley. This is a sad moment for me but I must admit that I see no chance for contributing to Cocoon again in a foreseeable future. Actually, I don't even program in Java anymore. I moved to Scala and I don't want to look back. You can learn a bit about my recent project over here: http://scalagwt.gogoego.com/. I'll update my records in svn in a week and I'll contact PMC to inform about my decision. Thanks for a great time and I hope to meet you again in a future. Grzegorz, I wish you all the best and thanks a lot for your contributions to Cocoon. -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
[vote] Release Cocoon JNet 1.2.0, Cocoon Maven Plugin 1.0.0 Cocoon Maven Site Skin 1.0.0
I created release artifacts for following modules: * Cocoon JNet 1.2.0 SVN: http://s.apache.org/cocoon-jnet-1.2.0 Maven artifacts: http://s.apache.org/cocoon-jnet-1.2.0-maven Distribution files: http://people.apache.org/~reinhard/cocoon-staging/cocoon-jnet/ Changes: http://s.apache.org/cocoon-jnet-1.2.0-changes * Cocoon Maven Plugin 1.0.0 SVN: http://s.apache.org/cocoon-maven-plugin-1.0.0 http://s.apache.org/cocoon-rcl-spring-reloader-1.0.0 http://s.apache.org/cocoon-rcl-webapp-wrapper-1.0.0 Maven artifacts: http://s.apache.org/cocoon-maven-plugin-1.0.0-maven http://s.apache.org/cocoon-rcl-spring-reloader-1.0.0-maven http://s.apache.org/cocoon-rcl-webapp-wrapper-1.0.0-maven Distribution files: a Maven release only (doesn't make sense to use it ouside the scope of Maven) Changes: Support Spring 3.0 * Cocoon Maven Site Skin 1.0.0 SVN: http://s.apache.org/cocoon-thien-maven-site-skin-1.0.0 Maven artifacts: http://s.apache.org/cocoon-thien-maven-site-skin-1.0.0-maven Distribution files: a Maven release only (doesn't make sense to use it ouside the scope of Maven) Changes: initial release This majority vote stays open for at least 72 hours. Please cast your votes. Thanks. -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [vote] Release Cocoon JNet 1.2.0, Cocoon Maven Plugin 1.0.0 Cocoon Maven Site Skin 1.0.0
On 01/18/2011 06:22 PM, Reinhard Pötz wrote: I created release artifacts for following modules: * Cocoon JNet 1.2.0 SVN: http://s.apache.org/cocoon-jnet-1.2.0 Maven artifacts: http://s.apache.org/cocoon-jnet-1.2.0-maven Distribution files: http://people.apache.org/~reinhard/cocoon-staging/cocoon-jnet/ Changes: http://s.apache.org/cocoon-jnet-1.2.0-changes * Cocoon Maven Plugin 1.0.0 SVN: http://s.apache.org/cocoon-maven-plugin-1.0.0 http://s.apache.org/cocoon-rcl-spring-reloader-1.0.0 http://s.apache.org/cocoon-rcl-webapp-wrapper-1.0.0 Maven artifacts: http://s.apache.org/cocoon-maven-plugin-1.0.0-maven http://s.apache.org/cocoon-rcl-spring-reloader-1.0.0-maven http://s.apache.org/cocoon-rcl-webapp-wrapper-1.0.0-maven Distribution files: a Maven release only (doesn't make sense to use it ouside the scope of Maven) Changes: Support Spring 3.0 * Cocoon Maven Site Skin 1.0.0 SVN: http://s.apache.org/cocoon-thien-maven-site-skin-1.0.0 Maven artifacts: http://s.apache.org/cocoon-thien-maven-site-skin-1.0.0-maven Distribution files: a Maven release only (doesn't make sense to use it ouside the scope of Maven) Changes: initial release This majority vote stays open for at least 72 hours. Please cast your votes. Thanks. +1 -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: Team List Updates
On 01/13/2011 08:35 AM, Carsten Ziegeler wrote: Hi, it seems that the teamlists at: http://cocoon.apache.org/3.0/team-list.html http://cocoon.apache.org/team-list.html are out of date and need some updates. It would be great if someone could send me to emeritus. Thanks! I updated http://cocoon.apache.org/3.0/team-list.html. http://cocoon.apache.org/team-list.html will follow as soon as I find some time to finish my work on the Daisy reactivation (I'm half way through yet ...) so that a 'mvn site' rebuilds the docs. -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Preparing releases: cocoon-maven-plugin, cocoon-jnet, cocoon-thien-maven-site-skin
For the last couple of months I haven't been following Cocoon development closely, but I want to work again on a couple of things related to Cocoon. First I'd like to start with the release of some long overdue modules: * cocoon-maven-plugin (plus cocoon-rcl-*): Using the Cocoon Maven plugin to provide a launcher environment (cocoon:prepare) which references Spring 3, causes an AbstractMethodError. See http://cocoon.markmail.org/message/hapiusamiic4uzq2 It has been in use for quite a while, hence I'd like to release it as 1.0.0 * cocoon-jnet There is a chance to produce a NPE in DynamicURLStreamHandlerFactoryBecause See https://issues.apache.org/jira/browse/COCOON-2277 Since it's only a bug fix release that can be used as a drop-in replacement for 1.1.0, I suggest releasing it as 1.1.1 * cocoon-thien-maven-site-skin It has never been released yet. Cocoon 3 also uses this skin which requires a manual build of it before the Cocoon 3 site can be created. That's not a really comfortable for people that are only interested in building the C3 site. It has been in use for quite a while, hence I'd like to release it as 1.0.0 Since the Cocoon Maven plugin and the cocoon-rcl-* modules are used in Cocoon 2 and 3 I'd like to move them to a more general place. For that purpose I suggest moving them to cocoon/trunk/subprojects. WDYT? -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: Preparing releases: cocoon-maven-plugin, cocoon-jnet, cocoon-thien-maven-site-skin
On 01/04/2011 03:38 AM, Peter Hunsberger wrote: On Mon, Jan 3, 2011 at 5:36 PM, Reinhard Pötzreinh...@apache.org wrote: For the last couple of months I haven't been following Cocoon development closely, but I want to work again on a couple of things related to Cocoon. First I'd like to start with the release of some long overdue modules: * cocoon-maven-plugin (plus cocoon-rcl-*): It has been in use for quite a while, hence I'd like to release it as 1.0.0 * cocoon-jnet Since it's only a bug fix release that can be used as a drop-in replacement for 1.1.0, I suggest releasing it as 1.1.1 * cocoon-thien-maven-site-skin It has been in use for quite a while, hence I'd like to release it as 1.0.0 Since the Cocoon Maven plugin and the cocoon-rcl-* modules are used in Cocoon 2 and 3 I'd like to move them to a more general place. For that purpose I suggest moving them to cocoon/trunk/subprojects. WDYT? +1 - I'm not completely sure about whether 1.0 is completely correct in some cases, but OTOH I don't think it's worth worrying about... Neither am I but changing any contracts without some deprecation phase in the cocoon-maven-plugin or the site-skin wouldn't be very helpful to the existing users. And, there's always the chance of a 2.x release ;-) -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: Gump for Cocoon3
David Crossley wrote: At Apache Gump, Stefan has recently added a Gump build of Cocoon3. See http://thread.gmane.org/gmane.comp.jakarta.gump/14458/focus=14475 Here is the first output: http://vmgump.apache.org/gump/public/cocoon3/ If not familiar with Gump, then follow: All Projects : cocoon3 then Project-level Work : build_cocoon3_cocoon3 then Output : Complete Output File Could someone here at Cocoon assist with the build errors. Not sure if Gump runs more than once per day, but that last run finished at 19:20 US PDT. When it settles, we could enable Gump to nag us. I guess it is somehow related with the XSLTC precompilation tests. Simone, any idea? -- Reinhard PötzFounder Managing Director, Indoqa http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org
Re: Planning for a release of the Cocoon Maven Plugin
Reinhard Pötz wrote: The upgrade of Spring 3 required some minor changes of the Cocoon Maven plugin. See http://cocoon.markmail.org/message/hapiusamiic4uzq2 In order to make this fix (http://cocoon.markmail.org/message/ab4muyauhznirms7) available for all people that don't want to build it themselves, I'd like to release the plugin. The current version is 1.0.0-M3. I think that a 1.0.0 release is appropriate because the plugin has proven to be stable with respect to its interfaces as well as its implementation. Since there are no objections, I will create the release artifacts over the weekend or next week. -- Reinhard PötzFounder Managing Director, Indoqa http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org
Re: [C3] Adding the cinclude transformer
Hugh Sparks wrote: It appears that IncludeTransformer might work if I pass the parameters in the url, which would make an ugly mess out of my code. IncludeTransformer is pretty simple. Would it be appropriate to add optional protocol for controlling the request (GET, POST) and passing parameters in an element? Or would it be better to add some new thing like a rewrite of the old CIncludeTransform? It seems excessive to have Include, XInclude, and CInclude... This is what I'm doing now with C2: ci:includexml ci:configuration ci:srchttp://myserver/cgi-bin/someScript.sh/ci:src ci:parameter ci:namemethod/ci:name ci:valuePOST/ci:value /ci:parameter /ci:configuration ci:parameters ci:parameter ci:nameparam1/ci:name ci:valuevalue1/ci:value /ci:parameter ... /ci:parameters /ci:include I think it would be good for C3 to have some kind of door to invoke scripts on the server. And cramming things onto the URL and using GET isn't very attractive. I think that it would be the best idea to port the CInclude transformer of C2. When I wrote the IncludeTransformer, I just did the simplest possible thing, no POST support or support for parallel include pipeline execution. Any contribution would be highly appreciated! -- Reinhard PötzFounder Managing Director, Indoqa http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org
Planning for Cocoon 3 alpha-3
The latest Cocoon 3 release is three months ago. In the meantime a couple of improvements and fixes have found their way into SVN. See https://svn.eu.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-docs/src/changes/changes.xml I think it's time for another release. I propose to release it as 'alpha-3' because I expect some more backwards-incompatible changes of the pipline API (a pipeline should be able to produce other output than java.io.OutputStream as a direct result). After this change we could start with beta releases IMO. WDOT? -- Reinhard PötzFounder Managing Director, Indoqa http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org
Planning for a release of the Cocoon Maven Plugin
The upgrade of Spring 3 required some minor changes of the Cocoon Maven plugin. See http://cocoon.markmail.org/message/hapiusamiic4uzq2 In order to make this fix (http://cocoon.markmail.org/message/ab4muyauhznirms7) available for all people that don't want to build it themselves, I'd like to release the plugin. The current version is 1.0.0-M3. I think that a 1.0.0 release is appropriate because the plugin has proven to be stable with respect to its interfaces as well as its implementation. WDOT? -- Reinhard PötzFounder Managing Director, Indoqa http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org
Re: Planning for Cocoon 3 alpha-3
Simone Tripodi wrote: Hi Reinhard! Yes I totally agree with you, before releasing it I personally would like to spent some effort on integrating the new latest components (XInclude, LinkRewriter, Log and LogAsXML) into the sitemap, this weekend I'm trying to do my best. Once these integration will be completed, then we should be able to release the alpha 3. Does it work for you? An of course, as you reminded, any contribution will be more than appreciated :) All the best, thanks in advance!!! That's fine with me, I won't be able to cut the release before May anyway. -- Reinhard PötzFounder Managing Director, Indoqa http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org
Re: Adding new components to C3 Optionals
I forgot to mention another place where we have to mentation the inclusion of CDDL licensed stuff: The cocoon-all module creates the distribution that contains all Cocoon modules, of course also cocoon-optional. Simone Tripodi wrote: Thanks to you, very appreciated! :) See you, Simo http://people.apache.org/~simonetripodi/ On Tue, Apr 20, 2010 at 10:21 PM, Reinhard Pötz reinh...@apache.org wrote: Simone Tripodi wrote: Hi all, Reinhard, I just added the JAXB generator to C3 Optionals, I'd like to ask if you have time to review the licensing part. I followed yours and Donald's hints, but 4 eyes are better than 2 :P Thanks in advance, have a nice evening, Looks good to me, thanks! -- Reinhard PötzFounder Managing Director, Indoqa http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org -- Reinhard PötzFounder Managing Director, Indoqa http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org
Re: Adding new components to C3 Optionals
While reviewing your commit, I've already done the necessary changes. Simone Tripodi wrote: Hi Reinhard! OK, I'll take care about it during the lunchtime, don't worry!!! All the best, Simo http://people.apache.org/~simonetripodi/ On Wed, Apr 21, 2010 at 9:49 AM, Reinhard Pötz reinh...@apache.org wrote: I forgot to mention another place where we have to mentation the inclusion of CDDL licensed stuff: The cocoon-all module creates the distribution that contains all Cocoon modules, of course also cocoon-optional. Simone Tripodi wrote: Thanks to you, very appreciated! :) See you, Simo http://people.apache.org/~simonetripodi/ On Tue, Apr 20, 2010 at 10:21 PM, Reinhard Pötz reinh...@apache.org wrote: Simone Tripodi wrote: Hi all, Reinhard, I just added the JAXB generator to C3 Optionals, I'd like to ask if you have time to review the licensing part. I followed yours and Donald's hints, but 4 eyes are better than 2 :P Thanks in advance, have a nice evening, Looks good to me, thanks! -- Reinhard PötzFounder Managing Director, Indoqa http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org -- Reinhard PötzFounder Managing Director, Indoqa http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org -- Reinhard PötzFounder Managing Director, Indoqa http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org
Re: Adding new components to C3 Optionals
Simone Tripodi wrote: Hi all, Reinhard, I just added the JAXB generator to C3 Optionals, I'd like to ask if you have time to review the licensing part. I followed yours and Donald's hints, but 4 eyes are better than 2 :P Thanks in advance, have a nice evening, Looks good to me, thanks! -- Reinhard PötzFounder Managing Director, Indoqa http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org
Re: Adding new components to C3 Optionals
I'm not sure what is meant by Java SE 5 level of JAXB support because AFAICS it doesn't come with the JRE. I guess that it means that we have to add a JAXB dependency to the cocoon-optional POM: dependency groupIdcom.sun.xml.bind/groupId artifactIdjaxb-impl/artifactId version2.2/version optionaltrue/optional /dependency and dependency groupIdjavax.xml/groupId artifactIdjaxb-api/artifactId version2.1/version optionaltrue/optional /dependency Both are available at the central Maven repo. Since the impl is licenced under CDDL we have to add the CDDL license to the cocoon-optional LICENSE.txt and the mentioned third-party notice to the NOTICE.txt file. Reinhard Simone Tripodi wrote: Hi Reinhard, follow below what Donald Woods, from Apache Geronimo Apache BeanValidation, wrote me about JAXB Licensing, maybe could help us o resolve our issue. Before starting coding I'll wait for your feedbacks. Have a nice evening, all the best! Simo --- We've distributed JAXB in Geronimo releases, as a CDDL binary-only jar (no source or jar checked into svn.) To do so, you just need to include the appropriate info in the LICENSE and NOTICE files for your project. See - https://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-2.1.5/LICENSE.txt https://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-2.1.5/NOTICE.txt BUT, if your project can use the Java SE 5 or 6 provided levels of JAXB, then I strongly suggest you not provide your own. We had to include different levels in Geronimo, as the Java EE spec was always one generation of JAXB ahead of the Java SE spec 1) LICENSE - third-party licenses after the ASL 2.0 text - = == Sun CDDL License == == JAXB-API, JAXB, JAXWS, JSTL, SAAJ == = COMMON DEVELOPMENT AND DISTRIBUTION LICENSE (CDDL) Version 1.0 license text here 2) NOTICE - third-party required notices - . . . This product includes/uses software, Java Architecture for XML Binding (JAXB API), developed by Sun Microsystems (http://www.sun.com/) License: COMMON DEVELOPMENT AND DISTRIBUTION LICENSE (CDDL) Version 1.0 (http://www.sun.com/cddl/cddl.html) . . . = == Sun CDDL Notice== = This product includes software developed for the JAXB Reference Implementation project. (https://jaxb.dev.java.net/) This product includes software developed for Java API for XML Web Services project (JAX-WS) (https://jax-ws.dev.java.net/) This product includes software developed for the Java Server Pages Tag Library project (https://jstl.dev.java.net/) This product includes software developed for SOAP with Attachments API for Java (SAAJ). The software is available from the GlassFish project (https://saaj.dev.java.net/) http://people.apache.org/~simonetripodi/ On Wed, Apr 7, 2010 at 10:07 AM, Reinhard Pötz reinh...@apache.org wrote: Simone Tripodi wrote: Hi All, Reinhard, in the Apache BeanValidation we're using JAXB without any particular care on Licensing, being JAXB now part of the JVM. If you agree I'd add a JAXB based component starter to serialize beans through the SAX Pipeline in the sax module... what do you think about it? Hi Simone, isn't it a question of what JVM version we want to target? IIUC JAXB is part of Java 6 but for Java 5 you have to add external libraries. Since Cocoon 3 should be Java 5 compatible, we don't come around this problem. Reinhard On Thu, Feb 18, 2010 at 11:45 AM, Simone Tripodi simone.trip...@gmail.com wrote: Thank a lot Reinhard, I'll check the projects you mentioned!!! Have anice day :) Simo http://people.apache.org/~simonetripodi/ On Thu, Feb 18, 2010 at 8:53 AM, Reinhard Pötz reinh...@apache.org wrote: Simone Tripodi wrote: Hi all guys, even if a little late, I noticed an old email[1] in the users ML where one of C3 users was asking us how to integrate a JAXB marshaller into C3. After provided the hint, I suggested him to send a patch but at the same time I don't know if it could be applied because of the licensing: on the JAXB documentation I'm reading is reported that. * JAXB is a redistributable component of the JWSDP that's covered by the JWSDP License[3] * Parts of the JAXP software bundled with JAXB are covered by the Apache License and the W3C License I'm not a lawyer and honestly not expert about licenses: do you have any info that confirm we can/can't add JAXB in C3? Also Javolution[4] contains a nice and fast XML marshaller[5], but Javolution is released under the BSD[6] License. Are we allowed
Changes.xml and contributors in our parent POM
simonetrip...@apache.org wrote: Author: simonetripodi Date: Wed Apr 14 20:14:55 2010 New Revision: 934171 URL: http://svn.apache.org/viewvc?rev=934171view=rev Log: COCOON3-54 LinkRewriterTransformer porting from Cocoon 2.X by Francesco Chicchiriccò Hi Simone, many thanks for taking care of committing this patch! Additionally it would be great if you could add Francesco to the parent POM as contributor and update the changes.xml in the cocoon-site module. This is our way to 'officially' say thank you to contributors and to give an overview of what has changed between releases. IIRC you also applied some patch some time ago - please check if this is mentioned as described above.TIA -- Reinhard PötzFounder Managing Director, Indoqa http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org
Re: Adding new components to C3 Optionals
Simone Tripodi wrote:
Hi All, Reinhard,
in the Apache BeanValidation we're using JAXB without any particular
care on Licensing, being JAXB now part of the JVM.
If you agree I'd add a JAXB based component starter to serialize beans
through the SAX Pipeline in the sax module... what do you think about
it?
Hi Simone,
isn't it a question of what JVM version we want to target? IIUC JAXB is
part of Java 6 but for Java 5 you have to add external libraries. Since
Cocoon 3 should be Java 5 compatible, we don't come around this problem.
Reinhard
On Thu, Feb 18, 2010 at 11:45 AM, Simone Tripodi
simone.trip...@gmail.com wrote:
Thank a lot Reinhard,
I'll check the projects you mentioned!!!
Have anice day :)
Simo
http://people.apache.org/~simonetripodi/
On Thu, Feb 18, 2010 at 8:53 AM, Reinhard Pötz reinh...@apache.org wrote:
Simone Tripodi wrote:
Hi all guys,
even if a little late, I noticed an old email[1] in the users ML where
one of C3 users was asking us how to integrate a JAXB marshaller into
C3.
After provided the hint, I suggested him to send a patch but at the
same time I don't know if it could be applied because of the
licensing: on the JAXB documentation I'm reading is reported that.
* JAXB is a redistributable component of the JWSDP that's covered
by the JWSDP License[3]
* Parts of the JAXP software bundled with JAXB are covered by the
Apache License and the W3C License
I'm not a lawyer and honestly not expert about licenses: do you have
any info that confirm we can/can't add JAXB in C3?
Also Javolution[4] contains a nice and fast XML marshaller[5], but
Javolution is released under the BSD[6] License. Are we allowed to
integrate Javolution in C3?
I've never used JAXB, but I found http://camel.apache.org/jaxb.html
which says that JAXB is part of Java 6.
In order to remain Java 5 compliant, we have to add an optional JAXB
dependency. Maybe Apache WS, CXF or Geronimo offer an AL 2.0 complient
implementation or you could at least find out how they provide JAXB support.
--
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 reinh...@apache.org
--
Reinhard PötzFounder Managing Director, Indoqa
http://www.indoqa.com/people/reinhard-poetz.html
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
Re: summer of code
Will Holcomb wrote:
Hi, I'm a student with a project idea that I think might be a good
addition to Cocoon and I have a couple of questions.
#1. Does Cocoon have to apply to SoC on it's own, or will it be inducted
as a part of Apache?
It's the Apache Software Foundation.
I ask because the mentorship applications are only open March 8-12. My
web researchings suggest nothing has to be done right now by anyone in
this project, but I'm only about 90% sure.
Do you have any suggestions for a project? Unfortunately I won't have
time to get involved myself this year.
#2. When is a production release expected for Cocoon 3?
I will work on another release some time later this month or in April.
It will take some time until we get a production release out of the door.
I'm hoping for my SoC project to power my Burning Man art. I've done
tests with both versions 2 and 3, and I'm leaning toward 3, but I don't
want my art to crash. ☺
Some Cocoon 3 APIs might change (e.g. we have to find some way to make
the output type of a pipeline more flexible), but the implementation is
rather stable IMO. I also expect that your chances of finding a mentor
are best with Cocoon 3. As mentioned above, write down your ideas of a
Cocoon 3 GSoC project and share them with this community. Then let's
find a mentor for your project.
--
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 reinh...@apache.org
Re: [c3 monitoring] Integration tests
Dariusz Łuksza wrote:
Hi,
I'm back on track after some time of absence.
Welcome back!
To write integration tests I should start programaticaly cocoon with
predefined configuration's. Then test suites should connect to JMX
service and check does everything is all right.
So there are two goals:
* start cocoon from test case with predefine configuration
* write small JMX client that would only connect to JMX service and
get list of available services.
The main question is where can I find examples how to achieve first goal ?
IIUC, the main problem is that you have to start your own VM instance,
right? Have a look at http://commons.apache.org/exec/. In this VM
instance you can start a Jetty server yourself (e.g.
http://svn.apache.org/repos/asf/cocoon/trunk/tools/cocoon-it-fw/src/main/java/org/apache/cocoon/maven/test/jetty/JettyStarterMojo.java)
HTH
--
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 reinh...@apache.org
Re: Adding new components to C3 Optionals
Simone Tripodi wrote:
Hi all guys,
even if a little late, I noticed an old email[1] in the users ML where
one of C3 users was asking us how to integrate a JAXB marshaller into
C3.
After provided the hint, I suggested him to send a patch but at the
same time I don't know if it could be applied because of the
licensing: on the JAXB documentation I'm reading is reported that.
* JAXB is a redistributable component of the JWSDP that's covered
by the JWSDP License[3]
* Parts of the JAXP software bundled with JAXB are covered by the
Apache License and the W3C License
I'm not a lawyer and honestly not expert about licenses: do you have
any info that confirm we can/can't add JAXB in C3?
Also Javolution[4] contains a nice and fast XML marshaller[5], but
Javolution is released under the BSD[6] License. Are we allowed to
integrate Javolution in C3?
I've never used JAXB, but I found http://camel.apache.org/jaxb.html
which says that JAXB is part of Java 6.
In order to remain Java 5 compliant, we have to add an optional JAXB
dependency. Maybe Apache WS, CXF or Geronimo offer an AL 2.0 complient
implementation or you could at least find out how they provide JAXB support.
--
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 reinh...@apache.org
[jnet] Threading issues
Moving over this thread to dev.
Carsten, any idea what could go wrong here? And, once I asked you why
you used an InheritableThreadLocal instead of a ThreadLocal to store the
list but can't remember. Can you explain it to me again? :-)
--
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 reinh...@apache.org
---BeginMessage---
Reinhard Pötz wrote:
Gabriel Gruber wrote:
Hi Joe,
well, I don't have a replayable scenario yet (f.i. testcase), but it
seems that the exception comes after heavy use of cocoon pages within
our application.
I suspect that cocoon:/ protocol usage AND/OR inheritence of sitemap
calling (we extend cocoon-forms block to override specific resources)
might be the root of problem. But that is only a guess...
We are using latest trunk versions of servlet-service-framework and jnet
subprojects. I know that Grek made some changes in cocoon servlet
service framework in summer 2009, which went into the 1.2 release, which
we are using (since then no changes have been comitted).
The problems reported here (exact same problem we have)
http://jira.dspace.org/jira/browse/DS-253?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel
I had a look at the JNet code and haven't found a cause for your
problems. The list of URLStreamHandlerFactory objects is stored in a
thread local.
I propose that you add extensive logging to
org.apache.cocoon.jnet.URLHandlerFactoryCollector,
org.apache.cocoon.jnet.DynamicURLStreamHandlerFactory and
org.apache.cocoon.jnet.URLStreamHandlerFactoryInstaller
Then create a special logging target for all org.apache.cocoon.jnet
messages and make sure that you also log the tread ids.
Then try to reproduce your problems and you should get a hint from the
logs what could be the cause of empty lists.
Maybe you can also provide a patch with the logging statements.
It might also be interesting to see, whether the exceptions changes (or
disappears) if you change line 42 of
o.a.c.jnet.DynamicURLStreamHandlerFactory to
list = Collections.synchronizedList(new
LinkedListURLStreamHandlerFactory());
Steven and I experimented with linked lists today and didn't find a way
to produce a NPE as long as only a single thread accesses it. Those
exceptions only occur in the case of multiple threads modifying it
without synchronization.
So I expect that this change will just lead to an
IndexOutOfBoundException ...
--
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 reinh...@apache.org
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
---End Message---
Re: How to test?
David Legg wrote:
I thought I'd give C3 a go but I appear to have a couple of artifacts
missing when I run Maven. They are: -
com.sun.jersey:jersey-core:jar:1.0.3
com.sun.jersey:jersey-server:jar:1.0.3
I've tried making sure I'm using the 'cocoon-staging' profile mentioned
in the email but to no effect. It is getting late here now but tomorrow
I'll try manually installing the missing jar files and try again.
The Maven error looks as follows: -
D:\projects\cocoon\cocoon3\mysamplemvn jetty:run -P cocoon-staging
...
[INFO] Failed to resolve artifact.
...
Missing:
--
1) com.sun.jersey:jersey-core:jar:1.0.3
Try downloading the file manually from the project website.
Path to dependency:
1) com.mycompany:mysample:jar:1.0-SNAPSHOT
2) com.sun.jersey:jersey-core:jar:1.0.3
...
2) com.sun.jersey:jersey-server:jar:1.0.3
Try downloading the file manually from the project website.
Path to dependency:
1) com.mycompany:mysample:jar:1.0-SNAPSHOT
2) com.sun.jersey:jersey-server:jar:1.0.3
...
--
2 required artifacts are missing.
for artifact:
com.mycompany:mysample:jar:1.0-SNAPSHOT
from the specified remote repositories:
cocoon.staging (http://people.apache.org/builds/cocoon),
central (http://repo1.maven.org/maven2)
Thanks David! I don't know why this can happen because I built the
release artifacts on a clean machine with an empty Maven repository and
without a Maven proxy.
Anyway, I will create an alpha-3 release in February that will fix this
problem.
--
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 reinh...@apache.org
Re: [Cocoon 3] Optimizing resources creation on SAX pipeline components
Simone Tripodi wrote:
Hi Reinhard,
Thanks for your reply! I wouldn't add a dependency but rather using a
simple yet powerful ad-hoc implementation based on LinkedhashMap that
allows realizing a memory based LRU cache, I already provided an
implementation in Apache Commons Sandbox[1]. If you agree I can start
adding it and modifying the components.
The question is whether we want this store to become a pluggable
component. In Cocoon 2.x it was configurable but I have never seen
another configuration but using an in-memory store for caching XSLT
templates.
Anyway, I suggest that you start with the implementation and we discuss
configuration issues afterwards.
About making the mentioned components as CachingPipelineComponent: do
you have any hint you can suggest to me please? I'd more than pleased to
working on it!
See the org.apache.cocoon.transformation.TraxTransformer in Cocoon 2.2
and the implementation of getKey() and getValidity().
The tricky thing is that an XSLT stylesheet can have imports and
includes that can change 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 reinh...@apache.org
Re: More karma on Jira
Simone Tripodi wrote:
Hi all guys,
I need more karma on Cocoon 3 Jira to assign to me issues, start working
and resolve them. Can anyone please help me?
Thanks in adavance and have a nice weekend!!!
Simo
I added you to the Jira group cocoon-developers.
--
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 reinh...@apache.org
Re: [Cocoon 3] Optimizing resources creation on SAX pipeline components
Simone Tripodi wrote:
Hi all guys,
I'd like to improve a little the resources creation into C3 SAX
pipelines components, saving consumed memory and components
initialization time, reusing already created resources.
I mean, instantiating the same kind of XSLTTransformer (or the
SchemaProcessorTransformer) twice, in different parts of the
application, with the same resource:
class Service1 {
XSLTTransformer xsltTransformer =
new XSLTTransformer(this.getClass().getResource(myStyle.xsl));
...
}
class Service2 {
XSLTTransformer xsltTransformer =
new XSLTTransformer(this.getClass().getResource(myStyle.xsl));
...
}
causes the myStyle.xsl resource has to be load twice, consuming
memory. As proposed time ago - also mentioned by Sylvain - I'd like to
introduce an InMemoryLRU cache that stores and maintains already loaded
resources.
What do you think about it? It's a simple improvement I can realize
quickly and that's not hard to integrate in the existing code, obviously
any kind of help and suggestion is more than welcome! :)
Yes, improvements in that area are very appreciated. What solution (api)
do you propose?
And when we are at it, it would also be great to support the
CachingPipelineComponent interface in the XSLTTransformer and the
SchemaProcessorTransformer.
--
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 reinh...@apache.org
Re: Site Updates
Simone Tripodi wrote:
Hi all guys,
I modified the c3 site home page and developers list page, but it
seems not be updated; is it the site update a manual or automatic
operation? can anyone explain to me please?
It's a manual process. There is an ASF requirement that all site content
has to be put into SVN. In our case it is located a
https://svn.apache.org/repos/asf/cocoon/site/site/
Checkout this URL.
Then you have to install the Cocoon Maven site skin:
https://svn.apache.org/repos/asf/cocoon/trunk/site/cocoon-thien-maven-site-skin/
to your Maven repository.
And
mvn site-deploy -Ddocs.deploymentBaseUrl=file://[path-to-site]
from the cocoon-docs module base directory creates the site.
Then commit the newly generated content.
On the server-side, login to people.apache.org and go to
/www/cocoon.apache.org/3.0/ and call 'svn up'.
(Unfortunately there is no easier way but you could create a script at
your local machine that does everything for you.)
On my personal apache space[1] I integrated a JS code syntax
highlighter in the maven skin site, do you think could be useful
having it in the C3 site? I'd more than pleased to improve our doc,
please let me know :)
That would be great! Just go to the cocoon-thien-maven-site-skin and
change whatever you need.
--
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 reinh...@apache.org
Re: Site Updates
Simone Tripodi wrote:
Hi Reinhard,
I just modified the skin and updated the new site version - I took
time because of the maven build but everything worked fine.
I did the svn up on the server side, it updated the pages but the
don't appear updated on the browser. Is there anything I missed or the
pages are just cached?
Thanks in advance, see you!
There is some sync mechanism that copies /www/* of people.apache.org
every hour.
The site has been updated but
http://cocoon.apache.org/3.0/js/prettify.js can't be found. It's not in
/x1/www/cocoon.apache.org/3.0/js where I would expect it.
BTW, where does the prettify.js code come from (AFAICS there is no
license header).
--
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 reinh...@apache.org
[result][vote] Release Cocoon 3.0.0-alpha-2
Reinhard Pötz wrote:
This majority vote stays open for at least 72 hours. Please cast your votes!
The vote passed with 3 binding +1 votes and one non-binding one (Simone,
your vote will be binding starting with tomorrow evening, 3 days after
the acknowledgment of the ASF board of your PMC member status.)
Thanks to all for your reviews and votes.
I will take care of the synchronization of the release artifacts with
the central Maven repo and the Apache distribution area, will update the
docs and send the official announcement asap.
--
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 reinh...@apache.org
Re: [result][vote] Release Cocoon 3.0.0-alpha-2
Simone Tripodi wrote:
Hi reinhard,
don't worry, the most important thing for me is the project success,
yes I know, it was just for clarifications to others who are not that
familiar with ASF procedures and rules.
--
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 reinh...@apache.org
Re: [vote] Release Cocoon 3.0.0-alpha-2
Simone Tripodi wrote:
Hi Reinhard,
just a couple of questions before expressing my +1:
On SVN repo I found alpha2 tags out of sync the following modules:
- cocoon-all (is empty)
- cocoon-optional (is empty)
- cocoon-parent (is empty)
Thanks for spotting - I created all the release tags and updated the
tagging script. Unfortunately Maven doesn't do this out of the box (see
the 'svn-release-tags.bat' script in the root directory of Cocoon 3).
I didn't find tagged the following modules:
- cocoon-docs
directory and tag added
- cocoon-profiling-firebug
not released this time because I have to check how to properly
release/distribute Firefox/Firebug plugins.
- cocoon-sample-webapp
- cocoon-sample-wicket-webapp
Not there because it doesn't make much sense to release them because
everything is packed in a war file. In order to explore the webapp
samples, use the samples archetype.
- cocoon-sax
directory and tag added.
After downloaded both zip and tar.gz archives, I didn't find the
parent pom to build all modules: did I miss something?
It's not there on purpose because its modules section would point to
non-existing projects.
If you want to rebuild the release from its sources, you either have to
build the modules in the right order or you would have to add a root pom
yourself.
For the next release we could enhance the apache-release profile of the
'cocoon-all' module e.g. by a Groovy script that creates the root POM.
XInclude: I'm sure my patch doesn't include the sitemap integration,
and I'm very sorry for that :(
no problem. Since you'll get commit privileges very soon, you can fix it
yourself :-P
Should I integrate it before releasing
alpha2?
I would only want to rebuild the release artifacts either if there is a
serious bug or a formal issue that makes the release 'invalid' regarding
to ASF rules. Otherwise we should just ship alpha-3 asap.
Documentation: should we move my name from contributors to committers?
sorry but I'm still celebrating my graduation :P :D
:-)
You're welcome, add yourself to the parent pom, otherwise see above.
Have a nice evening, and count on me for any help you need!!!
Thanks for reviewing!
--
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 reinh...@apache.org
[vote] Release Cocoon 3.0.0-alpha-2
I've prepared the artifacts for the release of Cocoon 3.0.0-alpha-2.
Since it has been more than a year since alpha-1 was released, there are
many improvements and enhancements:
Pipeline API level
~~~
. Add generics to the pipeline interface. With additionally introducing
marker interfaces for the component types (SAX, StAX, etc.) this allows
compile time checks if all components have the correct type when
assembling the pipeline
. Use MurmurHash 2.0, a strong hashing algorithm, to implement the
hashCode() method of cache keys.
. Introduce an exception hierarchy for pipeline components
(ProcessingException and SetupException extend both PipelineException).
. Create a separate SAX module that contains all SAX specific classes
. Provide basic component implementations of StAX pipeline components
(new module: 'cocoon-stax')
. Add a new module 'cocoon-optional' for components that need external
libraries (i.e. everything that goes beyond JDK5, commons-logging and
cocoon-sax)
New components:
. XMLGenerator (constructors for File, InputStream, String, Node,
SAXBuffer) [cocoon-sax]
. XIncludeTransformer [cocoon-sax]
. SchemaProcessorTransformer [cocoon-sax]
. Add factory methods to o.a.c.sax.component.XMLSerializer to create
properly configured serializers for XML, XHTML and HTML4 [cocoon-sax]
. FOPSerializer [cocoon-optional]
. NekoHTMLGenerator [cocoon-optional]
. BetwixtBeanGenerator [cocoon-optional]
Sitemap level
~~~
Only minor changes
Webapplication level
~~~
. REST controller (new module: 'cocoon-rest')
. JAX-RS based controllers (JSR 311)
. Automatic conditional GET support for all caching pipelines.
(ETag and Last-Modified are supported)
. Wicket integration in both ways (new module: 'cocoon-wicket')
. JMX based monitoring: Cache overview, reconfiguration of logging,
Servlet-Service-Framework overview (new module: 'cocoon-monitoring')
. SSF/Sitemap/Pipeline profiling (new module: 'cocoon-profiling'
. Update to Spring 2.5.6
Find all details at http://cocoon.apache.org/3.0/changes-report.html.
You can find the staged files for all modules (sources, binaries,
javadocs, checksums, gpg signatures) at
http://people.apache.org/builds/cocoon/
SVN tags of all these artifacts can be found at
http://svn.apache.org/repos/asf/cocoon/cocoon3/tags/
The general distribution artifacts (tar, zip) are available at
http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-2/cocoon-all-3.0.0-alpha-2-dist.zip
http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-2/cocoon-all-3.0.0-alpha-2-dist.zip.asc
http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-2/cocoon-all-3.0.0-alpha-2-dist.zip.md5
http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-2/cocoon-all-3.0.0-alpha-2-dist.zip.sha1
http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-2/cocoon-all-3.0.0-alpha-2-dist.tar.gz
http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-2/cocoon-all-3.0.0-alpha-2-dist.tar.gz.asc
http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-2/cocoon-all-3.0.0-alpha-2-dist.tar.gz.md5
http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-2/cocoon-all-3.0.0-alpha-2-dist.tar.gz.sha1
I want to stress again that this is an alpha release. This means that we
are free to change contracts without following any deprecation rules.
See http://cocoon.apache.org/3.0/alpha-warning.html
This majority vote stays open for at least 72 hours. Please cast your votes!
--
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 reinh...@apache.org
Re: [vote] Release Cocoon 3.0.0-alpha-2
Reinhard Pötz wrote:
I've prepared the artifacts for the release of Cocoon 3.0.0-alpha-2.
Since it has been more than a year since alpha-1 was released, there are
many improvements and enhancements:
Pipeline API level
~~~
. Add generics to the pipeline interface. With additionally introducing
marker interfaces for the component types (SAX, StAX, etc.) this allows
compile time checks if all components have the correct type when
assembling the pipeline
. Use MurmurHash 2.0, a strong hashing algorithm, to implement the
hashCode() method of cache keys.
. Introduce an exception hierarchy for pipeline components
(ProcessingException and SetupException extend both PipelineException).
. Create a separate SAX module that contains all SAX specific classes
. Provide basic component implementations of StAX pipeline components
(new module: 'cocoon-stax')
. Add a new module 'cocoon-optional' for components that need external
libraries (i.e. everything that goes beyond JDK5, commons-logging and
cocoon-sax)
New components:
. XMLGenerator (constructors for File, InputStream, String, Node,
SAXBuffer) [cocoon-sax]
. XIncludeTransformer [cocoon-sax]
. SchemaProcessorTransformer [cocoon-sax]
. Add factory methods to o.a.c.sax.component.XMLSerializer to create
properly configured serializers for XML, XHTML and HTML4 [cocoon-sax]
. FOPSerializer [cocoon-optional]
. NekoHTMLGenerator [cocoon-optional]
. BetwixtBeanGenerator [cocoon-optional]
Sitemap level
~~~
Only minor changes
Webapplication level
~~~
. REST controller (new module: 'cocoon-rest')
. JAX-RS based controllers (JSR 311)
. Automatic conditional GET support for all caching pipelines.
(ETag and Last-Modified are supported)
. Wicket integration in both ways (new module: 'cocoon-wicket')
. JMX based monitoring: Cache overview, reconfiguration of logging,
Servlet-Service-Framework overview (new module: 'cocoon-monitoring')
. SSF/Sitemap/Pipeline profiling (new module: 'cocoon-profiling'
. Update to Spring 2.5.6
Find all details at http://cocoon.apache.org/3.0/changes-report.html.
You can find the staged files for all modules (sources, binaries,
javadocs, checksums, gpg signatures) at
http://people.apache.org/builds/cocoon/
SVN tags of all these artifacts can be found at
http://svn.apache.org/repos/asf/cocoon/cocoon3/tags/
The general distribution artifacts (tar, zip) are available at
http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-2/cocoon-all-3.0.0-alpha-2-dist.zip
http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-2/cocoon-all-3.0.0-alpha-2-dist.zip.asc
http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-2/cocoon-all-3.0.0-alpha-2-dist.zip.md5
http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-2/cocoon-all-3.0.0-alpha-2-dist.zip.sha1
http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-2/cocoon-all-3.0.0-alpha-2-dist.tar.gz
http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-2/cocoon-all-3.0.0-alpha-2-dist.tar.gz.asc
http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-2/cocoon-all-3.0.0-alpha-2-dist.tar.gz.md5
http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-2/cocoon-all-3.0.0-alpha-2-dist.tar.gz.sha1
I want to stress again that this is an alpha release. This means that we
are free to change contracts without following any deprecation rules.
See http://cocoon.apache.org/3.0/alpha-warning.html
This majority vote stays open for at least 72 hours. Please cast your votes!
+1
--
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 reinh...@apache.org
How to test? (was: [vote] Release Cocoon 3.0.0-alpha-2)
(Note: Those instructions require the usage of Maven 2. If you want to
use/test Cocoon without Maven, pls let me know.)
If you already use Cocoon 3 the best way to test is setting the version
to 3.0.0-alpha-2, e.g.:
dependency
groupIdorg.apache.cocoon.sax/groupId
artifactIdcocoon-sax/artifactId
version3.0.0-alpha-2/version
/dependency
If you want to explore how a Cocoon 3 web application works, use the
'Samples Archetype':
mvn org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7:create
-DarchetypeGroupId=org.apache.cocoon.archetype-sample
-DarchetypeArtifactId=cocoon-archetype-sample
-DarchetypeVersion=3.0.0-alpha-2 -DgroupId=com.mycompany
-DartifactId=mysample
-DremoteRepositories=http://people.apache.org/builds/cocoon/
Then move into the base directory and run
mvn jetty:run -P cocoon-staging
Make sure that the 'cocoon-staging' profile is set in your
~/.m2/settings.xml:
profile
idcocoon-staging/id
repositories
repository
idcocoon.staging/id
nameCocoon staging repository/name
urlhttp://people.apache.org/builds/cocoon/url
/repository
/repositories
pluginRepositories
pluginRepository
idcocoon.staging/id
nameCocoon staging repository/name
urlhttp://people.apache.org/builds/cocoon/url
/pluginRepository
/pluginRepositories
/profile
In order to start a new Cocoon 3 webapp project, use one of the
following archetypes:
mvn org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7:create
-DarchetypeGroupId=org.apache.cocoon.archetype-block
-DarchetypeArtifactId=cocoon-archetype-block
-DarchetypeVersion=3.0.0-alpha-2 -DgroupId=com.mycompany
-DartifactId=mysite
-DremoteRepositories=http://people.apache.org/builds/cocoon/
mvn org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7:create
-DarchetypeGroupId=org.apache.cocoon.archetype-parent
-DarchetypeArtifactId=cocoon-archetype-parent
-DarchetypeVersion=3.0.0-alpha-2 -DgroupId=com.mycompany
-DartifactId=myparent
-DremoteRepositories=http://people.apache.org/builds/cocoon/
mvn org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7:create
-DarchetypeGroupId=org.apache.cocoon.archetype-webapp
-DarchetypeArtifactId=cocoon-archetype-webapp
-DarchetypeVersion=3.0.0-alpha-2 -DgroupId=com.mycompany
-DartifactId=mywebapp
-DremoteRepositories=http://people.apache.org/builds/cocoon/
Again, make sure that you activate the 'cocoon-staging' profile when you
build your project.
One final note, all Cocoon artifacts require Maven 2.0.9 or higher.
Otherwise the transitive dependency resolution of Maven doesn't work
properly.
--
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 reinh...@apache.org
SSH connection to cocoon.zones.apache.org
I try to login at cocoon.zones.apache.org but can't even establish a SSH
connection. Is it only me or do others have the same problem?
--
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 reinh...@apache.org
Re: Release Cocoon 3.0.0-alpha-2
Simone Tripodi wrote:
Hi Reinhard,
count on me to fix the open issues, let's have a chat if you already
have an idea how to fix them so I can provide you the help needed.
Have a nice evening,
In Jira there aren't any bugs but only improvements or ideas left and I
moved them to alpha-3 because I don't want to delay the release.
Or do you refer to something else?
That said I probably won't have enough time before Christmas do actually
work on the release. So if you have some spare time, just go ahead!
--
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 reinh...@apache.org
Re: [VOTE] Release cocoon-xml 2.0.2
Carsten Ziegeler wrote:
Hi,
I've assembled a release candidate for the xml sub project.
This is just a maintenance release which adds the license and notice
files to the jar and corrects some OSGi manifest headers.
The code is the same as the 2.0.0 release.
The release candidate can be found here:
http://people.apache.org/builds/cocoon/org/apache/cocoon/cocoon-xml/2.0.2/
Please cast your votes.
Works fine with C3, +1
--
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 reinh...@apache.org
Re: Release Cocoon 3.0.0-alpha-2
Reinhard Pötz wrote:
Reinhard Pötz wrote:
I plan to do a release of Cocoon 3.0.0-alpha-2 at the first half of
August. If there is anything that you want to see fixed/included, let me
know or provide a patch in time.
Of course this also means that I will go through the list of all
available patches and bug reports in Jira and will try to resolve them.
I was busier in Aug/Sept than expected and didn't have enough time. In
the next two weeks I will concentrate on the C3 docs and then create the
release artifacts in the last week of October.
Is there anything that speaks against this time plan?
I'm going to create the release artifacts as soon as cocoon-xml 2.0.2 is
available from the central Maven repo.
--
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 reinh...@apache.org
[result][vote] Simone Tripodi as new Cocoon committer
Reinhard Pötz wrote:
I propose Simone Tripodi as a new Cocoon committer and PMC member.
Simone has been participating on our mailing lists since Sept 2008.
Recently he provided an extensive patch that adds XInclude support to
Cocoon 3. Additionally he provided 6 other patches.
That shows that his interest in Cocoon is longer-term which he also
confirmed at some chats that we both had.
This vote ends one week from today, i.e. midnight UTC on Sunday 2009-12-20
So please cast your votes.
Simone's nomination has been accepted. He got 12 positive votes and no
negative one. Congratulations Simone and welcome!
Simone, if you accept your nomination, please get familiar with
http://www.apache.org/dev/new-committers-guide.html and send your signed
CLA to the ASF Secretary.
Please also let me know which user id you prefer and what your
forwarding email address is.
It's also a good tradition here to introduce yourself.
--
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 reinh...@apache.org
Re: SAXGenerator - URLGenerator
Joerg Heinicke wrote:
On 14.12.2009 09:33, Reinhard Pötz wrote:
On Sun, Dec 13, 2009 at 3:59 PM, Joerg
Heinickejoerg.heini...@gmx.de wrote:
A long time ago I argued for renaming the FileGenerator to XMLGenerator
since the generators are usually named after the input they accept
(Midi,
HTML, Directory, JSP, JXTemplate, etc.). I'm not sure SAXGenerator
reflects
that exactly but it's good enough I guess.
I agree that we should have one consistent naming scheme and since we
usually use the input type, we shouldn't change it for this case.
I see two solutions in order to get a consistent naming of our
components:
a) We rename SAXGenerator AND StAXGenerator to XMLGenerator
or
b) We add the SAX prefix to all pipeline components.
I'm in favor of a) because SAX or StAX is already part of the package
name and looking at the implemented interfaces makes it clear what
underlying event mechanism is used.
I agree with your reasoning.
Thanks! Since none objected, I've just committed the changes. The
SAXGenerator/FileGenerator is called XMLGenerator and I also renamed the
StAXGenerator and StAXSerializer to XMLGenerator and XMLSerializer.
--
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 reinh...@apache.org
Re: SAXGenerator - URLGenerator
Simone Tripodi wrote:
Hi all,
I'd follow the Joerg suggestion since it reminded me the Neko HTML
Generator included in the optional module that has the behavior
similar to the old FileGenerator that takes an URL in input and
transforms HTML in XHTML.
At that point I'd suggest to have an AbstractGenerator that manipulate
an URL stream, than having different specialization, like:
*) SAXGenerator
*) NekoGenerator
*) Anyhing else?
How does it sound?
Simo
On Sun, Dec 13, 2009 at 3:59 PM, Joerg Heinicke joerg.heini...@gmx.de wrote:
On 13.12.2009 14:44, Reinhard Pötz wrote:
Long time ago (I think when the StAX module was added) we discussed to
have a SAXGenerator which is mainly useful when the pipeline API is
used. It has constructors for File, InputStream, String and Node. See
http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-sax/src/main/java/org/apache/cocoon/sax/component/SAXGenerator.java
I also renamed FileGenerator to URLGenerator because this better
reflects what it really does.
But thinking more about this it would also make sense to merge the
URLGenerator into the SAXGenerator.
WDYT?
A long time ago I argued for renaming the FileGenerator to XMLGenerator
since the generators are usually named after the input they accept (Midi,
HTML, Directory, JSP, JXTemplate, etc.). I'm not sure SAXGenerator reflects
that exactly but it's good enough I guess.
I agree that we should have one consistent naming scheme and since we
usually use the input type, we shouldn't change it for this case.
I see two solutions in order to get a consistent naming of our components:
a) We rename SAXGenerator AND StAXGenerator to XMLGenerator
or
b) We add the SAX prefix to all pipeline components.
I'm in favor of a) because SAX or StAX is already part of the package
name and looking at the implemented interfaces makes it clear what
underlying event mechanism is used.
--
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 reinh...@apache.org
Re: New release of the xml subproject
Carsten Ziegeler wrote:
Hi,
I just fixed COCOON-2274
(https://issues.apache.org/jira/browse/COCOON-2274)
which adds the license and notice files into the jar and fixes some OSGi
header information.
I would like to do a new release. Any comments/objections?
I was thinking the same when I saw Jukka's issue. Go ahead!
--
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 reinh...@apache.org
Re: Building blocks with cocoon3
Thorsten Scherler wrote:
Hi all,
I am trying to develop a new cocoon3 block but I get an error when
starting jetty.
snip/
I'm going to have a look into this issue before creating the alpha-2
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 reinh...@apache.org
Re: Cocoon documentation
Thorsten Scherler wrote:
On Fri, 2009-12-04 at 12:09 +0100, Reinhard Pötz wrote:
...
See
http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-docs/src/docbkx/reference/
You can generate the documentation yourself by invoking 'mvn site' from
the base directory of the cocoon-docs module.
I tried that but I get:
...
[INFO] Unable to find resource
'org.apache.cocoon:cocoon-thien-maven-site-skin:jar:1.0.0-SNAPSHOT' in
repository apache.snapshots
(http://people.apache.org/repo/m2-snapshot-repository)
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] The skin does not exist: Unable to download the artifact from any
repository
How can I fix this?
Cocoon 2.2 trunk contains the cocoon-thien-maven-site-skin
(http://svn.apache.org/repos/asf/cocoon/trunk/site/cocoon-thien-maven-site-skin/pom.xml).
Either your build (mvn install) the complete Cocoon 2.2 trunk or you
only build (mvn install) the parent POM and the site skin.
I will also release the site skin so that it is available at the central
Maven 2 repo.
--
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 reinh...@apache.org
