Re: Cocoon-trunk Build # 123 - Still Failing [WAS Re: Cocoon-trunk - Build # 122 - Failure]
On Thu, 2011-12-29 at 18:07 +0100, Francesco Chicchiriccò wrote: On 29/12/2011 15:50, Thorsten Scherler wrote: On Thu, 2011-12-29 at 14:01 +, Apache Jenkins Server wrote: The Apache Jenkins build system has built Cocoon-trunk (build #122) Status: Failure Check console output at https://builds.apache.org/job/Cocoon-trunk/122/ to view the results. Hmm, weird. Not sure what is wrong with Jenkins, but in my system I actually had to set MAVEN_OPTS=-Xmx256m -XX:PermSize=128m -XX:MaxPermSize=128m to start it.sh and build successful. Maybe same prob for J but not sure since the NPE could be about anything. Let us see the next build. Uhm, build 123 went wrong as well, with same meaningless NPE :-( Any idea? The only one regarding the MAVEN_OPTS. ...but https://builds.apache.org/job/Cocoon-trunk/123/consoleFull [trunk] $ /home/hudson/tools/java/latest1.6/bin/java -Xmx768m -Xms768m -client -XX:MaxPermSize=256m It actually gives the build more Perm then I do. :( It builds fine on my box and the one of my colleague. Further we have setup a jenkins for our current project that as well builds c3 as part of the main project and that is working fine as well (for all commits since 24.11 or r1203644). The only thing that I see is that is doing and svn up on the same files between 122 and 123 (in the latter there a couple more but is 122 +). Further it does not make sense that 122 is failing in the parent, since it does not have even changes in parent/pom.xml (At revision 1225536) Further in 123 it goes to r1225592 and getting the same files at before (even more), where it should heve done only: thorsten@mcKenny:~/src/apache/c3$ svnu U cocoon-archetype-parent/src/main/resources/archetype-resources/pom.xml Updated to revision 1225602. Shot in the dark some underlying os issue, being it disk full or something similar. Maybe we should ping infra? salu2 -- Thorsten Scherler thorsten.at.apache.org codeBusters S.L. - web based systems consulting, training and solutions http://www.codebusters.es/
[jira] [Commented] (COCOON3-85) cocoon-spring-configurator doesn't work with latest ( 1.6.6) AspectJ's static optimizer
[
https://issues.apache.org/jira/browse/COCOON3-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13177200#comment-13177200
]
Francesco Chicchiriccò commented on COCOON3-85:
---
@Thorsten I've just tried to reproduce the issue with StringTemplate generator
with no luck: no my laptop (Linux 3.1 64bit / OpenJDK 6.0.23) it runs smoothly.
cocoon-spring-configurator doesn't work with latest ( 1.6.6) AspectJ's
static optimizer
Key: COCOON3-85
URL: https://issues.apache.org/jira/browse/COCOON3-85
Project: Cocoon 3
Issue Type: Bug
Components: cocoon-servlet
Affects Versions: 3.0.0-alpha-1, 3.0.0-alpha-2, 3.0.0-alpha-3, 3.0.0-beta-1
Reporter: Igor Malinin
Fix For: 3.0.0-beta-1
Attachments: java.patch
As reported at first in mailing list [1], AspectJ's static optimizer was
reviewed starting from 1.6.7 onward.
A temporary workaround for this is to force usage of version 1.6.6 of AspectJ
(quite ancient right now).
At the moment Cocoon 3 is using latest Spring (3.1) and AspectJ (1.6.12)
versions.
With Spring 3.1, this workaround is not enough any more.
One issue I reported already in mailing list when Jetty7 + recent AspectJ was
failing, not the same issue is deeper and ServletContextFactoryBean doesn't
work at all with Spring 3.1.
Note that ServletContext is already in the Spring web-app context, although
with another name ('servletContext'). This is available starting from Spring
3.0. Making an alias 'javax.servlet.ServletContext' - 'servletContext'
solves problem partially, but still fails on XMLSitemapServlet initialization
(as it uses static field in ServletContextFactoryBean).
I will attach a patch (a little bit dirty, but not more than the current
implementation). But it assumes at least Spring 3.0.
As Cocoon 3 project is moved to Java 1.6, it is probably also worth to have
as a dependency at leas 3.0 version of Spring Framework (for Java5 generics
etc.)
[1]
http://old.nabble.com/Jetty-7---%22can%27t-determine-modifiers-of-missing-type-org.eclipse.jetty.webapp.WebAppContext$Context%22-error-td32314839.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: c3 version update (was Re: svn commit: r1224754 )
On 29/12/2011 12:28, Thorsten Scherler wrote: On Mon, 2011-12-26 at 16:40 +, ilgro...@apache.org wrote: Author: ilgrosso Date: Mon Dec 26 16:40:43 2011 New Revision: 1224754 URL: http://svn.apache.org/viewvc?rev=1224754view=rev Log: Updating to Spring 3.1 (+ other version updates) Modified: cocoon/cocoon3/trunk/cocoon-rest/pom.xml cocoon/cocoon3/trunk/cocoon-sample/pom.xml cocoon/cocoon3/trunk/parent/pom.xml Hi Francesco, hi devs, thanks for updating the pom. One small observation since I just updated the parent pom of our client project. https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-archetype-parent/src/main/resources/archetype-resources/pom.xml This pom is way outdated and maybe need to enter in the version update cycle. I am not sure whether we can actually generate that pom automatically based on the c3 parent one (which would save us the double version maintenance) but we cannot have it as outdated as now since it is the start for new developments around c3. Hi Thorsten, I've just (manually) aligned archetype's parent POM with parent POM. I don't know too if there is an automatic way to keep these two in sync: I'll keep in mind to update both for the future. Regards. -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
[jira] [Commented] (COCOON3-85) cocoon-spring-configurator doesn't work with latest ( 1.6.6) AspectJ's static optimizer
[
https://issues.apache.org/jira/browse/COCOON3-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13177216#comment-13177216
]
Thorsten Scherler commented on COCOON3-85:
--
I am At revision 1225548.
uname -rios
Linux 3.0.0-14-generic x86_64 GNU/Linux
java -version
java version 1.6.0_25
Java(TM) SE Runtime Environment (build 1.6.0_25-b06)
Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed mode)
c3/cocoon-sample$ mvn clean install jetty:run
now works, weird seems the clean did the trick, sorry for the noise and
thanks for testing.
cocoon-spring-configurator doesn't work with latest ( 1.6.6) AspectJ's
static optimizer
Key: COCOON3-85
URL: https://issues.apache.org/jira/browse/COCOON3-85
Project: Cocoon 3
Issue Type: Bug
Components: cocoon-servlet
Affects Versions: 3.0.0-alpha-1, 3.0.0-alpha-2, 3.0.0-alpha-3, 3.0.0-beta-1
Reporter: Igor Malinin
Fix For: 3.0.0-beta-1
Attachments: java.patch
As reported at first in mailing list [1], AspectJ's static optimizer was
reviewed starting from 1.6.7 onward.
A temporary workaround for this is to force usage of version 1.6.6 of AspectJ
(quite ancient right now).
At the moment Cocoon 3 is using latest Spring (3.1) and AspectJ (1.6.12)
versions.
With Spring 3.1, this workaround is not enough any more.
One issue I reported already in mailing list when Jetty7 + recent AspectJ was
failing, not the same issue is deeper and ServletContextFactoryBean doesn't
work at all with Spring 3.1.
Note that ServletContext is already in the Spring web-app context, although
with another name ('servletContext'). This is available starting from Spring
3.0. Making an alias 'javax.servlet.ServletContext' - 'servletContext'
solves problem partially, but still fails on XMLSitemapServlet initialization
(as it uses static field in ServletContextFactoryBean).
I will attach a patch (a little bit dirty, but not more than the current
implementation). But it assumes at least Spring 3.0.
As Cocoon 3 project is moved to Java 1.6, it is probably also worth to have
as a dependency at leas 3.0 version of Spring Framework (for Java5 generics
etc.)
[1]
http://old.nabble.com/Jetty-7---%22can%27t-determine-modifiers-of-missing-type-org.eclipse.jetty.webapp.WebAppContext$Context%22-error-td32314839.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COCOON3-85) cocoon-spring-configurator doesn't work with latest ( 1.6.6) AspectJ's static optimizer
[
https://issues.apache.org/jira/browse/COCOON3-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13177189#comment-13177189
]
Thorsten Scherler commented on COCOON3-85:
--
Actually @Francesco r1224754 broke the Stringtemplate example, meaning it
seems that everything is fine but in runtime that is not like that any more. It
seems as Igor described a problem of the class loader. Not sure though whether
it is fault of the RCL or the configurator, but I will try now to apply the
patch on my system and look whether that solves the problem.
To reproduce,
* just mvn clean install current Head
* cd cocoon-sample
* mvn jetty:run
* http://localhost:/string-template/generator - BANG!
{{{
2011-12-29 15:08:16.138:INFO:/:Initializing Spring root WebApplicationContext
2011-12-29 15:08:19.347:INFO:/:Apache Cocoon Spring Configurator v2.1.0 is
running in mode 'dev'.
2011-12-29 15:08:23.468:INFO:/:DispatcherServlet: Block dispatcher was
initialized successfully.
2011-12-29 15:08:23.581:INFO::Started SelectChannelConnector@0.0.0.0:
[INFO] Started Jetty Server
2011-12-29 15:08:35.365:INFO:/:Apache Cocoon Spring Configurator v2.1.0 is
running in mode 'dev'.
java.lang.Error: Unresolved compilation problem:
STRenderer cannot be resolved
at
org.apache.cocoon.stringtemplate.StringTemplateGenerator.renderTemplate(StringTemplateGenerator.java:152)
at
org.apache.cocoon.stringtemplate.StringTemplateGenerator.execute(StringTemplateGenerator.java:172)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:318)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:91)
at
org.apache.cocoon.profiling.aspects.InvocationDispatcher.dispatch(InvocationDispatcher.java:68)
at
org.apache.cocoon.profiling.aspects.PipelineComponentProfilingAspect.handleInvocation(PipelineComponentProfilingAspect.java:41)
at sun.reflect.GeneratedMethodAccessor73.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:621)
at
org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:610)
at
org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:65)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:90)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
at $Proxy46.execute(Unknown Source)
at
org.apache.cocoon.pipeline.AbstractPipeline.invokeStarter(AbstractPipeline.java:150)
at
org.apache.cocoon.pipeline.AbstractPipeline.execute(AbstractPipeline.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:318)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:80)
at
org.apache.cocoon.servlet.collector.ResponseHeaderCollector.interceptInvoke(ResponseHeaderCollector.java:94)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
Re: c3 version update (was Re: svn commit: r1224754 )
... Hi Thorsten, I've just (manually) aligned archetype's parent POM with parent POM. I don't know too if there is an automatic way to keep these two in sync: I'll keep in mind to update both for the future. Thank you very much! The thing is that we even have more components that needs a sync (like the block and war pom of the architypes). Old school Ant would use a xsl transform of the underlying pom, remove all obsolete lines and copy it to the architypes. I am sre we could do something similar with maven but sadly I have no time to look into that right now. salu2 -- Thorsten Scherler thorsten.at.apache.org codeBusters S.L. - web based systems consulting, training and solutions http://www.codebusters.es/
Cocoon-trunk Build # 123 - Still Failing [WAS Re: Cocoon-trunk - Build # 122 - Failure]
On 29/12/2011 15:50, Thorsten Scherler wrote: On Thu, 2011-12-29 at 14:01 +, Apache Jenkins Server wrote: The Apache Jenkins build system has built Cocoon-trunk (build #122) Status: Failure Check console output at https://builds.apache.org/job/Cocoon-trunk/122/ to view the results. Hmm, weird. Not sure what is wrong with Jenkins, but in my system I actually had to set MAVEN_OPTS=-Xmx256m -XX:PermSize=128m -XX:MaxPermSize=128m to start it.sh and build successful. Maybe same prob for J but not sure since the NPE could be about anything. Let us see the next build. Uhm, build 123 went wrong as well, with same meaningless NPE :-( Any idea? -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
Re: Cocoon-trunk - Build # 122 - Failure
On Thu, 2011-12-29 at 14:01 +, Apache Jenkins Server wrote: The Apache Jenkins build system has built Cocoon-trunk (build #122) Status: Failure Check console output at https://builds.apache.org/job/Cocoon-trunk/122/ to view the results. Hmm, weird. Not sure what is wrong with Jenkins, but in my system I actually had to set MAVEN_OPTS=-Xmx256m -XX:PermSize=128m -XX:MaxPermSize=128m to start it.sh and build successful. Maybe same prob for J but not sure since the NPE could be about anything. Let us see the next build. salu2 -- Thorsten Scherler thorsten.at.apache.org codeBusters S.L. - web based systems consulting, training and solutions http://www.codebusters.es/ smime.p7s Description: S/MIME cryptographic signature
[jira] [Issue Comment Edited] (COCOON3-85) cocoon-spring-configurator doesn't work with latest ( 1.6.6) AspectJ's static optimizer
[ https://issues.apache.org/jira/browse/COCOON3-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13177189#comment-13177189 ] Thorsten Scherler edited comment on COCOON3-85 at 12/29/11 2:23 PM: Actually @Francesco r1224754 broke the Stringtemplate example, meaning it seems that everything is fine but in runtime that is not like that any more. It seems as Igor described a problem of the class loader. Not sure though whether it is fault of the RCL or the configurator, but I will try now to apply the patch on my system and look whether that solves the problem. To reproduce, * just mvn clean install current Head * cd cocoon-sample * mvn jetty:run * http://localhost:/string-template/generator - BANG! pre 2011-12-29 15:08:16.138:INFO:/:Initializing Spring root WebApplicationContext 2011-12-29 15:08:19.347:INFO:/:Apache Cocoon Spring Configurator v2.1.0 is running in mode 'dev'. 2011-12-29 15:08:23.468:INFO:/:DispatcherServlet: Block dispatcher was initialized successfully. 2011-12-29 15:08:23.581:INFO::Started SelectChannelConnector@0.0.0.0: [INFO] Started Jetty Server 2011-12-29 15:08:35.365:INFO:/:Apache Cocoon Spring Configurator v2.1.0 is running in mode 'dev'. java.lang.Error: Unresolved compilation problem: STRenderer cannot be resolved at org.apache.cocoon.stringtemplate.StringTemplateGenerator.renderTemplate(StringTemplateGenerator.java:152) at org.apache.cocoon.stringtemplate.StringTemplateGenerator.execute(StringTemplateGenerator.java:172) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:318) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:91) at org.apache.cocoon.profiling.aspects.InvocationDispatcher.dispatch(InvocationDispatcher.java:68) at org.apache.cocoon.profiling.aspects.PipelineComponentProfilingAspect.handleInvocation(PipelineComponentProfilingAspect.java:41) at sun.reflect.GeneratedMethodAccessor73.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:621) at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:610) at org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:65) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:90) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202) at $Proxy46.execute(Unknown Source) at org.apache.cocoon.pipeline.AbstractPipeline.invokeStarter(AbstractPipeline.java:150) at org.apache.cocoon.pipeline.AbstractPipeline.execute(AbstractPipeline.java:80) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:318) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:80) at org.apache.cocoon.servlet.collector.ResponseHeaderCollector.interceptInvoke(ResponseHeaderCollector.java:94) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
Re: [C3] Import subprojects proposal [WAS: Re: [c3] Log4j injection in target of blocks]
On Sat, 2011-12-24 at 17:33 +0100, Francesco Chicchiriccò wrote: On 01/12/2011 21:47, Simone Tripodi wrote: Hi all guys! Apologies for the lack of participations but looks like contributing in more ASF communities requires a lot of time! :) My position are: * +1 on migrating old components - that's true that we could maintain them in their proper branch, but at the same time they would need an update to be more compliant with C3 - moreover, since we agreed on migrating to Java6, it would worth started getting advantage from the new platform - that would imply subprojects actualization. * +1 on restructuring the svn, I would like to restructure anyway the C3 first: IMHO having all the modules in a flat structures starts being a little confusing, even to me that I'm involved, I would suggest to move to a different hierarchical structure, grouping modules by technology/extension type/application type. Moreover IMHO the 'optional' module should be split, it contains now a lot of good reusable - more that at the begin - stuff that we could consider as a collection of modules. Of course, we have to pay attention to not overengineering. I would suggest as well to open a Sandbox open to all ASF committers to experiment new modules. My proposal is considering the two topics separately, I would like Francesco lead the topic #1, I can prepare during the weekend a proposal on how to restructure the SVN. Hi all, first of all, apologies for delay :-) Here it follows some results from my investigation of our current SVN repository (from root to branches someone would have said...) and also a proposal of mine for making things a bit easier to work with. I'll take the current structure at https://svn.apache.org/repos/asf/cocoon/ as reference and base URL. */branches/* Move current /trunk/ under here as BRANCH_2_2_X (similar to BRANCH_2_1_X and others, already present) so that any further activity on C2.2 can take place here. */cocoon3/* Move /cocoon3/trunk as /trunk/ (Simone restructuring as presented above will take place here) and /cocoon3/tags/** under /tags, possibly refactoring paths like as /cocoon3/tags/cocoon-archetype-block/cocoon-archetype-block-3.0.0-alpha-3/ to simpler /tags/cocoon-archetype-block-3.0.0-alpha-3/ */site/* Merge this with current /cocoon3/trunk/cocoon-docs */tags/* As said above for /cocoon3, move /cocoon3/tags/* here, possibly refactoring paths */trunk/* As said above for /cocoon3, move /cocoon3/trunk/* here. Then, copy current trunk/subprojects/ (i.e. /branches/BRANCH_2_2_X/subprojects/ after refactoring): cocoon-block-deployment/ cocoon-configuration/ cocoon-jnet/ cocoon-servlet-service/ cocoon-xml/ Next, copy some modules from current trunk/tools/ (i.e. /branches/BRANCH_2_2_X/tools/ after refactoring): cocoon-it-fw/ cocoon-maven-plugin/ cocoon-rcl/ Finally, copy from current trunk/blocks/cocoon-serializers/ (i.e. /branches/BRANCH_2_2_X/blocks/cocoon-serializers/ after refactoring): cocoon-serializers-charsets/ All modules involved with C3 should have now their places under /trunk/subprojects/ or /trunk/tools. If there is any module missing please let me know. We will need, of course, to adapt all pom.xml's for working in the new structure. WDYT? Not 100% sure. ATM we have: * branches/ * cocoon3/ * site/ * tags/ * trunk/ * whiteboard/ Which IMO should become: branches/ (2.X) site/ tags/ trunk/ (cocoon3/) whiteboard/ subprojects/ tools/ Where within subproject/tools we would apply the branches|tags|trunk structure. This way we can have a tag/branch for e.g. the cocoon-spring-configurator for the 2.2 deps and sub-trunk against our main-trunk. Further that would allow us to extract common code to a module in tools/subproject. Makes sense? Regarding site see David comment. The main problem here is that we have a wide range of build tools which originally build our docu (mainly forrest till now). However I am uncertain how we can manage the docu for the different versions. salu2 -- Thorsten Scherler thorsten.at.apache.org codeBusters S.L. - web based systems consulting, training and solutions http://www.codebusters.es/
c3 version update (was Re: svn commit: r1224754 )
On Mon, 2011-12-26 at 16:40 +, ilgro...@apache.org wrote: Author: ilgrosso Date: Mon Dec 26 16:40:43 2011 New Revision: 1224754 URL: http://svn.apache.org/viewvc?rev=1224754view=rev Log: Updating to Spring 3.1 (+ other version updates) Modified: cocoon/cocoon3/trunk/cocoon-rest/pom.xml cocoon/cocoon3/trunk/cocoon-sample/pom.xml cocoon/cocoon3/trunk/parent/pom.xml Hi Francesco, hi devs, thanks for updating the pom. One small observation since I just updated the parent pom of our client project. https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-archetype-parent/src/main/resources/archetype-resources/pom.xml This pom is way outdated and maybe need to enter in the version update cycle. I am not sure whether we can actually generate that pom automatically based on the c3 parent one (which would save us the double version maintenance) but we cannot have it as outdated as now since it is the start for new developments around c3. salu2 -- Thorsten Scherler thorsten.at.apache.org codeBusters S.L. - web based systems consulting, training and solutions http://www.codebusters.es/
