Le 21/06/11 18:08, Simone Tripodi a écrit :
Hi again,
that's not log4j but ant[1], it is easy&smart enough that could be
imported& modified depending on our needs...
Commons IO also has a file monitor that was written by Torsten :
http://commons.apache.org/io/
There's also http://jnotify.sour
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 manage
On 22/06/2011 17:39, Francesco Chicchiriccò wrote:
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 al
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
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
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
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)
HTH!
Sim
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
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 usin