You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Simone Tripodi <si...@apache.org> on 2011/06/22 17:47:38 UTC

[C3] Deploying Snapshots Was: Re: [C3] XSLTTransformer cache

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.
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.
WDYT?
All the best!
Simo

[1] https://repository.apache.org/index.html
[2] https://builds.apache.org/

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



2011/6/22 Francesco Chicchiriccò <il...@apache.org>:
> On 21/06/2011 18:08, Simone Tripodi wrote:
>>
>> Hi again,
>> that's not log4j but ant[1], it is easy&smart enough that could be
>> imported&  modified depending on our needs...
>> And we could make it generic in the way we can reuse the same policy
>> also in all transformers that require an external resource to be load
>> (i.e. the XSchema validator)
>
> Very nice idea, Simone (and Sylvain)!
>
> Tomorrow I'll start importing that Watchdog class from ANT, then I'll
> replace the current XSLT file caching mechanism with something using this
> approach.
>
> Let's see how this will go, and maybe we could extend it also to other
> components, as you suggest above.
>
> Since I will be using this modified XSLTTransformer anyway, it would be much
> more practical to me not to be forced all the times to rebuild cocoon 3 from
> sources on each and every place where I need it.
> In simple words: is there any possibility to publish SNAPSHOT maven
> artifacts somewhere?
>
> Thanks.
>
>> On Tue, Jun 21, 2011 at 6:05 PM, Simone Tripodi
>> <si...@apache.org>  wrote:
>>>
>>> Hi Grosso,
>>>
>>> of course, COCOON3-62 is still valid, I should have resolved it before
>>> the alpha-3, but "maybe" I'm in too much things now... :P Feel free to
>>> work on it!
>>>
>>> Anyway, we didn't implement the cache with the policy you suggested
>>> because there was an original idea - suggested by Sylvain - that the
>>> transformer should be take care about checking file modification and
>>> reloading the XSLT if changed. So I'd proceed to a Watchdog
>>> implementation - it could be kindly borrowed from already existing
>>> Apache components (log4j has one if I'm not wrong, I'll give a search
>>> anyway) - rather than a pure cache policy: immagine changes are
>>> frequent, they could - in the WOOOOOOOORSe case of course - pull out
>>> from the LRU also other XSL...
>>>
>>> WDYT?
>>> just my 2 cents, have a nice day!!!
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> 2011/6/21 Francesco Chicchiriccò<il...@apache.org>:
>>>>
>>>> Hi folks,
>>>> I am playing quite a lot these days with Cocoon 3 because I had the
>>>> insane
>>>> idea to build a CMS frontend framework upon its solid foundations :-)
>>>>
>>>> Among other things (for which I'll write some other e-mails), I see that
>>>> the
>>>> XSLTTransformer is currently implemented with a LRU cache using the sole
>>>> filename as key. This would imply that XSLT files get never reloaded,
>>>> even
>>>> such feature would be extremely useful when developing XSLT.
>>>>
>>>> What do you think if I modify the current XSLTTransformer cache
>>>> mechanism in
>>>> order to have a more complex key (say filename + filesize)?
>>>>
>>>> Anyway, do you think that [1] is still valid?
>>>>
>>>> [1] https://issues.apache.org/jira/browse/COCOON3-62
>
> --
> Francesco Chicchiriccò
>
> Apache Cocoon Committer and PMC Member
> http://people.apache.org/~ilgrosso/
>
>

Re: [C3] Deploying Snapshots Was: Re: [C3] XSLTTransformer cache

Posted by Reinhard Pötz <re...@apache.org>.
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                  reinhard@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

Posted by Francesco Chicchiriccò <il...@apache.org>.
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?

-- 
Francesco Chicchiriccò

Apache Cocoon Committer and PMC Member
http://people.apache.org/~ilgrosso/