-Original Message-
From: Leszek Gawron [mailto:[EMAIL PROTECTED]
Sent: Montag, 25. April 2005 20:54
To: dev@cocoon.apache.org
Subject: Re: [PROPOSAL] Download of jars with Maven ant tasks
quote All of the tasks can optionally take one or more remote
repositories to download
Sylvain Wallez wrote:
Your feedback and opinions about this initial implementation and its
future evolutions are more than welcome!
very cool. I will check how it will fit together with the Lenya specific
stuff
http://svn.apache.org/repos/asf/lenya/sandbox/jcrsitetree/
Re the JCR library
Hi all,
With the development of real blocks well underway, I was wondering if
anyone had given any thought to a CocoonForge? Something along the
lines of http://mamboforge.net/ perhaps?
Cheers,
Mark
Re the Jackrabbit library lib/optional/jackrabbit-20050422T153417.jar, I
think
it would make sense to use the LCR (Last Changed Revision) number
instead the date
within the filename.
yepp +1 ...I think we should make this a standard for libs
that are not released yet and come from
Would it be legally acceptable to link also to non-Apache licensed stuff?
(Provided it is made available in a repository somewhere.)
IANAL ...but I reckon that should be
ok. Problem is - mocks are still not
ok ...so it does not buy us much.
...I still don't get why mocks are
a problem - this
Hi everyone
Sorry to insist on this maybe Carsten Ziegeler can help me on this, I'm
trying to find out why the redirect coming out of the authetication reacts
differently towards Tomcat5 than any other cocoon redirect .
I don't know much about internals but looked into webapps.authetication but
Torsten Curdt wrote:
Would it be legally acceptable to link also to non-Apache licensed stuff?
(Provided it is made available in a repository somewhere.)
IANAL ...but I reckon that should be
ok. Problem is - mocks are still not
ok ...so it does not buy us much.
...I still don't get why mocks are
Leszek Gawron wrote:
Torsten Curdt wrote:
Would it be legally acceptable to link also to non-Apache licensed
stuff?
(Provided it is made available in a repository somewhere.)
IANAL ...but I reckon that should be
ok. Problem is - mocks are still not
ok ...so it does not buy us much.
...I still
Nicola Ken Barozzi wrote:
Some time ago, it was noted that the usage of a jar download and
handling mechanism would greatly help Cocoon, because it makes it easy
to share jars and to download only the ones needed.
Ivy was proposed as a possible solution, but I suggested instead to
use the
Michael Wechner wrote:
Sylvain Wallez wrote:
Your feedback and opinions about this initial implementation and its
future evolutions are more than welcome!
very cool. I will check how it will fit together with the Lenya
specific stuff
http://svn.apache.org/repos/asf/lenya/sandbox/jcrsitetree/
Sylvain Wallez wrote:
Michael Wechner wrote:
Sylvain Wallez wrote:
Your feedback and opinions about this initial implementation and its
future evolutions are more than welcome!
very cool. I will check how it will fit together with the Lenya
specific stuff
Leszek Gawron wrote:
Torsten Curdt wrote:
Would it be legally acceptable to link also to non-Apache licensed
stuff?
(Provided it is made available in a repository somewhere.)
IANAL ...but I reckon that should be
ok. Problem is - mocks are still not
ok ...so it does not buy us much.
On Sun, Apr 24, 2005 at 01:10:16PM +0200, Nathaniel Alfred wrote:
With my account in the works, it's time to introduce myself.
Alfred, welcome aboard :-)
Ciao
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
smime.p7s
Mark Leicester wrote:
With the development of real blocks well underway, I was wondering if
anyone had given any thought to a CocoonForge? Something along the lines
of http://mamboforge.net/ perhaps?
Well, the charming guys at CocoonDev [1] are already doing that, aren't
they ?
Regards,
[1]
Of course. Thanks Luca. Given I've spent some time working with Daisy I
don't know why I hadn't thought of cocoondev like that.
Steven et al, as blocks take off, are you guys thinking of cocoondev as a
kind of mamboforge? Would it make sense to host Cocoon blocks there? I'm
thinking about block
Leszek Gawron wrote:
what is the difference between rootThrowable and throwable? Does the
first one support chained exceptions or is it something else?
rootThrowable prints cause exception (as defined by
ExceptionUtils.getRootCause); throwable prints full exception chain.
Vadim
creating a single cocoon.log is a good idea. Still it was very good to
have a separate error.log. It is really annoying to search the file for
ERROR string. Is anybody against reintroducing error.log?
--
Leszek Gawron [EMAIL PROTECTED]
IT Manager
[EMAIL PROTECTED] wrote:
Author: lgawron
Date: Mon Apr 25 07:33:22 2005
New Revision: 164581
URL: http://svn.apache.org/viewcvs?rev=164581view=rev
Log:
use rootThrowable instead of throwable in cocoon.log
Modified:
cocoon/trunk/src/webapp/WEB-INF/logkit.xconf
Modified:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34626.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Jorg Heymans wrote:
[EMAIL PROTECTED] wrote:
Author: lgawron
Date: Mon Apr 25 07:33:22 2005
New Revision: 164581
URL: http://svn.apache.org/viewcvs?rev=164581view=rev
Log:
use rootThrowable instead of throwable in cocoon.log
Modified:
cocoon/trunk/src/webapp/WEB-INF/logkit.xconf
Modified:
Jorg Heymans wrote:
[EMAIL PROTECTED] wrote:
Author: lgawron
Date: Mon Apr 25 07:33:22 2005
New Revision: 164581
URL: http://svn.apache.org/viewcvs?rev=164581view=rev
Log:
use rootThrowable instead of throwable in cocoon.log
Modified:
cocoon/trunk/src/webapp/WEB-INF/logkit.xconf
Modified:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34626.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34626.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Reinhard Poetz wrote:
Leszek Gawron wrote:
Torsten Curdt wrote:
Would it be legally acceptable to link also to non-Apache licensed
stuff?
(Provided it is made available in a repository somewhere.)
IANAL ...but I reckon that should be
ok. Problem is - mocks are still not
ok ...so it does not buy
Leszek Gawron wrote:
creating a single cocoon.log is a good idea. Still it was very good to
have a separate error.log. It is really annoying to search the file for
ERROR string. Is anybody against reintroducing error.log?
I am, just change the log level or use tail -f cocoon.log | grep ERROR
--
On 26 Apr 2005, at 13:17, Mark Leicester wrote:
Of course. Thanks Luca. Given I've spent some time working with Daisy I
don't know why I hadn't thought of cocoondev like that.
Steven et al, as blocks take off, are you guys thinking of cocoondev
as a
kind of mamboforge? Would it make sense to host
Hi,
just did
svn update
./build.sh clean
./build.sh
compile-core:
Copying 19 files to
/home/torsten/eclipse/cocoon-2.2-world/trunk/build/cocoon/cl asses
Copied 71 empty directories to 42 empty directories under
/home/torsten/eclipse/ cocoon-2.2-world/trunk/build/cocoon/classes
Compiling Cocoon
Torsten Schlabach wrote:
DOMUtil.java:271: cannot resolve symbol
Fixed
Vadim
Stefano Mazzocchi wrote:
Reinhard Poetz wrote:
Leszek Gawron wrote:
Torsten Curdt wrote:
Would it be legally acceptable to link also to non-Apache licensed
stuff?
(Provided it is made available in a repository somewhere.)
IANAL ...but I reckon that should be
ok. Problem is - mocks are still not
Ralph Goers wrote:
snip/
Please see (if you haven't already)
http://www.gnu.org/licenses/lgpl-java.html.
There's a problem with from the reverse-engineering clause: it requires
the Apache code to be reverse-engineerable in all circumstances, which
goes against the ASL, as it allows any kind
Ralph Goers wrote:
Stefano Mazzocchi wrote:
Reinhard Poetz wrote:
Leszek Gawron wrote:
Torsten Curdt wrote:
Would it be legally acceptable to link also to non-Apache licensed
stuff?
(Provided it is made available in a repository somewhere.)
IANAL ...but I reckon that should be
ok. Problem is -
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34626.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
How do artifacts get into the remote Maven respository
and how are they guaranteed to be the legitimate file?
Surely this concern has been discussed before,
but i cannot find the answer.
The Maven web pages just say something like:
create a Jira issue and tell us what you want to add.
That
33 matches
Mail list logo
