Re: Importing Cocoon projects into Eclipse
Mark Lundquist skrev: OK... On Jan 10, 2007, at 2:50 PM, Daniel Fagerstrom wrote: For resources it works as you want OOTB, if you run from Eclipse. What is important is that you run mvn eclipse:eclipse from top level. If you do that (and import the needed projectts into Eclipse), I ran mvn eclipse:eclipse; now which projects do I need to import, and what's the easiest way to do it? :-) (again, my goal here is to run the cocoon-webapp w/ samples using the Eclipse Jetty plugin...) File - Import ... - General - Existing projects into workspace - Point on a directory that contains the project, it will be scanned for Eclipse project descriptors. It takes some time for Eclipse to scan all of cocoon-trunk. Choose the projects you want. Take a look at properties - Java build path for the project, to see what other projects it depends on and make sure that you import all dependencies. /Daniel
Re: project/description request
Mark Lundquist skrev: Hi, I'd like to make a modest request... if those who know how could add a little something to the description element in the various poms, I think it would help make the source base more broadly accessible, i.e. beyond the inner circle of people who have done the heavy lifting... :-) And going forward, IMHO all new modules should include some kind of what is this? readme info in the pom description. Seem like a good idea. For instance (and this is just a for instance...), I see that we have cocoon-sitemap-components and cocoon-pipeline-components, and I have no clue why a component should be in one module vs. the other. Maybe I don't really have an urgent need to know, but probably knowing why there are both modules and what the difference is would help me to understand the Cocoon architecture better. Read http://marc.theaimsgroup.com/?l=xml-cocoon-devm=116740983716752w=2. /Daniel
call a function not in global object in map:call
Hi, Does anyone know whether the function mentioned in http://www.mail-archive.com/dev@cocoon.apache.org/msg47930.html works now? Rice
Re: RCL difficulties (was Re: Input modules samples broken in trunk)
Daniel Fagerstrom wrote: It is also important to have -Dorg.apache.cocoon.mode=develop as argument to the Jetty launcher, otherwise the tree processor will not reload the resources when they change. The correct name for the mode is dev, so you have to specify -Dorg.apache.cocoon.mode=dev Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: call a function not in global object in map:call
On Jan 11, 2007, at 1:36 AM, Rice Yeh wrote: Does anyone know whether the function mentioned in http://www.mail-archive.com/dev@cocoon.apache.org/msg47930.html works now? phooey... I forgot to submit this patch to JIRA :-(. Doing it now... —ml—
Re: call a function not in global object in map:call
On Jan 11, 2007, at 6:08 AM, Mark Lundquist wrote: On Jan 11, 2007, at 1:36 AM, Rice Yeh wrote: Does anyone know whether the function mentioned in http://www.mail-archive.com/dev@cocoon.apache.org/msg47930.html works now? phooey... I forgot to submit this patch to JIRA :-(. Doing it now... Never mind! :-) I never submitted it to JIRA because I didn't need to. Jeremy Quinn asked for this feature, and that reminded me how it was something I had wanted also, so I made a patch and emailed it so he could try it out — I think I didn't JIRA it at first because I wasn't sure if the committers would think it was the right way to implement it (not that I think there's anything wrong with it :-). Anyway, it turns out that Jeremy committed this along with some of his other changes. So this made it into the 2.1.10 release, and it's also in trunk. —ml—
Re: Input modules samples broken in trunk
On Jan 10, 2007, at 10:15 PM, Reinhard Poetz wrote: try http://cocoon.zones.apache.org/daisy/cdocs-rcl-plugin/g1/1297.html OK, so let me make sure I understand... I want to make changes to sitemap, XLST, XML sources etc. within a block and have those changes take effect immediately in the running Cocoon. IIUC, there are two ways to do this: 1) By using the reloading classloader; 2) By using the Eclipse Jetty Launcher. Is that right? —ml—
Re: Cocoon API still refers to cocoon 2.1.9
Robby Pelssers, AGP wrote: Hi guys, how come http://cocoon.apache.org/2.1/apidocs/index.html still points to API 2.1.9? Or is only the name wrong? Thanks for the info - it was still the old content. I updated the docs to 2.1.10. Thanks Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Input modules samples broken in trunk
Mark Lundquist wrote:
On Jan 10, 2007, at 10:15 PM, Reinhard Poetz wrote:
try http://cocoon.zones.apache.org/daisy/cdocs-rcl-plugin/g1/1297.html
OK, so let me make sure I understand...
I want to make changes to sitemap, XLST, XML sources etc. within a block
and have those changes take effect immediately in the running Cocoon.
IIUC, there are two ways to do this:
1) By using the reloading classloader;
2) By using the Eclipse Jetty Launcher.
Is that right?
Definitly with 1). Haven't tried 2) myself but it works for Daniel. So yes,
you're right.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: RCL difficulties (was Re: Input modules samples broken in trunk)
On Jan 10, 2007, at 10:20 PM, Reinhard Poetz wrote: I just tried setting up the RCL per http://cocoon.zones.apache.org/daisy/cdocs/g1/g4/g1/1297.html; is that the solution I'm after? I added the rcl.properties to cocoon-core-addition-sample/pom.xml and tweaked the cocoon-webapp/pom.xml, ran mvn rcl:webapp there... but when I request the webapp site root in my browser, I get: Looking at target/rcl/webapp, I see that there's a WEB-INF/ there, but that's all the sitemap.xmap etc., are all missing. After running rcl:webapp, have you tried to start the created webapp? Yes, I'm sorry, I see where in my original email I left a place to paste in the reply from Cocoon, but then I forget to do it. Here's what I see in the browser: HTTP ERROR: 503 SERVICE_UNAVAILABLE RequestURI=/ Powered by jetty:// There is no need for a global sitemap.xmap anymore. You mount one of your blocks to the root of your webapp (/). No, no... this is core/cocoon-webapp where I have done this. I did it there, in situ, just temporarily while I (hopefully) test some changes in trunk. cocoon-webapp does have global (self-contained root-level) resources (sitemap.xmap, welcome.xml, stylesheets/ etc.). I know how to do it the block way, that's not the issue... I'm just trying to quick-'n'-dirty configure my own local build of cocoon-webapp to use the RCL, and it doesn't appear to be working right — which is probably All My Fault somewhere, and I'm trying to figure out where I went wrong :-). target/rcl/webapp/ should (I presume) end up containing everything that target/webapp does, right? My target/rcl/webapp contains only the WEB-INF, but nothing else. Any ideas? —ml—
Re: RCL difficulties (was Re: Input modules samples broken in trunk)
Mark Lundquist wrote:
[...]
I know how to do it the block way, that's not the issue... I'm just
trying to quick-'n'-dirty configure my own local build of cocoon-webapp
to use the RCL, and it doesn't appear to be working right — which is
probably All My Fault somewhere, and I'm trying to figure out where I
went wrong :-).
target/rcl/webapp/ should (I presume) end up containing everything that
target/webapp does, right? My target/rcl/webapp contains only the
WEB-INF, but nothing else.
Any ideas?
The RCL only works for blocks ATM.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: every new webapp a block?
On Jan 10, 2007, at 10:42 PM, Reinhard Poetz wrote: Maybe we should change the wording to [...] Cocoon web application should be done [...] to make the statement less exclusive. Though, in tutorials we should encourage our users to go down this path. This way they learn how to modularize a Cocoon webapp right from the beginning. Is it just so that new webapps don't have to bring along their own WEB-INF/? In return for that, they just have to provide a META-INF/cocoon/spring/core/whatever-block.xml, right? IIRC META-INF/cocoon/spring/whatever-block.xml, no core. right... brain spaz :-) So, OK... the rationale for the statement is really pedagogically motivated. Fair enough... :-) thx for the explanation... —ml—
Re: RCL difficulties (was Re: Input modules samples broken in trunk)
On Jan 11, 2007, at 7:56 AM, Reinhard Poetz wrote: The RCL only works for blocks ATM. Ah! OK. So I'll just servletize the samples app and then I should be able to see the RCL in action. thx a lot, —ml—
Re: Input modules samples broken in trunk
Reinhard Poetz skrev: Mark Lundquist wrote: On Jan 10, 2007, at 10:15 PM, Reinhard Poetz wrote: try http://cocoon.zones.apache.org/daisy/cdocs-rcl-plugin/g1/1297.html OK, so let me make sure I understand... I want to make changes to sitemap, XLST, XML sources etc. within a block and have those changes take effect immediately in the running Cocoon. IIUC, there are two ways to do this: 1) By using the reloading classloader; 2) By using the Eclipse Jetty Launcher. Is that right? Definitly with 1). Haven't tried 2) myself but it works for Daniel. So yes, you're right. To make resources available directly to a webapp you just need to make sure that the block directory with the resources in is available at the class path as a directory (file://path to block) rather than the block jar. Then the DeployUtil in the cocoon-spring-configurator takes care of the rest. See http://marc.theaimsgroup.com/?l=xml-cocoon-devm=116326232408386w=2 for how it works. I described how to use Eclipse as that is what I have experience with. But if you can ensure that the Maven Jetty plugin gets the blocks as directories rather than jars at its classpath, that should work as well. /Daniel
RAD (was Re: Input modules samples broken in trunk)
On Jan 11, 2007, at 8:35 AM, Daniel Fagerstrom wrote: I described how to use Eclipse as that is what I have experience with. But if you can ensure that the Maven Jetty plugin gets the blocks as directories rather than jars at its classpath, that should work as well. That was going to be my next question... :-) One of my clients has other people who work on Cocoon web sites that I create. They do content updates, and one of them can do some CSS and a few elementary things in XSLT to tweak the site layout/styling. But these are pretty much non-technical peeps; for them Eclipse is a chewing gum [1]. And they don't know how to build these webapps on their own computers and run them locally, that's just beyond them. They work by remotely editing files in place in a development instance of the application running up on a server. Then, one of them I've taught how to do svn commits from dev and then update into the production instance (sometimes it gets botched and I have to go clean up a subversion mess by hand, but 95% of the time this works OK). So to move these apps forward to 2.2, I will need a no-brainer way for them to make live changes on the development instance in a server environment. But I think now that I understand all about what we're discussing here [2], I will probably end up keeping root-level application resources directly in the webapp module instead of servletizing them in a separate block. I think that will take care of most of our issues. [1] - http://www.wrigley.com/wrigley/products/products_eclipse.asp [2] - sorry, no reference for discussion thread every new webapp a block? — I can't find it on marc.theaimsgroup.com for some reason? thx, —ml—
Re: every new webapp a block?
I just added a section to http://cocoon.zones.apache.org/daisy/cdocs/g2/g1/g2/1159.html explaining how to mount myBlock1 to the root context. I figure that's one of the first things a newbie is going to want to understand. I'm not really a newbie, but the first time(s) I read this tutorial I kept thinking yeah, but I don't want to make a block, I want to make my root-level webapp! cheers, —ml—
Re: Importing Cocoon projects into Eclipse
On Jan 11, 2007, at 12:56 AM, Daniel Fagerstrom wrote: File - Import ... - General - Existing projects into workspace - Point on a directory that contains the project, it will be scanned for Eclipse project descriptors. It takes some time for Eclipse to scan all of cocoon-trunk. Choose the projects you want. D'oh, I've always just used this to import a single project, never noticed the scanning business :-o Take a look at properties - Java build path for the project, to see what other projects it depends on and make sure that you import all dependencies. Well, I'm really a little too lazy for that, but if that's what I have to do... :-/. Has anyone tried the Eclipse Maven plugin [1] ? —ml— [1] http://m2eclipse.codehaus.org/
Re: Importing Cocoon projects into Eclipse
On Jan 11, 2007, at 12:56 AM, Daniel Fagerstrom wrote: File - Import ... - General - Existing projects into workspace - Point on a directory that contains the project, it will be scanned for Eclipse project descriptors. It takes some time for Eclipse to scan all of cocoon-trunk. Choose the projects you want. Take a look at properties - Java build path for the project, to see what other projects it depends on and make sure that you import all dependencies. I just imported all the projects in trunk. I get all kinds of errors of this sort: Unbound classpath variable: 'M2_REPO/aopalliance/aopalliance/1.0/aopalliance-1.0.jar' in project cocoon-core —ml—
Re: Importing Cocoon projects into Eclipse
Mark Lundquist napisał(a): On Jan 11, 2007, at 12:56 AM, Daniel Fagerstrom wrote: I just imported all the projects in trunk. I get all kinds of errors of this sort: Unbound classpath variable: 'M2_REPO/aopalliance/aopalliance/1.0/aopalliance-1.0.jar' in project cocoon-core You have to set up variable 'M2_REPO' in Eclipse (in build classpath settings somewhere) to point on the directory where your Maven's repo sit. -- Grzegorz Kossakowski
Re: Importing Cocoon projects into Eclipse
On 11.01.2007 02:28, Mark Lundquist wrote: I ran mvn eclipse:eclipse; now which projects do I need to import, and what's the easiest way to do it? :-) At least the Eclipse setup works as expected if following the description in README.txt in Cocoon trunk's root dir. Jörg
Strange container error
When using a bean defined like this: bean name=org.apache.cocoon.generation.Generator/contractors class=com.mobilebox.smart.generation.ContractorsGenerator scope=prototype property name=contractorService ref=contractorService/ property name=mobileConfigService ref=mobileConfigService/ property name=priceListDefinitionDao ref=priceListDefinitionDao/ /bean I get a NPE while referencing priceListDefinitionDao. Some experiments show that I may also do: property name=priceListDefinitionDaoBlahBlah ref=priceListDefinitionDao/ and spring context configured by cocoon also won't notice. Does anyone have a clue? -- Leszek GawronCTO at MobileBox Ltd.
[jira] Commented: (COCOON-1624) reader caching does not consider mime-type
[ https://issues.apache.org/jira/browse/COCOON-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464049 ] Alfred Nathaniel commented on COCOON-1624: -- ... or simply flush the pipeline cache whenever the sitemap is reloaded. There can be many more sitemap changes which may affect the pipeline output but are too rare/difficult to include in the cache validity calculation. reader caching does not consider mime-type -- Key: COCOON-1624 URL: https://issues.apache.org/jira/browse/COCOON-1624 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Jörg Heinicke Assigned To: Cocoon Developers Team Changing the mime type on a reader in a caching pipeline does not invalidate its former usage with another mime type. Sample: map:match pattern=form1.xul map:read src=forms/form1_template.xul mime-type=text/xml/ /map:match changed to map:match pattern=form1.xul map:read src=forms/form1_template.xul mime-type=application/vnd.mozilla.xul+xml/ /map:match still results in delivery with text/xml. Carsten already saw it at the hackathon when I played around with XUL. Jörg -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1807) Workaround for IE Bug in button
[ https://issues.apache.org/jira/browse/COCOON-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rolf Metternich updated COCOON-1807: Attachment: action-error.txt Workaround for IE Bug in button - Key: COCOON-1807 URL: https://issues.apache.org/jira/browse/COCOON-1807 Project: Cocoon Issue Type: Improvement Components: Blocks: Forms Affects Versions: 2.1.8, 2.1.9, 2.2-dev (Current SVN) Reporter: Rolf Metternich Priority: Minor Attachments: action-error.txt, Action.patch Special workaround IE Bug for button type=button title=row up name=results.0.columns.0.result-column-move-up id=results.0.columns.0.result-column-move-up value=row up onClick=forms_submitForm(this);img src=up.gif border=0/button The IE returns the values of all button in every row, so there are multiple submitWidgets! My Workaround is using the onClick-Event to remember the button name by using the known js-function forms_submitForm(this). In the Action-class I check if the field forms_submit_id is set and use this as SubmitWidget. I'm using this patch since 1 year and it works fine. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1807) Workaround for IE Bug in button
[ https://issues.apache.org/jira/browse/COCOON-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rolf Metternich updated COCOON-1807: Fix Version/s: 2.1.10 Priority: Major (was: Minor) Urgency: Normal Other Info: [Patch available] Affects Version/s: 2.1.10 Workaround for IE Bug in button - Key: COCOON-1807 URL: https://issues.apache.org/jira/browse/COCOON-1807 Project: Cocoon Issue Type: Improvement Components: Blocks: Forms Affects Versions: 2.1.8, 2.1.9, 2.1.10, 2.2-dev (Current SVN) Reporter: Rolf Metternich Fix For: 2.1.10 Attachments: action-error.txt, Action.patch Special workaround IE Bug for button type=button title=row up name=results.0.columns.0.result-column-move-up id=results.0.columns.0.result-column-move-up value=row up onClick=forms_submitForm(this);img src=up.gif border=0/button The IE returns the values of all button in every row, so there are multiple submitWidgets! My Workaround is using the onClick-Event to remember the button name by using the known js-function forms_submitForm(this). In the Action-class I check if the field forms_submit_id is set and use this as SubmitWidget. I'm using this patch since 1 year and it works fine. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
