Can we keep the source separate from the jar? I don't want to
have the rhino (etc) sources in every deployed Cocoon application :)
Carsten
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: Monday, June 28, 2004 7:59 AM
To: [EMAIL PROTECTED]
Subject: Re: New
Sylvain Wallez dijo:
Antonio Gallardo wrote:
Hi:
The new submitted rhino lib is 2 times bigger than the older one. I noted
it has included the source files.
When we discussed the inclusion of sources of Cocoon-produced jars,
several people expressed the desire to have sources included in
Hi,
Thank you for answer. No i have not tried to run CocoonPortlet in Pluto.
The guidance in web are not sufficiently. But perhaps you can me help.
What i have to do, in order to let run pluto?
Seb :)
On Thu, 24 Jun 2004 13:23:12 -0400, Menke, John [EMAIL PROTECTED]
wrote:
Sebastian,
Although i
Antonio Gallardo wrote:
Sylvain Wallez dijo:
Antonio Gallardo wrote:
Hi:
The new submitted rhino lib is 2 times bigger than the older one. I noted
it has included the source files.
When we discussed the inclusion of sources of Cocoon-produced jars,
several people expressed the
Hi all,
Some time ago, we discussed the need to keep sources somewhere in Cocoon
for third-party jars produced from CVS snapshots. The purpose is to be
able to easily find the source files for these jars, in order to be able
to know what we use and eventually track bugs.
It must be clear that
2/ keep sources as a separate zip file. This allows to distribute
binary-only jars, and we can dig the Cocoon CVS to get the corresponding
sources when needed.
This option is the least intrusive to users who are not interested in
sources. Developers will have CVS checkouts anyway instead of
Sylvain Wallez dijo:
Please cast your votes:
[+1] do not keep sources
[+1] keep sources as separate zip files
[-0] keep sources in jar files
Best Regards,
Antonio Gallardo
Please cast your votes:
[ ] do not keep sources
[X] keep sources as separate zip files
but only in this special case, otherwise don't keep the sources.
[ ] keep sources in jar files
Stephan.
Sylvain Wallez wrote:
snip/
There are 3 possible policies:
1/ do not keep sources. The build date that's present in the jar name
gives us enough precision to get the corresponding sources, even if
some files may have changed within a 24 hour period.
2/ keep sources as a separate zip file. This
Michal Stochmialek wrote:
Hello,
Something's wrong with implementation of getParent and makeCollection methods.
(in cocoon 2.1.5)
makeCollection() - creates collection only if parent exists. Can't create
directory hierarchy. When I try, i've got this exception:
Sylvain Wallez wrote:
Please cast your votes:
[+1] do not keep sources
and use a full timestamp (as UTC time) in the jar filename
so that people can get the sources from the relevant
external CVS, e.g. foobar-20040628T0824.jar
--
David Crossley
Sylvain Wallez wrote:
...
keep sources in jar files
+1
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
-
On 28.06.2004 10:32, Sylvain Wallez wrote:
Please cast your votes:
[ ] do not keep sources
[ ] keep sources as separate zip files
[X] keep sources in jar files
Joerg
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=24433.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi All
I am making a (non-SiteMap) Avalon Component that allows you to manage
LDAP Entries from FlowScript. (LDAPEntryManager).
I am loading the Component in FlowScript using it's Interface:
var users = cocoon.getComponent (EntryManager.ROLE);
and disposing it using:
Jeremy Quinn wrote:
Hi All
I am making a (non-SiteMap) Avalon Component that allows you to manage
LDAP Entries from FlowScript. (LDAPEntryManager).
I am loading the Component in FlowScript using it's Interface:
var users = cocoon.getComponent (EntryManager.ROLE);
and disposing it using:
Unico Hommes wrote:
Jeremy Quinn wrote:
Hi All
I am making a (non-SiteMap) Avalon Component that allows you to
manage LDAP Entries from FlowScript. (LDAPEntryManager).
I am loading the Component in FlowScript using it's Interface:
var users = cocoon.getComponent (EntryManager.ROLE);
and
Hi,
yes, that turned out to be the problem. My class was package-private, after
making it public it went fine. I'll test with the new rhino.jar asap.
Thanks.
Bye, Helma
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: Sunday, 27 June 2004 15:47
To: [EMAIL
[ ] do not keep sources
[X] keep sources as separate zip files
[ ] keep sources in jar files
--
Ugo Cei - http://beblogging.com/
smime.p7s
Description: S/MIME cryptographic signature
Please cast your votes:
[X] do not keep sources
I'm -1 on: keep sources in jar files
as I don't want to have the sources deployed in every Cocoon app.
Carsten
Hi,
I want to use JavaFlow for writing my application flow. But I've got a
problem; it isn't working with Tomcat, I'm getting a black page (view
source also shows that there is really nothing). However, it is working
with Jetty (both using the same webapp of couse). How is this possible,
what is
I solved it myself. I re-installed Tomcat, which seems to do the trick.
The only thing that I changed in the previous Tomcat installation was
that I added Apache Cactus to it (for testing). I know that JUnit (and
Cactus) also uses class loading, is it possible that this conflicts with
JavaFlow
Am Mo, den 28.06.2004 schrieb Bart Molenkamp um 14:23:
Hi,
I want to use JavaFlow for writing my application flow. But I've got a
problem; it isn't working with Tomcat, I'm getting a black page (view
source also shows that there is really nothing). However, it is working
with Jetty (both
Sylvain Wallez wrote:
[+1] do not keep sources
[ 0] keep sources as separate zip files
[-1] keep sources in jar files
Vadim
I see only one bcel library: jakarta-bcel-20040329.jar. And it works
fine with another Tomcat installation, as I posted earlier. So I don't
think that this is the source of the problem.
Thanks anyway,
Bart.
-Original Message-
From: Stephan Michels [mailto:[EMAIL PROTECTED]
Sent: Monday,
On Mon, Jun 28, 2004 at 11:13:22AM +0200, Sylvain Wallez wrote:
Sylvain Wallez wrote:
Please cast your votes:
[ ] do not keep sources
[ ] keep sources as separate zip files
[X] keep sources in jar files
This solution ensures permanent and unambiguous availability of snapshot
sources,
Hi,
On last cvs 2.1, with cachingURI coplet adapter and
portal-html-eventlink transformer, links like a
href=page2?a=1page2/a are transformed in action=xevent=y
I discovered the original request-params like a are put before the
question mark in the query string :
On 28 Jun 2004, at 12:43, Unico Hommes wrote:
Unico Hommes wrote:
Jeremy Quinn wrote:
Hi All
I am making a (non-SiteMap) Avalon Component that allows you to
manage LDAP Entries from FlowScript. (LDAPEntryManager).
I am loading the Component in FlowScript using it's Interface:
var users =
Hi,
On last cvs 2.1, with cachingURI coplet adapter and
portal-html-eventlink transformer, links like a
href=page2?a=1page2/a are transformed in action=xevent=y
I discovered the original request-params like a are put before the
question mark in the query string :
If I understand you correctly, the problem is in the pipeline calling
your coplet pipeline (calling page2?a=1).
The statement is in the sitemap in coplets/html/sitemap.xmap:
map:generate
src={coplet:temporaryAttributes/application-uri}?copletid={coplet:#}/
Jeremy Quinn wrote:
On 28 Jun 2004, at 12:43, Unico Hommes wrote:
Unico Hommes wrote:
Jeremy Quinn wrote:
Hi All
I am making a (non-SiteMap) Avalon Component that allows you to
manage LDAP Entries from FlowScript. (LDAPEntryManager).
I am loading the Component in FlowScript using it's Interface:
Jeremy Quinn wrote:
How would I organise this differently, in the situation where I had
several of these Components, each differently configured, that I
wanted to be able to load in FlowScript in a similar way. Maybe we
want one setup for read-only privs and another setup for read-write
privs
Carsten Ziegeler wrote:
Please cast your votes:
[X] do not keep sources
I'm -1 on: keep sources in jar files as I don't want to have the sources deployed in every Cocoon app.
Can you elaborate? Is there a technical reason except size?
Sylvain
--
Sylvain Wallez
On Mon, Jun 28, 2004 at 03:40:56PM +0200, Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Please cast your votes:
[X] do not keep sources
I'm -1 on: keep sources in jar files as I don't want to have the sources
deployed in every Cocoon app.
Can you elaborate? Is there a technical
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Please cast your votes:
[X] do not keep sources
I'm -1 on: keep sources in jar files as I don't want to have
the sources deployed in every Cocoon app.
Can you elaborate? Is there a technical reason except size?
My main concern
Tim Larson wrote:
On Mon, Jun 28, 2004 at 11:13:22AM +0200, Sylvain Wallez wrote:
Sylvain Wallez wrote:
Please cast your votes:
[ ] do not keep sources
[ ] keep sources as separate zip files
[X] keep sources in jar files
This solution ensures permanent and unambiguous availability of snapshot
Hello,
I want to lookup a component in a JavaFlow class, but I get a BCEL
error. I get the following error:
org.apache.bcel.verifier.exc.StructuralCodeConstraintException:
Instruction GETSTATIC constraint violated: Class
'com.bizzdesign.cms.model.StorageUnitManager' is referenced, but cannot
be
On 28 Jun 2004, at 14:50, Unico Hommes wrote:
Jeremy Quinn wrote:
On 28 Jun 2004, at 12:43, Unico Hommes wrote:
Unico Hommes wrote:
Jeremy Quinn wrote:
Hi All
I am making a (non-SiteMap) Avalon Component that allows you to
manage LDAP Entries from FlowScript. (LDAPEntryManager).
I am loading
On 28 Jun 2004, at 14:52, Stephan Coboos wrote:
Jeremy Quinn wrote:
How would I organise this differently, in the situation where I had
several of these Components, each differently configured, that I
wanted to be able to load in FlowScript in a similar way. Maybe we
want one setup for
Am Mo, den 28.06.2004 schrieb Bart Molenkamp um 16:25:
Hello,
I want to lookup a component in a JavaFlow class, but I get a BCEL
error. I get the following error:
org.apache.bcel.verifier.exc.StructuralCodeConstraintException:
Instruction GETSTATIC constraint violated: Class
Sylvain Wallez wrote:
Hi all,
Re-reading the ASL 2.0 and looking at our NOTICE.txt, I don't think its
content is appropriate, considering that this file is the attribution
notice that must be included in every derivative work.
With ASL 1.1 the only attribution needed was This product includes
Carsten Ziegeler dijo:
Tim Larson wrote:
On Mon, Jun 28, 2004 at 03:40:56PM +0200, Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Please cast your votes:
[X] do not keep sources
I'm -1 on: keep sources in jar files as I don't want to have the
sources deployed in every Cocoon
with a Google Number of 18,900i don't think so :) :)
(http://www.google.com/search?q=stefano+mazzocchi). Then there's
always the http://www.waybackmachine.org/ to look us all up when we
kick the bucket and fall off google's radar :)
-- dims
On Mon, 28 Jun 2004 13:50:41 -0400, Stefano
Even better than that: just look at
http://www.google.com/search?q=stefano
Darn, the first link on that page is hosted on my server :-P
Although, when it comes to Geek-Fame, the award goes to Carsten
http://www.google.com/search?q=carsten+ziegler
22.000 links! :-)
I'm waaay back with only 10.400
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=29562.
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=29562.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Please cast your votes:
[ -1] do not keep sources
[ +.5] keep sources as separate zip files
[ +1] keep sources in jar files
Interesting argument. However, if I was deploying something with a snapshot
into production I sure as heck would want to make sure I had the source
code for the snapshot to debug any problems that might arise. I've
complained about this before.
Sylvain made it pretty clear that snapshots
Not to throw a wrench in the works, but if I was to implement something
like this (I have, in fact), I would make it ThreadSafe and create a new
naming context every time it is accessed. Then set the system property
that allows the JVM to pool JNDI LDAP contexts and forget about it.
Ralph
At
Anyone have any tips/ideas/suggestions as to what might be causing a JCS
exception of the following form:
ERROR (2004-06-22) 18:41:29.156
org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCache : Failure updating
element, cacheName: main, key: PK_R-resource-
Davanum Srinivas wrote:
with a Google Number of 18,900i don't think so :) :)
(http://www.google.com/search?q=stefano+mazzocchi). Then there's
always the http://www.waybackmachine.org/ to look us all up when we
kick the bucket and fall off google's radar :)
[for the record, I was kidding ;-)]
i know :)
On Mon, 28 Jun 2004 22:37:51 -0400, Stefano Mazzocchi
[EMAIL PROTECTED] wrote:
Davanum Srinivas wrote:
with a Google Number of 18,900i don't think so :) :)
(http://www.google.com/search?q=stefano+mazzocchi). Then there's
always the http://www.waybackmachine.org/ to look us
Ralph Goers dijo:
Please cast your votes:
[ -1] do not keep sources
Can you explain your veto (-1)?
Best Regards,
Antonio Gallardo
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=29854.
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=29854.
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=29854.
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=29854.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
57 matches
Mail list logo
