Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's Rhino+continuations fork)
Reinhard Pötz wrote: And instead of investing to much time in all those things we should make CocoonBlocks become reality ASAP because they will solve those dependencies very elgantly. I'd say *most* of those dependencies, but not all of them. Flowscript is part of the core, for instance. Ugo
RE: Using Maven (or something similar) for dependencies? (Was: Cocoon's Rhino+continuations fork)
Reinhard Pötz wrote: And instead of investing to much time in all those things we should make CocoonBlocks become reality ASAP because they will solve those dependencies very elgantly. Yes, but imho we need a solution for 2.1.x as well. If we would wait for blocks we could not do another 2.1.x release. Carsten
Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's Rhino+continuations fork)
Carsten Ziegeler wrote: Reinhard Pötz wrote: And instead of investing to much time in all those things we should make CocoonBlocks become reality ASAP because they will solve those dependencies very elgantly. Yes, but imho we need a solution for 2.1.x as well. If we would wait for blocks we could not do another 2.1.x release. Good point. Let's wait on the results of the current discussions and then we can decide. -- Reinhard
Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's Rhino+continuations fork)
Ugo Cei wrote: Reinhard Pötz wrote: And instead of investing to much time in all those things we should make CocoonBlocks become reality ASAP because they will solve those dependencies very elgantly. I'd say *most* of those dependencies, but not all of them. Flowscript is part of the core, for instance. Ugo Yes, that true. But we have also also thought about modularizing Cocoon core (see Cocoon modules) - e.g. different environements - and if *licences* makes it necessary we can also have a flowscript module. -- Reinhard
Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's Rhino+continuations fork)
On 12 Mar 2004, at 09:05, Ugo Cei wrote: Reinhard Pötz wrote: And instead of investing to much time in all those things we should make CocoonBlocks become reality ASAP because they will solve those dependencies very elgantly. I'd say *most* of those dependencies, but not all of them. Flowscript is part of the core, for instance. Yep. And we should also think about the users of our users: can they be expected to go through the same download-on-demand scenario before even taking a quick look whether Cocoon fits their bill? /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
[XMLDBTransformer] Bug ? remove usefull namespace in update
Hi cocooners I got a serious problem, when I try to update an eXist database with this transformer. The input is ?xml version=1.0 encoding=UTF-8? page xmlns:xdb=http://apache.org/cocoon/xmldb/1.0; xmlns:xu=http://www.xmldb.org/xupdate; xdb:query type=update collection=MyCol oid=MyFile xu:modifications version=1.0 xmlns:xu=http://www.xmldb.org/xupdate; xu:update select=/my/pathMyValue/xu:update /xu:modifications /xdb:query /page The service.updateResource() failed because the xu namespace was remove from the xu:modification tag. Why all namespace are removed? If I insert again this namespace the update is successful. How can I avoid namespace removing? Can have side effect, with Xindice for exemple? Laurent Trillaud
Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's Rhino+continuations fork)
Am Fr, den 12.03.2004 schrieb Bertrand Delacretaz um 07:47: Sounds like the way to go, intelligently downloading dependencies from some non-ASF repository should solve most, maybe all of the licensing problems, and help make Cocoon more lightweight for many uses. IIRC last time this was discussed the debate quickly moved to a heated discussion on the relative merits of Maven and other similar tools - if we're going to discuss this again, we must be careful to focus on the goals rather than on the tools! You don't need to migrate to maven to have the automatic download mechanism, see Ruper(http://krysalis.org/ruper/). Should be easy to integrate into the existing build system. I think this is the way to go. Stephan.
RE: cvs commit: cocoon-2.1/tools/src blocks-build.xsl
Am Fr, den 12.03.2004 schrieb Carsten Ziegeler um 08:25: Stephan Michels wrote Ehm, are you sure that this works? The xconf's from the different blocks have to be applied in the correct order (in the order of their dependencies). If you all apply at once this is imho not guarenteed, right? Now it should work. I rewrote the XConfTask. So, there is no problem the xsp-session-fw.xconf and others anymore. Just curious, how does it work - how do you ensure that the xconf's are applied in the correct order? The patch method return a true if the patch was applied. So I retry to patch until there exists no patches to execute anymore. It's not perfect, but fulfil our needs. Stephan.
RE: cvs commit: cocoon-2.1/tools/src blocks-build.xsl
Stephan Michels wrote: The patch method return a true if the patch was applied. So I retry to patch until there exists no patches to execute anymore. It's not perfect, but fulfil our needs. Ah, I see - and in the case of an error you avoid endless loops, I guess? Carsten
Re: XSP block status
Stephan Michels wrote: Am Mi, den 10.03.2004 schrieb Unico Hommes um 19:24: There remain a few issues that need resolving. - InputModuleAction had to move along with xsp because it has a dependency on some xsp helper class. This is unfortunate and maybe unnecessary. Perhaps someone with more knowledge about this class could take a look and see if they can solve this? - Source samples. Some use xsp's. Move these to xsp block or remove them altogether? I'm in favour of removing them. But I can't decide that. Me too. I don't think there remains an appropriate place to move them. What do others think? - I18n samples. Needs volunteer. - simpleform samples. Needs volunteer. Only the first example use XSPs. - session-fw patches are executed before xsp patches but depend on them. Move xsp specific stuff from session-fw to xsp. I think this stuff, can stay where it is. The patch mechanism should now work properly. Nice one! Thanks. - some blocks have dependencies on xsp. These need to be declared. I think the rest comes the paradigm shift to flow+jx early or later. I was thinking more in the way that some blocks won't work when xsp is not included. For instance eventcache comes to mind. I'll see what more dependencies I can find. -- Unico
Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's Rhino+continuations fork)
Stephan Michels wrote: Am Fr, den 12.03.2004 schrieb Bertrand Delacretaz um 07:47: Sounds like the way to go, intelligently downloading dependencies from some non-ASF repository should solve most, maybe all of the licensing problems, and help make Cocoon more lightweight for many uses. IIRC last time this was discussed the debate quickly moved to a heated discussion on the relative merits of Maven and other similar tools - if we're going to discuss this again, we must be careful to focus on the goals rather than on the tools! You don't need to migrate to maven to have the automatic download mechanism, see Ruper(http://krysalis.org/ruper/). Should be easy to integrate into the existing build system. I think this is the way to go. Or maybe Ant-get is enough (http://ant.apache.org/manual/CoreTasks/get.html) -- Reinhard
RE: cvs commit: cocoon-2.1/tools/src blocks-build.xsl
Stephan Michels wrote: The patch method return a true if the patch was applied. So I retry to patch until there exists no patches to execute anymore. It's not perfect, but fulfil our needs. Ah, I see - and in the case of an error you avoid endless loops, I guess? Yes I hope so ;-) Great :) Carsten
RE: Using Maven (or something similar) for dependencies? (Was: Cocoon's Rhino+continuations fork)
Reinhard Pötz wrote: Stephan Michels wrote: Am Fr, den 12.03.2004 schrieb Bertrand Delacretaz um 07:47: Sounds like the way to go, intelligently downloading dependencies from some non-ASF repository should solve most, maybe all of the licensing problems, and help make Cocoon more lightweight for many uses. IIRC last time this was discussed the debate quickly moved to a heated discussion on the relative merits of Maven and other similar tools - if we're going to discuss this again, we must be careful to focus on the goals rather than on the tools! You don't need to migrate to maven to have the automatic download mechanism, see Ruper(http://krysalis.org/ruper/). Should be easy to integrate into the existing build system. I think this is the way to go. Or maybe Ant-get is enough (http://ant.apache.org/manual/CoreTasks/get.html) We have to fetch only those jars that aren't allowed in our CVS. I think the first step should be to list those jars and then we can see what we can do with each of them. And downloading them during the build should be imho the last option. So, do we have a list? Carsten
Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's Rhino+continuations fork)
Yep. And we should also think about the users of our users: can they be expected to go through the same download-on-demand scenario before even taking a quick look whether Cocoon fits their bill? Is it really much more complicated to download? It does not have to be always on demand... Let's assume we distribute cocoon-2.whatever-src.tgz without any external jars and we have a repository with each individual jar. rhino.jar itext.jar jetty.jar If we could (are alound) to provide an archiv for convenience, cocoon-2.whatever-dependencies.tgz We'd only have *two* instead of one downloads. After the download you have all dependencies on disk. The download-on-demand system should utilize the archiv and no further downloads-on-demand are necessary since everything is already there. IMO this should not make much of a difference for anyone who wants to try Cocoon. -- Torsten
Re: form framework clean up
xmlform has already been deprecated for quite a while now. I think it is safe to remove it. It's only half a year: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107662678916017w=4. I would deprecate jxforms block now and remove both for 2.2 (which is infact just a non-update to real blocks). ...really keep it in 2.1? I thought I'm the one who wants to remove stuff to early :) I don't need those both blocks, so I'm not blocking this for myself's needs. Maybe we should ask the users? I asked over a cocoon-user. Up til now 100% of them are saying remove it *now*. (about 17 users responded) It was clearly stated the vast amount of options lead more to confusion than they are helpful. ...as we already know :) If noone objects I'll remove both blocks either tonight or tomorrow. WDYT? -- Torsten
Re: First pass at Apache Wiki conversion
Also, http://wiki.apache.org/cocoon/Main shows nested list handling isn't quite perfect yet. JSPWiki: * foo ** bar becomes: * foo * * bar should be: * foo * bar /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
RE: form framework clean up
Torsten Curdt wrote: I asked over a cocoon-user. Up til now 100% of them are saying remove it *now*. (about 17 users responded) It was clearly stated the vast amount of options lead more to confusion than they are helpful. ...as we already know :) If noone objects I'll remove both blocks either tonight or tomorrow. WDYT? I would say, just wait some more days. We have to remove the blocks before the next release. So it actually doesn't matter if we remove it today or next week. But waiting just some more days might give users that are reading the list only from time to time to answer as well. Apart from that: blast it! Carsten
Re: form framework clean up
On 12.03.2004 11:19, Torsten Curdt wrote: I asked over a cocoon-user. Thanks for that. Up til now 100% of them are saying remove it *now*. (about 17 users responded) It was clearly stated the vast amount of options lead more to confusion than they are helpful. ...as we already know :) I did not expect such a clear result. If noone objects I'll remove both blocks either tonight or tomorrow. Me not. Joerg
Re: form framework clean up
Carsten Ziegeler wrote: Torsten Curdt wrote: I asked over a cocoon-user. Up til now 100% of them are saying remove it *now*. (about 17 users responded) It was clearly stated the vast amount of options lead more to confusion than they are helpful. ...as we already know :) If noone objects I'll remove both blocks either tonight or tomorrow. WDYT? I would say, just wait some more days. We have to remove the blocks before the next release. So it actually doesn't matter if we remove it today or next week. But waiting just some more days might give users that are reading the list only from time to time to answer as well. Apart from that: blast it! +1 (wait for next week so that everybody has a chance to comment) -- Reinhard
Re: cvs commit: cocoon-2.1/tools/src/anttasks XConfToolTask.java
On 11.03.2004 16:11, [EMAIL PROTECTED] wrote: stephan 2004/03/11 07:11:10 Modified:tools/src/anttasks XConfToolTask.java Log: Retry to apply patches, which depends on each other. I really wonder why we re-implement the dependency resolving into a task (how simple it might be) when Ant does it for us. That the patching did not work until now was probably caused by missing dependencies on target level, was it not? That means patch-session-fw-block did not depend on patch-xsp-block, though session-fw block is dependent on xsp block. I think this should be fixed in the generated blocks-build.xml and so in the stylesheet generating this file, not in the patch task. This also probably lowers the reusability of this task. Joerg
Re: cvs commit: cocoon-2.1/tools/src/anttasks XConfToolTask.java
Joerg Heinicke wrote: On 11.03.2004 16:11, [EMAIL PROTECTED] wrote: stephan 2004/03/11 07:11:10 Modified:tools/src/anttasks XConfToolTask.java Log: Retry to apply patches, which depends on each other. I really wonder why we re-implement the dependency resolving into a task (how simple it might be) when Ant does it for us. That the patching did not work until now was probably caused by missing dependencies on target level, was it not? That means patch-session-fw-block did not depend on patch-xsp-block, though session-fw block is dependent on xsp block. I think this should be fixed in the generated blocks-build.xml and so in the stylesheet generating this file, not in the patch task. This also probably lowers the reusability of this task. I thought that previously all xpatches for all blocks were executed in one go instead of separately and respecting dependency order. And that this was the root of the problem. But I am not sure. I also would prefer using the dependency information to dynamically arrange patch order instead. -- Unico
Re: form framework clean up
I asked over a cocoon-user. Up til now 100% of them are saying remove it *now*. (about 17 users responded) It was clearly stated the vast amount of options lead more to confusion than they are helpful. ...as we already know :) If noone objects I'll remove both blocks either tonight or tomorrow. WDYT? I would say, just wait some more days. We have to remove the blocks before the next release. So it actually doesn't matter if we remove it today or next week. But waiting just some more days might give users that are reading the list only from time to time to answer as well. Apart from that: blast it! alright -- Torsten
RE: cvs commit: cocoon-2.1/tools/src/anttasks XConfToolTask.java
Unico Hommes wrote: I thought that previously all xpatches for all blocks were executed in one go instead of separately and respecting dependency order. No, one patch after the other was applied previously. The order of the dependencies was used to define the order of the patches to be applied. So, if the dependencies were correctly set, no problem could occur. Carsten And that this was the root of the problem. But I am not sure. I also would prefer using the dependency information to dynamically arrange patch order instead.
Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's Rhino+continuations fork)
Bertrand Delacretaz wrote: Sounds like the way to go, intelligently downloading dependencies from some non-ASF repository should solve most, maybe all of the licensing problems, and help make Cocoon more lightweight for many uses. IIRC last time this was discussed the debate quickly moved to a heated discussion on the relative merits of Maven and other similar tools - if we're going to discuss this again, we must be careful to focus on the goals rather than on the tools! Isn't this missing the whole point of the current licensing discussion? If we cook up a system that allows us to create and distribute cocoon but that product now cannot be used to build a commercial application without questions of further license requirements (source code availability, etc.) have we served our users well? Geoff
Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's Rhino+continuations fork)
On 12.03.2004 13:14, Geoff Howard wrote: Isn't this missing the whole point of the current licensing discussion? If we cook up a system that allows us to create and distribute cocoon but that product now cannot be used to build a commercial application without questions of further license requirements (source code availability, etc.) have we served our users well? That's exactly the problem I have with this library system. Isn't Apache stuff that common because of its ease of use? I don't want to do license checking for every dependent project I get from somewhere. Moving this to the users is just a poor move and should be avoided if possible. It's not just about downloading one more JAR. Joerg
Re: XSP block status
Unico Hommes wrote: Stephan Michels wrote: Am Mi, den 10.03.2004 schrieb Unico Hommes um 19:24: There remain a few issues that need resolving. - InputModuleAction had to move along with xsp because it has a dependency on some xsp helper class. This is unfortunate and maybe unnecessary. Perhaps someone with more knowledge about this class could take a look and see if they can solve this? - Source samples. Some use xsp's. Move these to xsp block or remove them altogether? I'm in favour of removing them. But I can't decide that. Me too. I don't think there remains an appropriate place to move them. What do others think? - I18n samples. Needs volunteer. - simpleform samples. Needs volunteer. Only the first example use XSPs. - session-fw patches are executed before xsp patches but depend on them. Move xsp specific stuff from session-fw to xsp. I think this stuff, can stay where it is. The patch mechanism should now work properly. Nice one! Thanks. - some blocks have dependencies on xsp. These need to be declared. I think the rest comes the paradigm shift to flow+jx early or later. I was thinking more in the way that some blocks won't work when xsp is not included. For instance eventcache comes to mind. I'll see what more dependencies I can find. some block _samples_ won't work is of course what you mean. What we really need is the concept of optional dependencies. Examples: - during the eventcache build, the xsp samples should be copied over if it's optional xsp dependency is present. - during the jms build, the xsp and database caching examples should be created if both those optional dependencies are present. I have been wondering if ant 1.6 gives us some new options for these blocks builds which make this more possible. for example, I think the new import facility would allow us to import generic block build tasks into the block's own (usually non-present) build.xml, avoid generating the blocks build via xsl, and easily add arbitrarily complex sub-dependencies. Does that spark any ideas? Geoff
Re: cvs commit: cocoon-2.1/tools/src/anttasks XConfToolTask.java
On 12.03.2004 13:01, Carsten Ziegeler wrote: I thought that previously all xpatches for all blocks were executed in one go instead of separately and respecting dependency order. No, one patch after the other was applied previously. The order of the dependencies was used to define the order of the patches to be applied. So, if the dependencies were correctly set, no problem could occur. Where do you take this from? From what I see at [1] there was exactly one patch-conf target, for the dependencies we would need one target for every cocoon block. Or do I miss something? Joerg [1] http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/tools/src/blocks-build.xsl?annotate=1.48#231
RE: cvs commit: cocoon-2.1/tools/src/anttasks XConfToolTask.java
Joerg Heinicke wrote: On 12.03.2004 13:01, Carsten Ziegeler wrote: I thought that previously all xpatches for all blocks were executed in one go instead of separately and respecting dependency order. No, one patch after the other was applied previously. The order of the dependencies was used to define the order of the patches to be applied. So, if the dependencies were correctly set, no problem could occur. Where do you take this from? Because I did it :) From what I see at [1] there was exactly one patch-conf target, for the dependencies we would need one target for every cocoon block. Or do I miss something? Actually, I don't know anymore...I only know before I change that, the dependencies weren't preserved, with the changes it worked very well. But that's the past anyway :) Carsten
Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's Rhino+continuations fork)
Isn't this missing the whole point of the current licensing discussion? If we cook up a system that allows us to create and distribute cocoon but that product now cannot be used to build a commercial application without questions of further license requirements (source code availability, etc.) have we served our users well? That's exactly the problem I have with this library system. Isn't Apache stuff that common because of its ease of use? I don't want to do license checking for every dependent project I get from somewhere. Moving this to the users is just a poor move and should be avoided if possible. It's not just about downloading one more JAR. Well, AFAIU they will only run into the same legal hassle if they try to *redistribute* cocoon as a whole!! So no problem for the simple user. If it's really a problem for the ones distributing is still the question anyway (I doubt it) But this way it's not the ASF that would have to take the responsibility for that. I guess that's the point -- Torsten
Re: Experience with workflow at Hippo Webworks
On Tue, 9 Mar 2004 14:35:42 -0600, Hunsberger, Peter [EMAIL PROTECTED] wrote: Guido Casper [EMAIL PROTECTED] writes: Hunsberger, Peter wrote: You can call it whatever you want but a state in a FSM and a continuation in a script are exactly the same thing, they need to contain the same amount of data to be able to resort the execution. The problems in replicating one across containers will be the same problems in replicating the other. Hmm, I don't think so. A FSM (in general) and a continued script are in not isomorphically equivalent in CS terms, so there can be no equivalence between the maintenance of state and the maintenance of a continuation. However, for practical purposes, I would agree, they need to contain more or less the same information. While this would be true if you are just talking about the continuation ID (while destroying the whole idea of querying the repo for task lists) you actually have to maintain the whole continuation stack. I think the point was that the extended state path list and the continuation stack would work out to the same thing. But maybe I'm missing something... I mentioned using a state path to store the current state, but I intended it a bit different then used here. Wat I actually meant was a state identifier (or set of identifiers for concurrent states). An example of a state identifier (using the diagram from the first post) is: /Existing/Reviewed/Published. This is enough information to restore the workflow instance, because like I said previously the transition history cannot affect the processing taking place at a state. Using state identifiers also makes it (relatively) easy to migrate to a new workflow definition. Either the new definition has states with identical identifiers, or the new definition can have a mapping from old state identifiers to new state identifiers. Other information needed for proper processing should be stored with the object. -- Johan Stuyts
Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's Rhino+continuations fork)
Torsten Curdt wrote: Isn't this missing the whole point of the current licensing discussion? If we cook up a system that allows us to create and distribute cocoon but that product now cannot be used to build a commercial application without questions of further license requirements (source code availability, etc.) have we served our users well? That's exactly the problem I have with this library system. Isn't Apache stuff that common because of its ease of use? I don't want to do license checking for every dependent project I get from somewhere. Moving this to the users is just a poor move and should be avoided if possible. It's not just about downloading one more JAR. Well, AFAIU they will only run into the same legal hassle if they try to *redistribute* cocoon as a whole!! So no problem for the simple user. Is a company using Cocoon to deliver web applications redistributing Cocoon? (yes, I think). Then from what I can tell, a good portion of even our own committers, not to mention people on the users list would have a problem. If it's really a problem for the ones distributing is still the question anyway (I doubt it) But this way it's not the ASF that would have to take the responsibility for that. I guess that's the point Yes, that's the point indeed. ASL is supposed to be a business-friendly license. If Cocoon uses distribution-time tricks to technically comply with the ASL but in the process nullifies its intent for some users, we have failed IMO. Geoff
Re: cvs commit: cocoon-2.1/tools/src/anttasks XConfToolTask.java
Carsten Ziegeler wrote: Joerg Heinicke wrote: On 12.03.2004 13:01, Carsten Ziegeler wrote: I thought that previously all xpatches for all blocks were executed in one go instead of separately and respecting dependency order. No, one patch after the other was applied previously. The order of the dependencies was used to define the order of the patches to be applied. So, if the dependencies were correctly set, no problem could occur. Where do you take this from? Because I did it :) From what I see at [1] there was exactly one patch-conf target, for the dependencies we would need one target for every cocoon block. Or do I miss something? Actually, I don't know anymore...I only know before I change that, the dependencies weren't preserved, with the changes it worked very well. But that's the past anyway :) Ok I understand now. There is only one global patch-conf target and it preserves dependencies. So my previous assertion that the problem with session-fw dependency needed a change in the build system was incorrect. It should have been just a matter of declaring the correct dependency. Check. Now should the changes to XConfToolTask be rolled back? I think so, unless it has other advantages. -- Unico
RE: cvs commit: cocoon-2.1/tools/src/anttasks XConfToolTask.java
Unico Hommes wrote: Now should the changes to XConfToolTask be rolled back? I think so, unless it has other advantages. Yes, it helps keeping the dependencies correct. Carsten
Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's Rhino+continuations fork)
Le Vendredi, 12 mars 2004, à 13:14 Europe/Zurich, Geoff Howard a écrit : Bertrand Delacretaz wrote: Sounds like the way to go, intelligently downloading dependencies from some non-ASF repository should solve most, maybe all of the licensing problems, and help make Cocoon more lightweight for many uses. IIRC last time this was discussed the debate quickly moved to a heated discussion on the relative merits of Maven and other similar tools - if we're going to discuss this again, we must be careful to focus on the goals rather than on the tools! Isn't this missing the whole point of the current licensing discussion? If we cook up a system that allows us to create and distribute cocoon but that product now cannot be used to build a commercial application without questions of further license requirements (source code availability, etc.) have we served our users well? ... There are several blocks already (fins for example) which cannot be distributed with Cocoon because of incompatible licenses, even though for many users these licenses wouldn't be a problem. This causes these components to get less visibility than they might deserve. I think it can only serve Cocoon to have a mechanism where such license-incompatible stuff can be better integrated from our user's point of view. IMO, allowing dependencies to be downloaded automatically from non-ASF sites would help in this respect, whatever the outcome of the current discussion about licensing is. So I think it makes sense to discuss these matters (dependencies management and licensing issues) separately. -Bertrand
Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's Rhino+continuations fork)
Is a company using Cocoon to deliver web applications redistributing Cocoon? (yes, I think). That's the question! I'd say no ...as long as you don't bundle it and sell it as part of you software removing the license or the like. But AFAIU you may use those (for us) problematic jars in your project. But hell - I am no lawyer. Then from what I can tell, a good portion of even our own committers, not to mention people on the users list would have a problem. Of course that would give a different picture. If it's really a problem for the ones distributing is still the question anyway (I doubt it) But this way it's not the ASF that would have to take the responsibility for that. I guess that's the point Yes, that's the point indeed. ASL is supposed to be a business-friendly license. If Cocoon uses distribution-time tricks to technically comply with the ASL but in the process nullifies its intent for some users, we have failed IMO. Sure I hear what you are saying ...but may those users use the jars for their projects if they were downloading them by theirselves? If yes - this is only a trick to circumvent the redistribution clause. If not - they may not use them anyway. And hiding this behind the ASL doesn't make it any better. Especially for the ASF! cheers -- Torsten
Re: cvs commit: cocoon-2.1/tools/src/anttasks XConfToolTask.java
Am Fr, den 12.03.2004 schrieb Joerg Heinicke um 13:30: On 12.03.2004 13:01, Carsten Ziegeler wrote: I thought that previously all xpatches for all blocks were executed in one go instead of separately and respecting dependency order. No, one patch after the other was applied previously. The order of the dependencies was used to define the order of the patches to be applied. So, if the dependencies were correctly set, no problem could occur. Where do you take this from? From what I see at [1] there was exactly one patch-conf target, for the dependencies we would need one target for every cocoon block. Or do I miss something? In the orginal form of the blocks-build.xsl, we had separate targets for the patch files. But it was incredible slow. Then I merge these targets to one target, and rewrote to the XConf task to a MatchingTask, which allow to execute more than one patches. But it doesn't preserves the dependencies, then Carsten cuts the target in to several target again, to solve this problem. Now, with latest change it works again. I tend to agree with you Joerg, separate targets are much more elegant. But in the real world I have real problems, like a build time von 4min 25sec on a 2.4GHz Intel system. Which is, by the way, unacceptable, IMHO. So, should I revert the change to have a more elegant build file with bigger build time?! ehrmm ... I think not. Stephan.
Re: cvs commit: cocoon-2.1 status.xml
[EMAIL PROTECTED] wrote: !-- repeater requires unique identification mechanism of the row-nodes -- !-- (it is of course possible to implement other binding strategies) -- + !-- important note: the row-path is used inside jxpath-createPath context, + as a consequence it cannot have dependent children or predicates -- fb:repeater id=contacts parent-path=. row-path=contacts unique-row-id=id unique-path=@id Why did you change that? Currently in my application I have: row-path=member[position() lt; 3] row-path=.[member/gender = 'female'] row-path=.[count(../member) gt; 1] row-path=member[id != $id] and list goes on. With your change, this app won't work anymore. So what do I do in this position? Vadim
DO NOT REPLY [Bug 27432] - Malformed HTTP headers (debug information in Parameters object)
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=27432. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27432 Malformed HTTP headers (debug information in Parameters object) [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Additional Comments From [EMAIL PROTECTED] 2004-03-12 13:48 --- I just verified the fix with the nightly snapshot from today (20040312), closing this bug now.
DO NOT REPLY [Bug 27432] - Malformed HTTP headers (debug information in Parameters object)
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=27432. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27432 Malformed HTTP headers (debug information in Parameters object) [EMAIL PROTECTED] changed: What|Removed |Added Status|VERIFIED|CLOSED
Re: Responses to workflow experiences
A summary of my interpretation of the workflow thread is available on the wiki (http://wiki.cocoondev.org/Wiki.jsp?page=Workflow). Please verify my findings and I'm sorry if I misinterpreted something. -- Johan Stuyts
DO NOT REPLY [Bug 26086] - [PATCH] Dereferencing null TextEvent() argument in JXTemplateGenerator
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=26086. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26086 [PATCH] Dereferencing null TextEvent() argument in JXTemplateGenerator [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-03-12 14:40 --- It seems that this bug is invalid now as the code refered to has been removed/rewritten
Re: [CForms] Support for multipe unique-row-id in Repeater
Joerg Heinicke wrote: On 11.03.2004 17:31, Marc Portier wrote: All together we are at: fb:repeater id=myRepeaterId parent-path=. row-path=TheRowPath fb:identity fb:value id=myId1 path=myId1/ fb:value id=myId2 path=myId2/ /fb:identity fb:on-bind fb:value id=field1 path=field1/ fb:value id=field2 path=field2/ /fb:on-bind /fb:repeater yep, sounds like the best we have ATM So, I implemented this myself. To be honest, I'm proud of this work. Not this is utter good news only that I got it working, I also had the feeling I know what I'm doing even better :-) :) Ok, it took a while to understand all the things in the code, but now it works. I tested it with the form2 binding samples. Some issues: 1. I removed the old attributes and convertor. I will also add this to the woody2cforms upgrade task. Obviously this must by solved by a stylesheet. I missed the reason to do away with the convertor, or you moved it down to the identity-binding? 2. The repeater binding has to know stuff (fieldId, xpath, convertor, etc.) from its child bindings - and this dependency is bad. With the IIRC we just duplicated that info during building in order to make sure there would not be added coupling between the repeater and it's possible children both attributes all details where known to the repeater binding builder (therefore it implemented the functionality of a second builder) and so to the repeater binding. This is no longer true for the elements. I can get the child bindings from the composed binding, but I had to open (additional getters) the value binding to get the values no longer available to the repeater binding otherwise. afraid I don't understand completely yet This issue goes on: I expect value bindings as child bindings, nothing else (would result in ClassCastException at the moment). I could imagine the use of other bindings here too: the simplest is the context binding, which seems to be absolutely valid, but not working, because there is no chance to get the values from a value binding which is a child of a context binding which is a child of the identity binding. The extreme would be a repeater binding: imagine a list of persons that have a list of biometrical data that constitute the identity of those persons. All together: there is now a dependency of the repeater binding on its child bindings. We can restrict the allowed child elements of fb:identity to fb:value that reduces the problem to current minimum, but maybe something else is needed. oh, I'm starting to see the light again... damn, I have to check in the maillinglist to see if this was just a personal mental note or a discussed proposal, but in any case: IMHO this calls for an additional method on the binding interface, next to load() and save() we should be able to ask for isMatch() or even better isIdentical() wdyt? I read all the threads and use cases. And yes, a unification of the pfew, you are a brave man :-) I need some time to list all changes, proposals, enhancements that were partially discussed but haven't got into code yet That would be interesting. I guess while reading I lost at least half of the stuff ... Also the unification for binding to bean or XML is a one. This ends at the latest with the repeater at the moment as the @parent-path/@row-path is different for beans and XML. hm, I've experienced this myself now and then, but I'm afraid this is out of our league, jxpath imposes an XML way of looking at your java-bean that is sometimes 'surprising': Yes, I know and fear this. what most naturally looks like the standard java version of an xml snippet seems (often due to technical limitations that however logic need some thought to grasp) to be behaving different in the jxpath view next to this observation however I'ld like to question the real-life relevance: IMHO the advantage of jxpath under the hood of the binding is that it allows for reusing the syntax-metafor of xpath regardless of the backend. Being the mix of using slashes over dots, not needing parentheses and having a single expression that equally works for getting and setting (LHV/RHV) When it would work regardless of the backend ... yeah, but currently the regardless only realtes to the syntax being portable over to the backend, not the semantics or in other words: the semantics are imposed onto the backend by jxpath what I want to say is: it DOES work, but only if the backends are equal in the jxpath sense of the word :-) I don't see it as a common use case that people during the lifetime would want to switch the backend from XML to JavaBeans (or vice versa) and actually expect to have all binding expressions work 'justlikethat'. While developing we often encoupled the backend from the frontend. The interface between both was a simple XML structure. The frontend knows what it will get, the backend what it has to deliver when the system is running. This allows
DO NOT REPLY [Bug 25391] - [PATCH] AbstractTextSerializer use of Configuration.getLocation() incompatible with AvalonFramework 4.1.5
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=25391. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=25391 [PATCH] AbstractTextSerializer use of Configuration.getLocation() incompatible with AvalonFramework 4.1.5 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED
DO NOT REPLY [Bug 25437] - [PATCH] TreeProcessor.ForwardEnvironmentWrapper should delegate isResponseModified/setResponseIsNotModified to wrapped environment
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=25437. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=25437 [PATCH] TreeProcessor.ForwardEnvironmentWrapper should delegate isResponseModified/setResponseIsNotModified to wrapped environment [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED
DO NOT REPLY [Bug 26854] - [PATCH] redirect problems
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=26854. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26854 [PATCH] redirect problems --- Additional Comments From [EMAIL PROTECTED] 2004-03-12 15:01 --- The internal redirects have changed recently in CVS, could you please check if your problems still exist?
DO NOT REPLY [Bug 27602] - Small Improvment for AbstractReader
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=27602. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27602 Small Improvment for AbstractReader [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED
DO NOT REPLY [Bug 27066] - [PATCH] TreeProcessor, unreleased components
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=27066. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27066 [PATCH] TreeProcessor, unreleased components --- Additional Comments From [EMAIL PROTECTED] 2004-03-12 15:18 --- The first attachment (10428) isn't necessary and should not be applied. All implementations implement the Component interface, so an Interpreter can be used with ECM, but has the be casted on release. This is because the Component interface has been deprecated in favour of the ServiceManager/Serviceable construct.
Re: [CForms] Support for multipe unique-row-id in Repeater
Marc Portier mpo at outerthought.org writes: I missed the reason to do away with the convertor, or you moved it down to the identity-binding? The convertor was only for @unique-row-id and @unique-path and as I removed these I also removed that. The identity binding itself is just a composed binding. The value bindings do have a convertor themselves. 2. The repeater binding has to know stuff (fieldId, xpath, convertor, etc.) from its child bindings - and this dependency is bad. IIRC we just duplicated that info during building in order to make sure there would not be added coupling between the repeater and it's possible children Maybe I understand something wrong, but I don't agree with your recall: The handling of @unique-row-id and @unique-path was completely in RepeaterJXPathBindingBuilder [1] and RepeaterJXPathBinding [2]. So the repeater binding did also the work of the ValueJXPathBindingBuilder and so knew all values for latter usage. Nothing was duplicated AFAICS. This is no longer true for the elements. I can get the child bindings from the composed binding, but I had to open (additional getters) the value binding to get the values no longer available to the repeater binding otherwise. afraid I don't understand completely yet You don't have access to the field and its value of the child binding by default. For the repeater you now need the values, otherwise you can not build the identity of a row. All together: there is now a dependency of the repeater binding on its child bindings. We can restrict the allowed child elements of fb:identity to fb:value that reduces the problem to current minimum, but maybe something else is needed. oh, I'm starting to see the light again... damn, I have to check in the maillinglist to see if this was just a personal mental note or a discussed proposal, but in any case: IMHO this calls for an additional method on the binding interface, next to load() and save() we should be able to ask for isMatch() or even better isIdentical() wdyt? But fb:identity is a composed binding that would need to collect the values of its child bindings (fb:value or others, there is also no access to those ATM). next to this observation however I'ld like to question the real-life relevance: IMHO the advantage of jxpath under the hood of the binding is that it allows for reusing the syntax-metafor of xpath regardless of the backend. Being the mix of using slashes over dots, not needing parentheses and having a single expression that equally works for getting and setting (LHV/RHV) When it would work regardless of the backend ... yeah, but currently the regardless only realtes to the syntax being portable over to the backend, not the semantics An important difference indeed :) or in other words: the semantics are imposed onto the backend by jxpath what I want to say is: it DOES work, but only if the backends are equal in the jxpath sense of the word Yes, I put the blame on jxpath. While developing we often encoupled the backend from the frontend. The interface between both was a simple XML structure. The frontend knows what it will get, the backend what it has to deliver when the system is running. This allows independent development. Additionally we had static test XML files for the frontend, so that real life test is possible. The switching was just in the sitemap (XML from disk or from backend). Now I would have to maintain two binding files. hm, all falls with the line 'backend knows what it has to deliver' is that *knowing* really according to 'semantics as imposed by jxpath' and not according to 'most naive/simplistic view of the structure'? It was with Cocoon 2.0 (no JXPath, no beans, no woody) and just an arbitrary complex XML comming either from disk (static file) or XSP (the backend), but this XML structure was the interface. I could go on questioning if the static XML is a big gain over a static hard-coded Java that builds some bean instances rather then load them from the real backend... Indeed, new techniques sometimes need adapted developing. however, thinking about it constructively I think here and now the best we can do is build some docos/catalogue offering the real XML/jxpath view on some classic bean constructs? Yes, though it would belong more to JXPath itself and should be maintained there. Maybe it already exists. Thanks for your reply, Joerg [1] http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/woody/ java/org/apache/cocoon/woody/binding/RepeaterJXPathBindingBuilder.java? annotate=1.12#114 [2] http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/woody/ java/org/apache/cocoon/woody/binding/RepeaterJXPathBinding.java? annotate=1.20#121
Re: BATCH: All dressed up, with nowhere to go...
Stefano Mazzocchi stefano at apache.org writes: - Error - No such directory (where output is expected) : /data3/gump/cocoon-2.1/src/blocks/forms/lib I think the woody-cform name changes broke this. Can anybody take a look? thanks. I guess just gump.xml is broken, the JAR has been moved to lib/optional. Joerg
RE: Using Maven (or something similar) for dependencies? (Was: Co coon's Rhino+continuations fork)
Geoff, I totally agree with the statements you are making below. While I have no problem with blocks that are clearly marked as having redistribution licensing problems being part of Cocoon, the core components MUST not have this problem. Even moving flow to a block will not change it from being a core component because so many other blocks are tying into it. So this kind of tying must be done very carefully and judiciously in my opinion. While I am all in favor of using Maven, or some tool like it, to manage dependencies, I really don't see how that has anything to do with licensing. Whether Cocoon is pre-packaged at cocoon.apache.org, or the end-user has to build it at their site, it really makes no difference. If a Cocoon customer cannot add on whatever value they choose and then distribute their product with Cocoon included, this is a violation of the Apache license, at least in spirit. Ralph -Original Message- From: Geoff Howard [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 5:08 AM To: [EMAIL PROTECTED] Subject:Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's Rhino+continuations fork) Well, AFAIU they will only run into the same legal hassle if they try to *redistribute* cocoon as a whole!! So no problem for the simple user. Is a company using Cocoon to deliver web applications redistributing Cocoon? (yes, I think). Then from what I can tell, a good portion of even our own committers, not to mention people on the users list would have a problem. If it's really a problem for the ones distributing is still the question anyway (I doubt it) But this way it's not the ASF that would have to take the responsibility for that. I guess that's the point Yes, that's the point indeed. ASL is supposed to be a business-friendly license. If Cocoon uses distribution-time tricks to technically comply with the ASL but in the process nullifies its intent for some users, we have failed IMO. Geoff
RE: Using Maven (or something similar) for dependencies? (Was: Co coon's Rhino+continuations fork)
FYI, My company is a large ASP. Each of our customers runs our products as if from their own web site, although they are all sharing the same code. Our development effort is using Cocoon as our Presentation Tier for our products, as it allows us to totally customize the look and feel for each of our customers. Eventually we also want to package the product and sell it to large customers who want to run it at their site. Of course, this will include Cocoon. Obviously, the kind of tricks being talked about here would not allow us to redistribute Cocoon. Our customers would have to get it themselves - which, of course, is totally unacceptable. Ralph -Original Message- From: Torsten Curdt [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 5:32 AM To: [EMAIL PROTECTED] Subject:Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's Rhino+continuations fork) Is a company using Cocoon to deliver web applications redistributing Cocoon? (yes, I think). That's the question! I'd say no ...as long as you don't bundle it and sell it as part of you software removing the license or the like. But AFAIU you may use those (for us) problematic jars in your project. But hell - I am no lawyer. cheers -- Torsten
RE: SomeClass.getClass() in flow
Just use: var user = session.load(User, id); So easy and works like a charm. Thank you. Leszek Gawron
Re: Using Maven (or something similar) for dependencies? (Was: Co coon's Rhino+continuations fork)
Obviously, the kind of tricks being talked about here would not allow us to redistribute Cocoon. Our customers would have to get it themselves - which, of course, is totally unacceptable. Wait, wait, wait... from what I understand you may! ...but *you* would have take care to respect all the licenses that are included in this redistribution by *yourself*! Seems like the ASF wants to step back not covering the risk anymore. Or am I here on the wrong track? -- Torsten
RE: Using Maven (or something similar) for dependencies? (Was: Co coon's Rhino+continuations fork)
Lets take this to the extreme. Pretend that Rhino was a GPL license. Sure I could download Rhino and get a running Cocoon. But I could never sell a product based on Cocoon unless I make my customers also download Rhino (and I'm not sure even that would be legal). Since so many parts of Cocoon want to leverage Flow these days this would make the situation impossible. And although Rhino isn't GPL, from what I read of the Mozilla license it also has the requirement that anything that it is packaged with must also be under the Mozilla license, which makes it just as bad as the GPL from a commercial standpoint. I don't mean to pick on Rhino in particular here, but it is a convenient example. Ralph -Original Message- From: Torsten Curdt [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 8:54 AM To: [EMAIL PROTECTED] Subject:Re: Using Maven (or something similar) for dependencies? (Was: Co coon's Rhino+continuations fork) Obviously, the kind of tricks being talked about here would not allow us to redistribute Cocoon. Our customers would have to get it themselves - which, of course, is totally unacceptable. Wait, wait, wait... from what I understand you may! ...but *you* would have take care to respect all the licenses that are included in this redistribution by *yourself*! Seems like the ASF wants to step back not covering the risk anymore. Or am I here on the wrong track? -- Torsten
Re: Responses to workflow experiences
Johan Stuyts wrote: A summary of my interpretation of the workflow thread is available on the wiki (http://wiki.cocoondev.org/Wiki.jsp?page=Workflow). Please verify my findings and I'm sorry if I misinterpreted something. Thanks for your work, it is really appreciated! Just FYI: I've added an additional workflow solution and a section listing some interesting workflow standards. Not all may be applicable for Cocoon, but they may provide some valuable input though. Bye, Andreas
Re: cvs commit: cocoon-2.1 status.xml
Vadim wrote: Hello Vadim, as I can not reply to your mail (gmane does not list those mails replying to a mail on [EMAIL PROTECTED]) I answer with an extra mail for now: Now moving it back to list. + !-- important note: the row-path is used inside jxpath-createPath context, + as a consequence it cannot have dependent children or predicates -- Why did you change that? Currently in my application I have: row-path=member[position() 3] row-path=.[member/gender = 'female'] row-path=.[count(../member) 1] row-path=member[id != $id] and list goes on. With your change, this app won't work anymore. So what do I do in this position? Are you refering directly to the comment? I did not add it, I just moved it around. Ok, can you at least tell me whether above example row-paths will work with this new CForms or not? AFAIU/K it's a limitation of JXPath and has nothing to do with Woody/CForms. This should mean if it works til now it will work in future. Maybe you have provided an additional @row-path-insert? I also found this issue when reading the threads about repeater bindings, but don't no more which and who exactly: http://marc.theaimsgroup.com/?t=10697645531r=1w=2 http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107049618519927w=2 http://marc.theaimsgroup.com/?t=10705082112r=1w=2 Maybe Marc can tell us more about it. And maybe you can just test the upgrade task and test it with cforms :) I will add a stylesheet for the changed syntax to it too. Joerg
Re: Using Maven (or something similar) for dependencies? (Was: Co coon's Rhino+continuations fork)
Lets take this to the extreme. Pretend that Rhino was a GPL license. Sure I could download Rhino and get a running Cocoon. But I could never sell a product based on Cocoon unless I make my customers also download Rhino (and I'm not sure even that would be legal). Since so many parts of Cocoon want to leverage Flow these days this would make the situation impossible. Well, since you put it to the extreme - you got a point And although Rhino isn't GPL, from what I read of the Mozilla license it also has the requirement that anything that it is packaged with must also be under the Mozilla license, which makes it just as bad as the GPL from a commercial standpoint. I guess the problem is that packaging with is a bit blurry. What are we talking about? What a about a RH CD which comes with Mozilla, which is under MPL. Does all packages on the CD have to be under MPL? I personally don't think downloading-on-demand is really that bad at all. (If done nicely!) But let's wait what the board comes up with. It may or may not expose this discussion being a waste of time ;) -- Torsten
Re: Using Maven (or something similar) for dependencies? (Was: Co coon's Rhino+continuations fork)
Ralph Goers wrote: ... And although Rhino isn't GPL, from what I read of the Mozilla license it also has the requirement that anything that it is packaged with must also be under the Mozilla license, which makes it just as bad as the GPL from a commercial standpoint. ... Ralph Hum that's the same impression I got after reading the responses on this list by some of the Mozilla people. But there seems to be a difference in the MPL (http://www.mozilla.org/MPL/MPL-1.1.html) between modifying source code and using the executable in a larger piece of software. When you modify the source code 3.1 clearly states that these modifications should be MPL as well: The Modifications which You create or to which You contribute are governed by the terms of this License. But when you simply use the executable version of MPL code in a larger piece of software 3.7 says the following: You may create a Larger Work by combining Covered Code with other code not governed by the terms of this License and distribute the Larger Work as a single product. In such a case, You must make sure the requirements of this License are fulfilled for the Covered Code. Note that the end of the line says Covered Code and not Larger Work. So the Covered Code that is MPL, stays MPL. But anything surrounding it (Larger Work) does *not* automatically become MPL as well . This is (IMHO) the difference with GPL. But IANAL... -- Litrik De Roy www.litrik.com
FW: Cocoon and Globus
-Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Luca Morandini Sent: Friday, March 12, 2004 3:48 AM To: [EMAIL PROTECTED] Subject: Re: Cocoon and Globus Rafael Alvarado wrote: I am looking for any information about how Cocoon has been, or may be, integrated with the Globus Toolkit to create grid applications. It seems that Cocoon can play a key role in may respects, given that generators and transformers can be defined for the myriad protocols and services that exist in a grid. I can imagine that a very good grid portal could be written in Cocoon. Rafael C. Alvarado Manager of Humanities Computing Research Applications 316 87 Prospect | Princeton University This question may be better answered by the Cocoon developers, whose list is: [EMAIL PROTECTED] Regards, --- Luca Morandini [EMAIL PROTECTED] http://www.lucamorandini.it --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Experience with workflow at Hippo Webworks
Hunsberger, Peter wrote: Well I probably don't need to repeat my biases to Stephano, but once more: you need a Turing complete language to write work flow in. You need to be able to dynamically modify any given work flow instance. FSM's can't do this, perhaps some other forms of state machines can do this, but now you're heading into CS esoteria. Let's use the machinery that Cocoon already ships with... Yep, I agree [which is interesting, we never could reach agreement on anything in the past ;-)] -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
RE: Experience with workflow at Hippo Webworks
Stefano Mazzocchi [EMAIL PROTECTED] writes: Hunsberger, Peter wrote: Well I probably don't need to repeat my biases to Stephano, but once more: you need a Turing complete language to write work flow in. You need to be able to dynamically modify any given work flow instance. FSM's can't do this, perhaps some other forms of state machines can do this, but now you're heading into CS esoteria. Let's use the machinery that Cocoon already ships with... Yep, I agree [which is interesting, we never could reach agreement on anything in the past ;-)] Heh, heh, maybe I'm finally wearing you down? Or maybe you've finally seen the beauty of XSLT? Hmm, better not get you started on another angle bracket rant...
Re: [Vote] Moving XSP into its own block
Stephan Michels wrote: Am Di, den 09.03.2004 schrieb Bertrand Delacretaz um 16:37: We should move XSP in a block anyway. +1 from Stefano, Antonio, Reinhard +0.5 (=good idea, won't be able to help) I can offer some help, if nobody on it, then I can try it?! Go right ahead! -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [Summary] [Vote] Moving XSP into its own block
Unico Hommes wrote: Carsten Ziegeler wrote: Torsten Curdt wrote: Carsten Ziegeler wrote: Unico Hommes wrote: I tend to think the dependency is from session-fw on xsp, not the other way around. Unless this becomes really difficult to accomplish I'd prefer keeping it the way it is now. I will do some research as to what would be involved to change the build system to accomodate this. But this then makes removing xsp more difficult :) I really think we should keep all xsp related stuff in one place. This makes the whole thing easier to handle but also is more transparent for users. They have one single place to look for logicsheets. Hm... I think it's hard to classify... Do you also want to move the e.g. ESQL logicsheet into the XSP block? IMO that would not be a good idea. True...hmm...ok, then whoever does it should decide :) I see your point of placing the burden of dependencies with xsp though. We could take that as a guideline whenever there isn't a clear reason to do otherwise. I'm starting to realize that XSP is an aspect not a block... maybe we should have two different concepts? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Rhino
Ralph Goers wrote: After yesterday's message from Brian Behlendorf, and reviewing the mozilla license, it seems pretty clear that Cocoon 2.1.x is covered under the Mozilla license rather than apache's by its inclusion of Rhino. Since I have seen no responses here to his message I have to assume that discussions must be going on in the background. I'd appreciate some feedback here as it appears the only current way to resolve this is to remove Rhino from Cocoon. Ralph, the worst case scenario is that cocoon will ship without rhino and a script will download it for you at installation time. This would obviously saturate cocoon-dev.org's pipe (since we can't use the ASF infrastructure system to distribute non-ASF stuff) so we are working hard to avoid this and find a much better solution. the best case scenario is that our continuations patches get merged with the official rhino version and that the ASF finds a policy that allows us to keep distributing it or mozilla relicenses it. Do not worry, there is intense activity in the background and I am confident that we'll have very good outcomes out of this discussion. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Cocoon's Rhino+continuations fork
Hey Paul, welcome back! :-) Paul Russell wrote: On 10 Mar 2004, at 19:51, Steven Noels wrote: (OT for the non-ASF folks:) You seem to suggest that inclusion of non-ASL-licensed library dependencies inside ASF distributions should be deprecated, favoring a CPAN or FreeBSD ports -like mechanism instead. This will definitely lower the ease of use for end-users, which have been complaining already that we don't ship a binary distribution of Cocoon, let alone that we would ship a download which requires them to either hunt down additional packages themselves, or have an internet connection when installing Cocoon. ... which brings me around to something I've been pondering for a while. Since Cocoon is a bit of a 'hub' in the open source world, it brings together a stack of external libraries. Including these in the core source distribution is clunky and painful for everyone. Have we considered using Maven or similar to help manage these dependancies? I'm still playing catch up with the architectural changes within cocoon (this is still very much a part time job for me right now), so I don't know how this would tie up with Blocks. I do know however that the Geronimo project uses Maven to great effect, and they do separate modules with their own code trees etc, so this may be a prior art. Thoughts? Search the wiki and for blocks and read that first :-) -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Using Maven (or something similar) for dependencies?
Ugo Cei wrote: Reinhard Pötz wrote: And instead of investing to much time in all those things we should make CocoonBlocks become reality ASAP because they will solve those dependencies very elgantly. I'd say *most* of those dependencies, but not all of them. Flowscript is part of the core, for instance. very true, real block are not enough. We need two systems: a higher level one (real blocks) and a lower level one (jars). There are two ways of doing a package distributor: 1) package it yourself [rpm,deb,war] 2) provide metadata and tools [port,gentoo] I came to the conclusion (also after working with gump for a while) that 2) is the way to go. [thanks to Pier for opening my eyes on this!] but the painful thing is that not all jars are distributable standalone for legal reasons. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Using Maven (or something similar) for dependencies? (Was: Co coon's Rhino+continuations fork)
On 12.03.2004 17:54, Torsten Curdt wrote: Wait, wait, wait... from what I understand you may! ...but *you* would have take care to respect all the licenses that are included in this redistribution by *yourself*! Seems like the ASF wants to step back not covering the risk anymore. But if that's true what's the right to exist for the ASF from just the legal point of view? They break exactly this part what made it popular to use Apache stuff: mostly no risk through any legal issues. These copyright and license issues can really jam all the (open source) software development - but what happens when they introduce software patents additionally in Europe? Joerg
Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's Rhino+continuations fork)
Geoff Howard wrote: Bertrand Delacretaz wrote: Sounds like the way to go, intelligently downloading dependencies from some non-ASF repository should solve most, maybe all of the licensing problems, and help make Cocoon more lightweight for many uses. IIRC last time this was discussed the debate quickly moved to a heated discussion on the relative merits of Maven and other similar tools - if we're going to discuss this again, we must be careful to focus on the goals rather than on the tools! Isn't this missing the whole point of the current licensing discussion? If we cook up a system that allows us to create and distribute cocoon but that product now cannot be used to build a commercial application without questions of further license requirements (source code availability, etc.) have we served our users well? wait! let's keep reasonable here, ok? We are distributing cocoon today and it's *already* a legal hell to go thru to find out how to package cocoon in a commercial product and redistribute it. The cocoon *code* is licensed under the apache license, the libraries are licensed according to the /legal directory, as we specify in the README file. Brian thinks that this is not enough and yields the false impression that *everything* is licensed under the apache license. Not everybody agrees with him. But due to the nature of cocoon, installations are just that: installations. 99% of our users do not redistribute cocoon as part of their system. They use it to provide a service. And, if they do redistribute cocoon as a part of their software, they will need to comply to *ALL* the licenses that we ship. [but since we did the job for them to screen the compatibilities, they have to make sure that they comply to the other things, like IP and patent rights] If we do not redistribute, say, Rhino, this makes it more obvious that they have to comply to the license because they have to download it themselves... but if we do it thru a package manager, well, it's the same thing. IMHO, stopping distributing libraries under the MPL doesn't buy us nothing, the legal issues are all already there, we should just make it more obvious when the user downloads our distribution. NOTE: legal issues are nasty with IP and patents anyway. Open source is not freeing you from living in the real world, unfortunately. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
RE: Using Maven (or something similar) for dependencies? (Was: Co coon's Rhino+continuations fork)
On general principal I agree with you. I have no problem with having certain blocks require that you download software from wherever under whatever license. The problem comes about when you start having other blocks require the first block as a prereq and the prereq has an unacceptable license. In other words, I don't believe an Apache project should ever rely on other software with an incompatible license for its core functionality. In some sense, the way Cocoon is organized can help this. One would expect that the core of Cocoon itself would be free of ANY licensing issues. Blocks, on the other hand, might not be. In fact, blocks.properties as well as the blocks description web pages could clearly identify what components they require and what the licenses for them are. However, one would expect that blocks such as cocoon forms, the authentication framework, session framework, etc. would also be free of issues. Ralph -Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 2:26 PM To: [EMAIL PROTECTED] Subject:Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's Rhino+continuations fork) wait! let's keep reasonable here, ok? We are distributing cocoon today and it's *already* a legal hell to go thru to find out how to package cocoon in a commercial product and redistribute it. The cocoon *code* is licensed under the apache license, the libraries are licensed according to the /legal directory, as we specify in the README file. Brian thinks that this is not enough and yields the false impression that *everything* is licensed under the apache license. Not everybody agrees with him. But due to the nature of cocoon, installations are just that: installations. 99% of our users do not redistribute cocoon as part of their system. They use it to provide a service. And, if they do redistribute cocoon as a part of their software, they will need to comply to *ALL* the licenses that we ship. [but since we did the job for them to screen the compatibilities, they have to make sure that they comply to the other things, like IP and patent rights] If we do not redistribute, say, Rhino, this makes it more obvious that they have to comply to the license because they have to download it themselves... but if we do it thru a package manager, well, it's the same thing. IMHO, stopping distributing libraries under the MPL doesn't buy us nothing, the legal issues are all already there, we should just make it more obvious when the user downloads our distribution. NOTE: legal issues are nasty with IP and patents anyway. Open source is not freeing you from living in the real world, unfortunately. -- Stefano.
Re: Using Maven (or something similar) for dependencies? (Was: Co coon's Rhino+continuations fork)
Ralph Goers wrote: FYI, My company is a large ASP. Each of our customers runs our products as if from their own web site, although they are all sharing the same code. Our development effort is using Cocoon as our Presentation Tier for our products, as it allows us to totally customize the look and feel for each of our customers. Eventually we also want to package the product and sell it to large customers who want to run it at their site. Of course, this will include Cocoon. Obviously, the kind of tricks being talked about here would not allow us to redistribute Cocoon. Our customers would have to get it themselves - which, of course, is totally unacceptable. Ralph, it is enough that your company reads all the licenses of the libraries in the /legal directory that come with cocoon and complies to the restrictions that they impose when redistributing the code. That's it. We are trying to address the problem of people believing that it's enough for them to say this includes software by the ASF and fail to comply to those other licenses, so if they get sued, they sue us back for not having been clear about how we license our stuff and blame us. I personally think it's just SCO-induced paranoia and can be addressed with a big red blinking sign but hey, I'm not the lawyer and I'm not the one who gets to decide those things. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Using Maven (or something similar) for dependencies? (Was: Co coon's Rhino+continuations fork)
Ralph Goers wrote: FYI, My company is a large ASP. Each of our customers runs our products as if from their own web site, although they are all sharing the same code. Our development effort is using Cocoon as our Presentation Tier for our products, as it allows us to totally customize the look and feel for each of our customers. Eventually we also want to package the product and sell it to large customers who want to run it at their site. Of course, this will include Cocoon. Obviously, the kind of tricks being talked about here would not allow us to redistribute Cocoon. Our customers would have to get it themselves - which, of course, is totally unacceptable. Ralph -Original Message- From: Torsten Curdt [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 5:32 AM To: [EMAIL PROTECTED] Subject: Re: Using Maven (or something similar) for dependencies? (Was: Cocoon's Rhino+continuations fork) Is a company using Cocoon to deliver web applications redistributing Cocoon? (yes, I think). That's the question! I'd say no ...as long as you don't bundle it and sell it as part of you software removing the license or the like. But AFAIU you may use those (for us) problematic jars in your project. But hell - I am no lawyer. cheers -- Torsten Definitely no I would hope. I have been tacking copyright on the bottom of all my stuff thinking of cocoon as httpd I put copyright joecompany.com on a regular web site, and no one has ever implied I was infringing on httpd. Not the server the pages are served by. However, I think it would be different if I jarred my stuff up with cocoon and a jdk, and gave it to a cutsomer to run on a local network. *that*, I think, constitutes redistributing. As far as distributing cocoon, we are talking about guys like me, who are designing data systems for the customers. *we* are the ones who need to configure up a server to provide the *service* of cocoon for our systems to utilize, not a redistributable product. My customers have no idea they are using cocoon. I show them where to type, what to click, and watch them get giddy when I tell them they don't need to spend thousands on a M$ framework. (My newest was using access, and discovered he needed to reverse his personal upgrade, or have his whole office upgraded to office 2003... when I showed him a demo of some other stuff, he never asked, just said yup ok go) So, if we have to get rhino as a separate package.. it will be us who has to deal with it, and most of us know what we have signed on for. It will suck getting new people interested, true, But putting this in the context of final end-business-customers downloading and running cocoon is not really a wise way to approach the subject JD
Re: cvs commit: cocoon-2.1 status.xml
Joerg Heinicke wrote: Ok, can you at least tell me whether above example row-paths will work with this new CForms or not? AFAIU/K it's a limitation of JXPath and has nothing to do with Woody/CForms. This should mean if it works til now it will work in future. Maybe you have provided an additional @row-path-insert? I don't do inserts there :-) I guess this remark applicable only when repeater tries to insert row. I have to test this and improve the comment Thanks, Vadim
Re: Using Maven (or something similar) for dependencies? (Was: Co coon's Rhino+continuations fork)
Litrik De Roy wrote: Ralph Goers wrote: ... And although Rhino isn't GPL, from what I read of the Mozilla license it also has the requirement that anything that it is packaged with must also be under the Mozilla license, which makes it just as bad as the GPL from a commercial standpoint. ... Ralph Hum that's the same impression I got after reading the responses on this list by some of the Mozilla people. But there seems to be a difference in the MPL (http://www.mozilla.org/MPL/MPL-1.1.html) between modifying source code and using the executable in a larger piece of software. When you modify the source code 3.1 clearly states that these modifications should be MPL as well: The Modifications which You create or to which You contribute are governed by the terms of this License. But when you simply use the executable version of MPL code in a larger piece of software 3.7 says the following: You may create a Larger Work by combining Covered Code with other code not governed by the terms of this License and distribute the Larger Work as a single product. In such a case, You must make sure the requirements of this License are fulfilled for the Covered Code. Note that the end of the line says Covered Code and not Larger Work. So the Covered Code that is MPL, stays MPL. But anything surrounding it (Larger Work) does *not* automatically become MPL as well . This is (IMHO) the difference with GPL. you are 100% correct. The MPL is *NOT* a reciprocal license (viral is a bad term) in respect to the code that surrounds it, but it is for the modifications inside. So, this means that if Chris puts those modifications under the MPL 1.1, we are kosher. Anyway, people, let's not freak out: there is *NOTHING* going on to change the status quo. What you were able to do yesterday with the code, you are able to do today and you'll be able to continue to do tomorrow. Period. The ASF is just trying cover all possible ass here, so that we can serve our users better in order to guarantee that we'll still be around tomorrow. Because, since SCO arrived in town you never know. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: BATCH: All dressed up, with nowhere to go...
[EMAIL PROTECTED] wrote: G U M P [EMAIL PROTECTED]: cocoon-2.1/xreporter-expression failed To whom it may engage... This is an automated request, but not an unsolicited one. For help understanding the request please visit http://gump.apache.org/nagged.html, and/or contact [EMAIL PROTECTED] Project xreporter-expression has an issue affecting it's community integration. This issue affects 4 projects, and has been outstanding for 3 runs. The current state is 'Failed', for reason 'Missing Build Outputs' Full details are available at: http://lsd.student.utwente.nl/gump/cocoon-2.1/xreporter-expression.html, however some snippets follow: - - - - - -- -- G U M P Gump provided these annotations: - Info - Sole jar [/data3/gump/cocoon-2.1/src/blocks/forms/lib/xreporter-expression-20030725.jar] identifier set to project name - Info - Enable verbose output, due to error. - Error - Failed with reason missing build outputs - Error - Missing Output: /data3/gump/cocoon-2.1/src/blocks/forms/lib/xreporter-expression-20030725.jar - Error - No such directory (where output is expected) : /data3/gump/cocoon-2.1/src/blocks/forms/lib I think the woody-cform name changes broke this. Can anybody take a look? thanks. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
