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ò <ilgro...@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 >> <simonetrip...@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ò<ilgro...@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/ > >
