Re: [jira] [Commented] (COCOON3-126) Make configurable whether xslt transformer component uses LRU cache or not

[Jos Snellings]

I completely agree !
(see also Simo's idea)


On Wed, Jul 3, 2013 at 12:30 AM, Thorsten Scherler (JIRA)
wrote:

>
> [
> https://issues.apache.org/jira/browse/COCOON3-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13698330#comment-13698330]
>
> Thorsten Scherler commented on COCOON3-126:
> ---
>
> I do not think it is a good idea to use the spring injection  here.
>
> Have a look at
> http://svn.apache.org/viewvc?view=revision&revision=r1447255 I think
> passing the config via parameter is much more flexible and do not force to
> use spring.
>
> Can you attach a patch that is more in the spirit of the commit I linked
> above?
>
>
>
> > Make configurable whether xslt transformer component uses LRU cache or
> not
> >
> --
> >
> > Key: COCOON3-126
> > URL: https://issues.apache.org/jira/browse/COCOON3-126
> > Project: Cocoon 3
> >  Issue Type: Improvement
> >  Components: cocoon-sax
> >Affects Versions: 3.0.0-beta-1
> >Reporter: Jos Snellings
> >Priority: Minor
> > Fix For: 3.0.0-beta-1
> >
> > Attachments: cocoon3-126.patch
> >
> >
> > The XSLT pipeline component should be aware of the following setting in
>  
> >  value="true|false|True|False"/>
>
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA
> administrators
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>



-- 
We should be careful to get out of an experience only the wisdom that is
in it - and stay there, lest we be like the cat that sits down on a hot
stove-lid.  She will never sit down on a hot stove-lid again - and that
is well; but also she will never sit down on a cold one any more.
-- Mark Twain
 

[jira] [Commented] (COCOON3-126) Make configurable whether xslt transformer component uses LRU cache or not

[Thorsten Scherler (JIRA)]

[ 
https://issues.apache.org/jira/browse/COCOON3-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13698330#comment-13698330
 ] 

Thorsten Scherler commented on COCOON3-126:
---

I do not think it is a good idea to use the spring injection  here.

Have a look at http://svn.apache.org/viewvc?view=revision&revision=r1447255 I 
think passing the config via parameter is much more flexible and do not force 
to use spring.

Can you attach a patch that is more in the spirit of the commit I linked above?



> Make configurable whether xslt transformer component uses LRU cache or not
> --
>
> Key: COCOON3-126
> URL: https://issues.apache.org/jira/browse/COCOON3-126
> Project: Cocoon 3
>  Issue Type: Improvement
>  Components: cocoon-sax
>Affects Versions: 3.0.0-beta-1
>Reporter: Jos Snellings
>Priority: Minor
> Fix For: 3.0.0-beta-1
>
> Attachments: cocoon3-126.patch
>
>
> The XSLT pipeline component should be aware of the following setting in  
> 
>  value="true|false|True|False"/>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COCOON-2337) cocoon-maven-plugin 1.0.2 - maven-war-plugin 2.3 problem

[gil cattaneo (JIRA)]

[ 
https://issues.apache.org/jira/browse/COCOON-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13697795#comment-13697795
 ] 

gil cattaneo commented on COCOON-2337:
--

in fedora we don't want to install or use archetypes
thnaks

> cocoon-maven-plugin 1.0.2 - maven-war-plugin 2.3 problem
> 
>
> Key: COCOON-2337
> URL: https://issues.apache.org/jira/browse/COCOON-2337
> Project: Cocoon
>  Issue Type: Bug
>  Components: - Build System: Maven
>Reporter: gil cattaneo
>
> hi
> i have this problem building cocoon-maven-plugin 1.0.2
> in fedora we have maven-war-plugin 2.3
> [ERROR] 
> ~/rpmbuild/BUILD/cocoon-maven-plugin-1.0.2/src/main/java/org/apache/cocoon/maven/deployer/AbstractDeployMojo.java:[168,18]
>  cannot find symbol
> #  symbol: method copyResources(java.io.File,java.io.File)
> i changed
> super.copyResources(getWarSourceDirectory(), getWebappDirectory())
> with
> super.buildWebapp(this.getProject(), getWebappDirectory())
> should fix? plugin build ...
> thanks in advance

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COCOON-2337) cocoon-maven-plugin 1.0.2 - maven-war-plugin 2.3 problem

[JIRA]

[ 
https://issues.apache.org/jira/browse/COCOON-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13697783#comment-13697783
 ] 

Francesco Chicchiriccò commented on COCOON-2337:


Gil, I don't understand why are you building Cocoon 3 sources (à la C2.1), 
since you should be instead using the Maven archetype for generating your own, 
Cocoon 3-based, project, as described in 
http://cocoon.apache.org/3.0/download.html

> cocoon-maven-plugin 1.0.2 - maven-war-plugin 2.3 problem
> 
>
> Key: COCOON-2337
> URL: https://issues.apache.org/jira/browse/COCOON-2337
> Project: Cocoon
>  Issue Type: Bug
>  Components: - Build System: Maven
>Reporter: gil cattaneo
>
> hi
> i have this problem building cocoon-maven-plugin 1.0.2
> in fedora we have maven-war-plugin 2.3
> [ERROR] 
> ~/rpmbuild/BUILD/cocoon-maven-plugin-1.0.2/src/main/java/org/apache/cocoon/maven/deployer/AbstractDeployMojo.java:[168,18]
>  cannot find symbol
> #  symbol: method copyResources(java.io.File,java.io.File)
> i changed
> super.copyResources(getWarSourceDirectory(), getWebappDirectory())
> with
> super.buildWebapp(this.getProject(), getWebappDirectory())
> should fix? plugin build ...
> thanks in advance

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (COCOON-2337) cocoon-maven-plugin 1.0.2 - maven-war-plugin 2.3 problem

[JIRA]

[ 
https://issues.apache.org/jira/browse/COCOON-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13697783#comment-13697783
 ] 

Francesco Chicchiriccò edited comment on COCOON-2337 at 7/2/13 1:32 PM:


Gil, I don't understand why you are building Cocoon 3 sources (à la C2.1), 
since you should be instead using the Maven archetype for generating your own, 
Cocoon 3-based, project, as described in 
http://cocoon.apache.org/3.0/download.html

  was (Author: ilgrosso):
Gil, I don't understand why are you building Cocoon 3 sources (à la C2.1), 
since you should be instead using the Maven archetype for generating your own, 
Cocoon 3-based, project, as described in 
http://cocoon.apache.org/3.0/download.html
  
> cocoon-maven-plugin 1.0.2 - maven-war-plugin 2.3 problem
> 
>
> Key: COCOON-2337
> URL: https://issues.apache.org/jira/browse/COCOON-2337
> Project: Cocoon
>  Issue Type: Bug
>  Components: - Build System: Maven
>Reporter: gil cattaneo
>
> hi
> i have this problem building cocoon-maven-plugin 1.0.2
> in fedora we have maven-war-plugin 2.3
> [ERROR] 
> ~/rpmbuild/BUILD/cocoon-maven-plugin-1.0.2/src/main/java/org/apache/cocoon/maven/deployer/AbstractDeployMojo.java:[168,18]
>  cannot find symbol
> #  symbol: method copyResources(java.io.File,java.io.File)
> i changed
> super.copyResources(getWarSourceDirectory(), getWebappDirectory())
> with
> super.buildWebapp(this.getProject(), getWebappDirectory())
> should fix? plugin build ...
> thanks in advance

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (COCOON-2337) cocoon-maven-plugin 1.0.2 - maven-war-plugin 2.3 problem

[gil cattaneo (JIRA)]

[ 
https://issues.apache.org/jira/browse/COCOON-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13697779#comment-13697779
 ] 

gil cattaneo edited comment on COCOON-2337 at 7/2/13 1:28 PM:
--

ok sorry
cocoon 2.x is too old and should bring in fedora some old unwanted libraries as 
excalibur (2010/12/15 - Apache Excalibur has been retired)
thanks

  was (Author: puntogil):
ok sorry
cocoon 2.x is too old and should bring in fedora some old unwanted libraries as 
excalibur
thanks
  
> cocoon-maven-plugin 1.0.2 - maven-war-plugin 2.3 problem
> 
>
> Key: COCOON-2337
> URL: https://issues.apache.org/jira/browse/COCOON-2337
> Project: Cocoon
>  Issue Type: Bug
>  Components: - Build System: Maven
>Reporter: gil cattaneo
>
> hi
> i have this problem building cocoon-maven-plugin 1.0.2
> in fedora we have maven-war-plugin 2.3
> [ERROR] 
> ~/rpmbuild/BUILD/cocoon-maven-plugin-1.0.2/src/main/java/org/apache/cocoon/maven/deployer/AbstractDeployMojo.java:[168,18]
>  cannot find symbol
> #  symbol: method copyResources(java.io.File,java.io.File)
> i changed
> super.copyResources(getWarSourceDirectory(), getWebappDirectory())
> with
> super.buildWebapp(this.getProject(), getWebappDirectory())
> should fix? plugin build ...
> thanks in advance

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COCOON-2337) cocoon-maven-plugin 1.0.2 - maven-war-plugin 2.3 problem

[gil cattaneo (JIRA)]

[ 
https://issues.apache.org/jira/browse/COCOON-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13697779#comment-13697779
 ] 

gil cattaneo commented on COCOON-2337:
--

ok sorry
cocoon 2.x is too old and should bring in fedora some old unwanted libraries as 
excalibur
thanks

> cocoon-maven-plugin 1.0.2 - maven-war-plugin 2.3 problem
> 
>
> Key: COCOON-2337
> URL: https://issues.apache.org/jira/browse/COCOON-2337
> Project: Cocoon
>  Issue Type: Bug
>  Components: - Build System: Maven
>Reporter: gil cattaneo
>
> hi
> i have this problem building cocoon-maven-plugin 1.0.2
> in fedora we have maven-war-plugin 2.3
> [ERROR] 
> ~/rpmbuild/BUILD/cocoon-maven-plugin-1.0.2/src/main/java/org/apache/cocoon/maven/deployer/AbstractDeployMojo.java:[168,18]
>  cannot find symbol
> #  symbol: method copyResources(java.io.File,java.io.File)
> i changed
> super.copyResources(getWarSourceDirectory(), getWebappDirectory())
> with
> super.buildWebapp(this.getProject(), getWebappDirectory())
> should fix? plugin build ...
> thanks in advance

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COCOON-2337) cocoon-maven-plugin 1.0.2 - maven-war-plugin 2.3 problem

[JIRA]

[ 
https://issues.apache.org/jira/browse/COCOON-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13697762#comment-13697762
 ] 

Francesco Chicchiriccò commented on COCOON-2337:


No, I mean the steps that brought you to the need of building the 
cocoon-maven-plugin or cocoon3.

> cocoon-maven-plugin 1.0.2 - maven-war-plugin 2.3 problem
> 
>
> Key: COCOON-2337
> URL: https://issues.apache.org/jira/browse/COCOON-2337
> Project: Cocoon
>  Issue Type: Bug
>  Components: - Build System: Maven
>Reporter: gil cattaneo
>
> hi
> i have this problem building cocoon-maven-plugin 1.0.2
> in fedora we have maven-war-plugin 2.3
> [ERROR] 
> ~/rpmbuild/BUILD/cocoon-maven-plugin-1.0.2/src/main/java/org/apache/cocoon/maven/deployer/AbstractDeployMojo.java:[168,18]
>  cannot find symbol
> #  symbol: method copyResources(java.io.File,java.io.File)
> i changed
> super.copyResources(getWarSourceDirectory(), getWebappDirectory())
> with
> super.buildWebapp(this.getProject(), getWebappDirectory())
> should fix? plugin build ...
> thanks in advance

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COCOON-2337) cocoon-maven-plugin 1.0.2 - maven-war-plugin 2.3 problem

[gil cattaneo (JIRA)]

[ 
https://issues.apache.org/jira/browse/COCOON-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13697761#comment-13697761
 ] 

gil cattaneo commented on COCOON-2337:
--

which steps? do you means how i made to build cocoon-aven-plugin with maven 3.x?
regards

> cocoon-maven-plugin 1.0.2 - maven-war-plugin 2.3 problem
> 
>
> Key: COCOON-2337
> URL: https://issues.apache.org/jira/browse/COCOON-2337
> Project: Cocoon
>  Issue Type: Bug
>  Components: - Build System: Maven
>Reporter: gil cattaneo
>
> hi
> i have this problem building cocoon-maven-plugin 1.0.2
> in fedora we have maven-war-plugin 2.3
> [ERROR] 
> ~/rpmbuild/BUILD/cocoon-maven-plugin-1.0.2/src/main/java/org/apache/cocoon/maven/deployer/AbstractDeployMojo.java:[168,18]
>  cannot find symbol
> #  symbol: method copyResources(java.io.File,java.io.File)
> i changed
> super.copyResources(getWarSourceDirectory(), getWebappDirectory())
> with
> super.buildWebapp(this.getProject(), getWebappDirectory())
> should fix? plugin build ...
> thanks in advance

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COCOON-2337) cocoon-maven-plugin 1.0.2 - maven-war-plugin 2.3 problem

[JIRA]

[ 
https://issues.apache.org/jira/browse/COCOON-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13697734#comment-13697734
 ] 

Francesco Chicchiriccò commented on COCOON-2337:


Everything seems to look fine: could you please detail the steps you are 
following?
I still don't figure out why are you "building" cocoon 3.0.0-alpha-3: if you 
want to run your own Cocoon 3 project, you should start by generating a project 
from Maven archetype [1].

[1] http://cocoon.apache.org/3.0/download.html

> cocoon-maven-plugin 1.0.2 - maven-war-plugin 2.3 problem
> 
>
> Key: COCOON-2337
> URL: https://issues.apache.org/jira/browse/COCOON-2337
> Project: Cocoon
>  Issue Type: Bug
>  Components: - Build System: Maven
>Reporter: gil cattaneo
>
> hi
> i have this problem building cocoon-maven-plugin 1.0.2
> in fedora we have maven-war-plugin 2.3
> [ERROR] 
> ~/rpmbuild/BUILD/cocoon-maven-plugin-1.0.2/src/main/java/org/apache/cocoon/maven/deployer/AbstractDeployMojo.java:[168,18]
>  cannot find symbol
> #  symbol: method copyResources(java.io.File,java.io.File)
> i changed
> super.copyResources(getWarSourceDirectory(), getWebappDirectory())
> with
> super.buildWebapp(this.getProject(), getWebappDirectory())
> should fix? plugin build ...
> thanks in advance

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COCOON-2337) cocoon-maven-plugin 1.0.2 - maven-war-plugin 2.3 problem

[gil cattaneo (JIRA)]

[ 
https://issues.apache.org/jira/browse/COCOON-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13697722#comment-13697722
 ] 

gil cattaneo commented on COCOON-2337:
--

hi
i built cocoon 3.0.0-alpha-3 and for the submodule sample need this plugin

Apache Maven 3.0.5 (rNON-CANONICAL_2013-03-12_12-47_mockbuild; 2013-03-12 
13:47:10+0100)
Maven home: /usr/share/maven
Java version: 1.7.0_25, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.25.i386/jre
Default locale: it_IT, platform encoding: UTF-8
OS name: "linux", version: "3.9.8-300.fc19.i686", arch: "i386", family: "unix"

java version "1.7.0_25"
OpenJDK Runtime Environment (fedora-2.3.10.3.fc19-i386)
OpenJDK Server VM (build 23.7-b01, mixed mode)
thanks for your interest
regards


> cocoon-maven-plugin 1.0.2 - maven-war-plugin 2.3 problem
> 
>
> Key: COCOON-2337
> URL: https://issues.apache.org/jira/browse/COCOON-2337
> Project: Cocoon
>  Issue Type: Bug
>  Components: - Build System: Maven
>Reporter: gil cattaneo
>
> hi
> i have this problem building cocoon-maven-plugin 1.0.2
> in fedora we have maven-war-plugin 2.3
> [ERROR] 
> ~/rpmbuild/BUILD/cocoon-maven-plugin-1.0.2/src/main/java/org/apache/cocoon/maven/deployer/AbstractDeployMojo.java:[168,18]
>  cannot find symbol
> #  symbol: method copyResources(java.io.File,java.io.File)
> i changed
> super.copyResources(getWarSourceDirectory(), getWebappDirectory())
> with
> super.buildWebapp(this.getProject(), getWebappDirectory())
> should fix? plugin build ...
> thanks in advance

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COCOON-2337) cocoon-maven-plugin 1.0.2 - maven-war-plugin 2.3 problem

[JIRA]

[ 
https://issues.apache.org/jira/browse/COCOON-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13697716#comment-13697716
 ] 

Francesco Chicchiriccò commented on COCOON-2337:


Which Maven version are you running?
BTW, why are you building the cocoon-maven-plugin?

> cocoon-maven-plugin 1.0.2 - maven-war-plugin 2.3 problem
> 
>
> Key: COCOON-2337
> URL: https://issues.apache.org/jira/browse/COCOON-2337
> Project: Cocoon
>  Issue Type: Bug
>  Components: - Build System: Maven
>Reporter: gil cattaneo
>
> hi
> i have this problem building cocoon-maven-plugin 1.0.2
> in fedora we have maven-war-plugin 2.3
> [ERROR] 
> ~/rpmbuild/BUILD/cocoon-maven-plugin-1.0.2/src/main/java/org/apache/cocoon/maven/deployer/AbstractDeployMojo.java:[168,18]
>  cannot find symbol
> #  symbol: method copyResources(java.io.File,java.io.File)
> i changed
> super.copyResources(getWarSourceDirectory(), getWebappDirectory())
> with
> super.buildWebapp(this.getProject(), getWebappDirectory())
> should fix? plugin build ...
> thanks in advance

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: COCOON3-126, xslt cache

[Jos Snellings]

Yet, as a Roman, you enjoy a different likelihood for sunny weather :-).
Nonetheless, getting inspiration is very important!

Jos


On Tue, Jul 2, 2013 at 1:12 PM, Simone Tripodi wrote:

> >
> > We can work out a proposal during the weekend, (though it will be very
> nice
> > weather in Belgium).
> >
>
> we are having sunny days in Rome as well (finally!) so I'll do some
> work in the night on the terrace :)
>
> have a nice day, all the best!
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://twitter.com/simonetripodi
>



-- 
We should be careful to get out of an experience only the wisdom that is
in it - and stay there, lest we be like the cat that sits down on a hot
stove-lid.  She will never sit down on a hot stove-lid again - and that
is well; but also she will never sit down on a cold one any more.
-- Mark Twain
 

[jira] [Created] (COCOON-2337) cocoon-maven-plugin 1.0.2 - maven-war-plugin 2.3 problem

[gil cattaneo (JIRA)]

gil cattaneo created COCOON-2337:


 Summary: cocoon-maven-plugin 1.0.2 - maven-war-plugin 2.3 problem
 Key: COCOON-2337
 URL: https://issues.apache.org/jira/browse/COCOON-2337
 Project: Cocoon
  Issue Type: Bug
  Components: - Build System: Maven
Reporter: gil cattaneo


hi
i have this problem building cocoon-maven-plugin 1.0.2
in fedora we have maven-war-plugin 2.3
[ERROR] 
~/rpmbuild/BUILD/cocoon-maven-plugin-1.0.2/src/main/java/org/apache/cocoon/maven/deployer/AbstractDeployMojo.java:[168,18]
 cannot find symbol
#  symbol: method copyResources(java.io.File,java.io.File)
i changed
super.copyResources(getWarSourceDirectory(), getWebappDirectory())
with
super.buildWebapp(this.getProject(), getWebappDirectory())
should fix? plugin build ...
thanks in advance


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: COCOON3-126, xslt cache

[Simone Tripodi]

>
> We can work out a proposal during the weekend, (though it will be very nice
> weather in Belgium).
>

we are having sunny days in Rome as well (finally!) so I'll do some
work in the night on the terrace :)

have a nice day, all the best!
-Simo

http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi

Re: COCOON3-126, xslt cache

[Jos Snellings]

Yes, Simo, that is a good approach!
I think it is worth the work in order to keep the cocoon base classes tidy.

We can work out a proposal during the weekend, (though it will be very nice
weather in Belgium).

Cheers,
Jos


On Tue, Jul 2, 2013 at 11:38 AM, Simone Tripodi wrote:

> Hi Jos,
>
> the most important thing is IMHO having the XSLT transformer
> dependencies-less as much as we can - I suggest to define a "cache"
> interface (with a basic implementation) provided to XSLT transformer
> (via constructor), then users are free to use whatever implementation
> they need/prefer.
>
> Having a default implementation would be a strict constraint, while
> users should be able to plug their integration module depending to
> their use case.
>
> Does it sound reasonable?
>
> I have ~0 spare cycles to OSS ATM, but I promise to have a look at
> your patch during the WE, so I can at least provide you more
> feedbacks.
>
> Have a nice day, all the best!
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://twitter.com/simonetripodi
>
>
> On Tue, Jul 2, 2013 at 11:19 AM, Jos Snellings
>  wrote:
> > Hi Francesco et al,
> >
> > I proposed a patch for COCOON3-126, on the configurability of using an
> LRU
> > cache for
> > xslt transformations. I am not too happy with it though.
> >
> > I would like to have a member function to set "isCacheEnabled", or to set
> > this at setup.
> > However, the resource is loaded in the constructor.
> > Would it be better to add a boolean "isCacheEnabled' to a constructor,
> > leaving the default
> > to "yes"?
> >
> > What do you think?
> >
> > Kind regards,
> > Jos
> >
> > --
> > We should be careful to get out of an experience only the wisdom that is
> > in it - and stay there, lest we be like the cat that sits down on a hot
> > stove-lid.  She will never sit down on a hot stove-lid again - and that
> > is well; but also she will never sit down on a cold one any more.
> > -- Mark Twain
>



-- 
We should be careful to get out of an experience only the wisdom that is
in it - and stay there, lest we be like the cat that sits down on a hot
stove-lid.  She will never sit down on a hot stove-lid again - and that
is well; but also she will never sit down on a cold one any more.
-- Mark Twain
 

Re: COCOON3-126, xslt cache

[Simone Tripodi]

Hi Jos,

the most important thing is IMHO having the XSLT transformer
dependencies-less as much as we can - I suggest to define a "cache"
interface (with a basic implementation) provided to XSLT transformer
(via constructor), then users are free to use whatever implementation
they need/prefer.

Having a default implementation would be a strict constraint, while
users should be able to plug their integration module depending to
their use case.

Does it sound reasonable?

I have ~0 spare cycles to OSS ATM, but I promise to have a look at
your patch during the WE, so I can at least provide you more
feedbacks.

Have a nice day, all the best!
-Simo

http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi


On Tue, Jul 2, 2013 at 11:19 AM, Jos Snellings
 wrote:
> Hi Francesco et al,
>
> I proposed a patch for COCOON3-126, on the configurability of using an LRU
> cache for
> xslt transformations. I am not too happy with it though.
>
> I would like to have a member function to set "isCacheEnabled", or to set
> this at setup.
> However, the resource is loaded in the constructor.
> Would it be better to add a boolean "isCacheEnabled' to a constructor,
> leaving the default
> to "yes"?
>
> What do you think?
>
> Kind regards,
> Jos
>
> --
> We should be careful to get out of an experience only the wisdom that is
> in it - and stay there, lest we be like the cat that sits down on a hot
> stove-lid.  She will never sit down on a hot stove-lid again - and that
> is well; but also she will never sit down on a cold one any more.
> -- Mark Twain

COCOON3-126, xslt cache

[Jos Snellings]

Hi Francesco et al,

I proposed a patch for COCOON3-126, on the configurability of using an LRU
cache for
xslt transformations. I am not too happy with it though.

I would like to have a member function to set "isCacheEnabled", or to set
this at setup.
However, the resource is loaded in the constructor.
Would it be better to add a boolean "isCacheEnabled' to a constructor,
leaving the default
to "yes"?

What do you think?

Kind regards,
Jos

-- 
We should be careful to get out of an experience only the wisdom that is
in it - and stay there, lest we be like the cat that sits down on a hot
stove-lid.  She will never sit down on a hot stove-lid again - and that
is well; but also she will never sit down on a cold one any more.
-- Mark Twain
 

Re: Your Gump Build(s)

[David Crossley]

David Crossley wrote:
> Francesco Chicchiriccò wrote:
> > David Crossley wrote:
> > >
> > >Reminder to the Cocoon project:
> > >
> > >We have a number of Gump builds:
> > >See http://svn.apache.org/repos/asf/gump/metadata/project/
> > >for the "cocoon" entries.
> > >
> > >For example, the output from the vmgump machine is here:
> > >http://vmgump.apache.org/gump/public/cocoon3/
> > >and
> > >http://vmgump.apache.org/gump/public/cocoon/ for c2.2
> > >(IIRC then cocoon-2.1 is "packaged" rather than built.)
> > >
> > >The metadata for each Cocoon "project" probably
> > >needs some care and attention from us.
> > 
> > Hi David,
> > I am not familiar with Gump at all, but at least for Cocoon 3 [1] and 
> > Cocoon 2.1 [2] we have Jenkins jobs defined.
> 
> Gump is very different. See Stefan's message below.
> 
> I reckon that both are useful in different ways.

This is the description from their home page:
"Gump is unique in that it builds and compiles software against the latest 
development versions of those projects. This allows gump to detect potentially 
incompatible changes to that software just a few hours after those changes are 
checked into the version control system."

and from their Board reports:
"Apache Gump is a cross-project continuous integration server. Gump's intention 
isn't so much to be a CI server but rather a vehicle that makes people look 
beyond their project's boundaries and helps the projects to collaborate."

-David

> > I don't think we still need Gump, at least for C3 and C2.1 (and we might 
> > define a job on Jenkins for C2.2 as well), right?
> > 
> > WDYT? Should we safely remove cocoon entries from Gump? How could this 
> > be done?
> > 
> > Regards.
> > 
> > [1] https://builds.apache.org/job/Cocoon%203.0/
> > [2] https://builds.apache.org/job/Cocoon%202.1.X/
> > 
> > >Stefan Bodewig wrote:
> > >>Dear Community
> > >>
> > >>Apache Gump builds some of your projects and it is quite possible you
> > >>don't know or have by now forgotten about it.
> > >>
> > >>More than half a year ago a technical problem has forced us to turn off
> > >>emails on build failures as we would have been sending out lots of false
> > >>alarms.
> > >>
> > >>Before we re-enable emails we'd like to know whether you are still
> > >>interested in the service Gump provides, so please tell us. :-)
> > >>
> > >>Metadata for many projects have been neglected for a long time and it is
> > >>quite possible they'd need some love for results to be meaningful.  All
> > >>Apache committers have write access to Gump's metadata.
> > >>
> > >>In case you don't know what this Gump stuff is about:
> > >>
> > >>Apache Gump builds the full stack of the latest commits of software in
> > >>order to ensure integrity over releases.  Build failures surface API
> > >>discontinuities between projects before they impact releases, and Gump's
> > >>e-mail notifications hope to promote the conversations between teams to
> > >>resolve those discontinuities.
> > >>
> > >>When responding to this mail please shorten the CC list as appropriate.
> > >>
> > >>Cheers
> > >>
> > >> Stefan
> > >>
> > >>  on behalf of the Gump PMC
> > 
> > -- 
> > Francesco Chicchiriccò
> > 
> > ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> > http://people.apache.org/~ilgrosso/
> > 

Re: Your Gump Build(s)

[David Crossley]

Francesco Chicchiriccò wrote:
> David Crossley wrote:
> >
> >Reminder to the Cocoon project:
> >
> >We have a number of Gump builds:
> >See http://svn.apache.org/repos/asf/gump/metadata/project/
> >for the "cocoon" entries.
> >
> >For example, the output from the vmgump machine is here:
> >http://vmgump.apache.org/gump/public/cocoon3/
> >and
> >http://vmgump.apache.org/gump/public/cocoon/ for c2.2
> >(IIRC then cocoon-2.1 is "packaged" rather than built.)
> >
> >The metadata for each Cocoon "project" probably
> >needs some care and attention from us.
> 
> Hi David,
> I am not familiar with Gump at all, but at least for Cocoon 3 [1] and 
> Cocoon 2.1 [2] we have Jenkins jobs defined.

Gump is very different. See Stefan's message below.

I reckon that both are useful in different ways.

-David

> I don't think we still need Gump, at least for C3 and C2.1 (and we might 
> define a job on Jenkins for C2.2 as well), right?
> 
> WDYT? Should we safely remove cocoon entries from Gump? How could this 
> be done?
> 
> Regards.
> 
> [1] https://builds.apache.org/job/Cocoon%203.0/
> [2] https://builds.apache.org/job/Cocoon%202.1.X/
> 
> >Stefan Bodewig wrote:
> >>Dear Community
> >>
> >>Apache Gump builds some of your projects and it is quite possible you
> >>don't know or have by now forgotten about it.
> >>
> >>More than half a year ago a technical problem has forced us to turn off
> >>emails on build failures as we would have been sending out lots of false
> >>alarms.
> >>
> >>Before we re-enable emails we'd like to know whether you are still
> >>interested in the service Gump provides, so please tell us. :-)
> >>
> >>Metadata for many projects have been neglected for a long time and it is
> >>quite possible they'd need some love for results to be meaningful.  All
> >>Apache committers have write access to Gump's metadata.
> >>
> >>In case you don't know what this Gump stuff is about:
> >>
> >>Apache Gump builds the full stack of the latest commits of software in
> >>order to ensure integrity over releases.  Build failures surface API
> >>discontinuities between projects before they impact releases, and Gump's
> >>e-mail notifications hope to promote the conversations between teams to
> >>resolve those discontinuities.
> >>
> >>When responding to this mail please shorten the CC list as appropriate.
> >>
> >>Cheers
> >>
> >> Stefan
> >>
> >>  on behalf of the Gump PMC
> 
> -- 
> Francesco Chicchiriccò
> 
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~ilgrosso/
> 

Re: Your Gump Build(s)

[Francesco Chicchiriccò]

On 02/07/2013 09:34, David Crossley wrote:

Reminder to the Cocoon project:

We have a number of Gump builds:
See http://svn.apache.org/repos/asf/gump/metadata/project/
for the "cocoon" entries.

For example, the output from the vmgump machine is here:
http://vmgump.apache.org/gump/public/cocoon3/
and
http://vmgump.apache.org/gump/public/cocoon/ for c2.2
(IIRC then cocoon-2.1 is "packaged" rather than built.)

The metadata for each Cocoon "project" probably
needs some care and attention from us.


Hi David,
I am not familiar with Gump at all, but at least for Cocoon 3 [1] and 
Cocoon 2.1 [2] we have Jenkins jobs defined.


I don't think we still need Gump, at least for C3 and C2.1 (and we might 
define a job on Jenkins for C2.2 as well), right?


WDYT? Should we safely remove cocoon entries from Gump? How could this 
be done?


Regards.

[1] https://builds.apache.org/job/Cocoon%203.0/
[2] https://builds.apache.org/job/Cocoon%202.1.X/


Stefan Bodewig wrote:

Dear Community

Apache Gump builds some of your projects and it is quite possible you
don't know or have by now forgotten about it.

More than half a year ago a technical problem has forced us to turn off
emails on build failures as we would have been sending out lots of false
alarms.

Before we re-enable emails we'd like to know whether you are still
interested in the service Gump provides, so please tell us. :-)

Metadata for many projects have been neglected for a long time and it is
quite possible they'd need some love for results to be meaningful.  All
Apache committers have write access to Gump's metadata.

In case you don't know what this Gump stuff is about:

Apache Gump builds the full stack of the latest commits of software in
order to ensure integrity over releases.  Build failures surface API
discontinuities between projects before they impact releases, and Gump's
e-mail notifications hope to promote the conversations between teams to
resolve those discontinuities.

When responding to this mail please shorten the CC list as appropriate.

Cheers

 Stefan

  on behalf of the Gump PMC


--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/

Re: Your Gump Build(s)

[David Crossley]

David Crossley wrote:
>
> Reminder to the Cocoon project:
> 
> We have a number of Gump builds:
> See http://svn.apache.org/repos/asf/gump/metadata/project/
> for the "cocoon" entries.
> 
> For example, the output from the vmgump machine is here:
> http://vmgump.apache.org/gump/public/cocoon3/

At the moment Cocoon3 is failing with a complaint
that seems to be related to FOP.
See http://vmgump.apache.org/gump/public/cocoon3/
and follow the link to "cocoon-optional" (which the other
cocoon parts depend upon). Then follow the link to
the "build_cocoon3_cocoon-optional" output which has the detail.

-David

> and
> http://vmgump.apache.org/gump/public/cocoon/ for c2.2
> (IIRC then cocoon-2.1 is "packaged" rather than built.)
> 
> The metadata for each Cocoon "project" probably
> needs some care and attention from us.
> 
> -David
> 
> Stefan Bodewig wrote:
> > Dear Community
> > 
> > Apache Gump builds some of your projects and it is quite possible you
> > don't know or have by now forgotten about it.
> > 
> > More than half a year ago a technical problem has forced us to turn off
> > emails on build failures as we would have been sending out lots of false
> > alarms.
> > 
> > Before we re-enable emails we'd like to know whether you are still
> > interested in the service Gump provides, so please tell us. :-)
> > 
> > Metadata for many projects have been neglected for a long time and it is
> > quite possible they'd need some love for results to be meaningful.  All
> > Apache committers have write access to Gump's metadata.
> > 
> > In case you don't know what this Gump stuff is about:
> > 
> > Apache Gump builds the full stack of the latest commits of software in
> > order to ensure integrity over releases.  Build failures surface API
> > discontinuities between projects before they impact releases, and Gump's
> > e-mail notifications hope to promote the conversations between teams to
> > resolve those discontinuities.
> > 
> > When responding to this mail please shorten the CC list as appropriate.
> > 
> > Cheers
> > 
> > Stefan
> > 
> >  on behalf of the Gump PMC
> > 

Re: Your Gump Build(s)

[David Crossley]

Reminder to the Cocoon project:

We have a number of Gump builds:
See http://svn.apache.org/repos/asf/gump/metadata/project/
for the "cocoon" entries.

For example, the output from the vmgump machine is here:
http://vmgump.apache.org/gump/public/cocoon3/
and
http://vmgump.apache.org/gump/public/cocoon/ for c2.2
(IIRC then cocoon-2.1 is "packaged" rather than built.)

The metadata for each Cocoon "project" probably
needs some care and attention from us.

-David

Stefan Bodewig wrote:
> Dear Community
> 
> Apache Gump builds some of your projects and it is quite possible you
> don't know or have by now forgotten about it.
> 
> More than half a year ago a technical problem has forced us to turn off
> emails on build failures as we would have been sending out lots of false
> alarms.
> 
> Before we re-enable emails we'd like to know whether you are still
> interested in the service Gump provides, so please tell us. :-)
> 
> Metadata for many projects have been neglected for a long time and it is
> quite possible they'd need some love for results to be meaningful.  All
> Apache committers have write access to Gump's metadata.
> 
> In case you don't know what this Gump stuff is about:
> 
> Apache Gump builds the full stack of the latest commits of software in
> order to ensure integrity over releases.  Build failures surface API
> discontinuities between projects before they impact releases, and Gump's
> e-mail notifications hope to promote the conversations between teams to
> resolve those discontinuities.
> 
> When responding to this mail please shorten the CC list as appropriate.
> 
> Cheers
> 
> Stefan
> 
>  on behalf of the Gump PMC
>