[EMAIL PROTECTED]: Module cocoon success, but with warnings.
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Module cocoon contains errors. The current state of this module is 'Success'. Full details are available at: http://vmgump.apache.org/gump/public/cocoon/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -ERROR- *** Failed to update from source control. Stale contents *** The following work was performed: http://vmgump.apache.org/gump/public/cocoon/gump_work/update_cocoon.html Work Name: update_cocoon (Type: Update) Work ended in a state of : Failed Elapsed: 45 secs Command Line: svn --quiet update --non-interactive cocoon [Working Directory: /usr/local/gump/public/workspace/cvs] - svn: Failed to add directory 'cocoon/cocoon-ajax/cocoon-ajax-impl/src/main/resources/WEB-INF': object of the same name already exists - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/cocoon/rss.xml - Atom: http://vmgump.apache.org/gump/public/cocoon/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2015012006, vmgump.apache.org:vmgump-public:2015012006 Gump E-mail Identifier (unique within run) #1. -- Apache Gump http://gump.apache.org/ [Instance: vmgump]
[EMAIL PROTECTED]: Module cocoon success, but with warnings.
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Module cocoon contains errors. The current state of this module is 'Success'. Full details are available at: http://vmgump.apache.org/gump/public/cocoon/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -ERROR- *** Failed to update from source control. Stale contents *** The following work was performed: http://vmgump.apache.org/gump/public/cocoon/gump_work/update_cocoon.html Work Name: update_cocoon (Type: Update) Work ended in a state of : Failed Elapsed: 45 secs Command Line: svn --quiet update --non-interactive cocoon [Working Directory: /usr/local/gump/public/workspace/cvs] - svn: Failed to add directory 'cocoon/cocoon-ajax/cocoon-ajax-impl/src/main/resources/WEB-INF': object of the same name already exists - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/cocoon/rss.xml - Atom: http://vmgump.apache.org/gump/public/cocoon/atom.xml == Gump Tracking Only === Produced by Gump version 2.2. Gump Run 2015012006, vmgump.apache.org:vmgump-public:2015012006 Gump E-mail Identifier (unique within run) #1. -- Apache Gump http://gump.apache.org/ [Instance: vmgump]
[SOLVED] How to resolve relative external sources?
Thank you for your kind replies. I think I found one more way, that does it for me. I simply get the tomcat path by System.getProperty(catalina.home) and then attach /webapps to that! Stefan | -Ursprüngliche Nachricht- | Von: Ross Gardler [mailto:[EMAIL PROTECTED] | Gesendet: Samstag, 14. Januar 2006 20:18 | An: dev@cocoon.apache.org | Betreff: Re: How to resolve relative external sources? | | Geert Josten wrote: | You could use input-modules to convert a relative path to an absolute | one. It should be possible with the realpath input module for instance. | | | The locationmap in Forrest is an input module that can be used to do | this, and much more. | | Docs at http://forrest.apache.org/docs_0_80/locationmap.html | | Code at | http://svn.apache.org/repos/asf/forrest/trunk/main/java/org/apache/forrest | /locationmap/ | | Ross
Re: blocks and SVN externals
Joerg Heinicke wrote: On 14.01.2006 19:12, Carsten Ziegeler wrote: I wasn't able to update my check-out either directly, but deleting src\blocks\ajax followed by an update did work for me. However I did a clean check out of the branch and that works pretty well for me. A clean checkout worked for me too, thanks for the hint. Yeah, looks like subversion sometimes get lost when some regular directories have been changed to/from svn:external. Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: M10N
Ben Pope skrev: Hi, I am currently unable to get the 2.2 trunk working with maven, as descibed in the docs. It might just be that it's broken what with all the refactoring, I dunno. I've been following this page: http://cocoon.zones.apache.org/daisy/documentation/g2/756.html When Building Cocoon Block Deployer I get a compile error: java.lang.IllegalStateException: basedir src\main\resources\xsd does not exist I get the same error, the directory is there but the castor plugin doesn't find it. Hopefully Reinhard can give a better answer on what is going on. I can compile successfully if I remove both modulecocoon-deployer/module modulecocoon-plugins/module from the top-level pom.xml OK, that seems to work and I can successfully run jetty6. I then try to create my own block and webapp using the instructions here: http://cocoon.zones.apache.org/daisy/documentation/g2/796.html and here: http://cocoon.zones.apache.org/daisy/documentation/g2/797.html These documents descreibe what we want to achieve rather than what we have. So you have either to wait, or get involved ;) But both fail with a file that cannot be downloaded: Downloading: http://repo1.maven.org/maven2/org/apache/cocoon/block/1.0/block-1.0.jar [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) and Downloading: http://repo1.maven.org/maven2/org/apache/cocoon/webapp/1.0/webapp-1.0.jar [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) Are these things known to be broken? Whats the current workaround? If the current workaround is to wait 'til it works, then thats ok :P You are right about the current workaround. We are making good progress, so the waiting will hopefully not be to long. Thanks for being eager to use the new stuff. /Daniel
Re: M10N
On 15/01/06, Daniel Fagerstrom [EMAIL PROTECTED] wrote: Ben Pope skrev: When Building Cocoon Block Deployer I get a compile error: java.lang.IllegalStateException: basedir src\main\resources\xsd does not exist I get the same error, the directory is there but the castor plugin doesn't find it. Hopefully Reinhard can give a better answer on what is going on. At least I'm not going mad. I then try to create my own block and webapp using the instructions here: http://cocoon.zones.apache.org/daisy/documentation/g2/796.html and here: http://cocoon.zones.apache.org/daisy/documentation/g2/797.html These documents descreibe what we want to achieve rather than what we have. So you have either to wait, or get involved ;) OK, understood. It might take me a while to catch up, but if there's anything I can do to help I'll try. I'll have a look; I'll probably be more useful in the easy, but time consuming, rather than complicated stuff ;) If the current workaround is to wait 'til it works, then thats ok :P You are right about the current workaround. We are making good progress, so the waiting will hopefully not be to long. I can see the good progress and it's very interesting. Thanks for being eager to use the new stuff. ...I just wish I understood the implementation more so that I could contribute. Thanks for your response. Ben Pope -- I'm not just a number. To many, I'm known as a string...
Re: M10N
Ben Pope skrev: On 15/01/06, Daniel Fagerstrom [EMAIL PROTECTED] wrote: Ben Pope skrev: ... I then try to create my own block and webapp using the instructions here: http://cocoon.zones.apache.org/daisy/documentation/g2/796.html and here: http://cocoon.zones.apache.org/daisy/documentation/g2/797.html These documents descreibe what we want to achieve rather than what we have. So you have either to wait, or get involved ;) OK, understood. It might take me a while to catch up, but if there's anything I can do to help I'll try. I'll have a look; I'll probably be more useful in the easy, but time consuming, rather than complicated stuff ;) All kinds of contributions are welcome. It can be testing (as you did now), commenting and discussing the proposals, and code. It is better to start with easy stuff, so that you get going and get feedback. And the block creation and deployment are probably a good area to start to work in as they are in dependent from the rest of Cocoon and on a early stage of devlopment, so you can work on them without needing to understand the Cocoon internals. If the current workaround is to wait 'til it works, then thats ok :P You are right about the current workaround. We are making good progress, so the waiting will hopefully not be to long. I can see the good progress and it's very interesting. Thanks for being eager to use the new stuff. ...I just wish I understood the implementation more so that I could contribute. Just ask at the list about things that are unclear. /Daniel
[EMAIL PROTECTED]: Project cocoon (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon has an issue affecting its community integration. This issue affects 58 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon : Java XML Framework - cocoon-block-ajax : Ajax - Utilities and resources for Ajax applications. - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-captcha : Utilites to generate simple CAPTCHAs - cocoon-block-chaperon : Java XML Framework - cocoon-block-core-samples-additional : Additional core samples. - cocoon-block-core-samples-main : Main core samples. - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jcr : A jcr: protocol for Cocoon - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-mail : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-ojb : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-portal-sample : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-querybean : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-spring-app : A demo for Spring and Cocoon - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-template : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-validation : In-pipeline validation of documents - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - forrest : Apache Forrest is an XML standards-oriented documentation fr... - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... - lenya : Content Management System Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon] -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: [cocoon-testcase] -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: [cocoon-deprecated] -INFO- Made directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-15012006/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-15012006/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-15012006/test/output] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html Work Name: build_cocoon_cocoon (Type: Build) Work ended in a state of : Failed Elapsed: 7 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dlogkit.jar=/usr/local/gump/public/workspace/excalibur/containerkit/logkit/target/excalibur-logkit-15012006.jar
[EMAIL PROTECTED]: Project cocoon (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon has an issue affecting its community integration. This issue affects 58 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon : Java XML Framework - cocoon-block-ajax : Ajax - Utilities and resources for Ajax applications. - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-captcha : Utilites to generate simple CAPTCHAs - cocoon-block-chaperon : Java XML Framework - cocoon-block-core-samples-additional : Additional core samples. - cocoon-block-core-samples-main : Main core samples. - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jcr : A jcr: protocol for Cocoon - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-mail : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-ojb : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-portal-sample : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-querybean : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-spring-app : A demo for Spring and Cocoon - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-template : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-validation : In-pipeline validation of documents - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - forrest : Apache Forrest is an XML standards-oriented documentation fr... - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... - lenya : Content Management System Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon] -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: [cocoon-testcase] -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: [cocoon-deprecated] -INFO- Made directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-15012006/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-15012006/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-15012006/test/output] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html Work Name: build_cocoon_cocoon (Type: Build) Work ended in a state of : Failed Elapsed: 7 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dlogkit.jar=/usr/local/gump/public/workspace/excalibur/containerkit/logkit/target/excalibur-logkit-15012006.jar
Re: svn commit: r368690 - in /cocoon/branches/BRANCH_2_1_X: src/blocks/xmldb/java/org/apache/cocoon/transformation/XMLDBTransforme r.java status.xml
* Ralph Goers: It is good practice to apply patches to both branches just so it doesn't get forgotten. * Antonio Gallardo: Yes, please keep the both version in sync. If not, then this problem will show up again in 2.2. * Upayavira: No, but if you don't do it now, likely it will be forgotten. No problem, I will do it tomorrow ;-) I won't forget, it's on my TODO list. Thanks for reminding. -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: Caching question
On 14.01.2006 20:25, Ard Schrijvers wrote: But I don't like the idea about cron jobs doing checks...you can imagine. Other then this, I would not know how to accomplish it. For Jakarta Commons JCI Torsten wrote a FilesystemAlterationMonitor, which allows the recompiling of Java source files being event-based. This should already be integrated into Cocoon 2.2, but Torsten can probably tell more about this. Most changes of sites we build come from changes in a repository, where a jms message is send to invalidate depending dasls and repository files. That makes it less harder then for filesystem. It's not integrated with Cocoon caching though. Jörg
Getting response in any particular format required by client
Hi All, I have one issue i.e. while developing a dynamic web page i want the response in anyparticular format required by user, it can be in PDF, TXT, DOC, HTML, XML or WML or any other format whichsoever user chooses, so according to his/her choice the response should be dynamically converted in that particular format and should be visible to user. Can Cocoon and XSP + XSL help in this. I have written some code but not fully successful with that. Any help would be highly appreciated Thanx, Sumit Sanwal PCSMumbai, India +91-9819146942
Re: blocks and SVN externals
On Sun, 15 Jan 2006, Joerg Heinicke [EMAIL PROTECTED] wrote: On 15.01.2006 10:39, Sylvain Wallez wrote: Yeah, looks like subversion sometimes get lost when some regular directories have been changed to/from svn:external. The same problem seems to be on the gump server: http://vmgump.apache.org/gump/public/cocoon/index.html. Has anybody access to it? I've removed the whole working copy of cocoon, we'll see with the next run. Stefan
Re: blocks and SVN externals
On 15.01.2006 16:54, Stefan Bodewig wrote: Yeah, looks like subversion sometimes get lost when some regular directories have been changed to/from svn:external. The same problem seems to be on the gump server: http://vmgump.apache.org/gump/public/cocoon/index.html. Has anybody access to it? I've removed the whole working copy of cocoon, we'll see with the next run. Thanks. It seems Cocoon has already been built [1], but failed. So it's now about to fix our gump descriptor to get Cocoon also built based on Maven. Jörg [1] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113733054407477w=4
Re: Jetty and Eclipse
Jorg Heymans wrote: Anyhow, there seems to be something not quite right yet with our eclipse setup. If you run eclipse:eclipse from the top level pom in whiteboard/cocoon-flat-layout, you'll see that the plugin generates eclipse project dependencies between the different modules (very useful!) . For some reason, it's not doing this in trunk. I'm currently investigating this ... The trick here is to do $mvn clean install eclipse:clean eclipse:eclipse before importing the project. The plugin seems to need the projects to be *installed* before it will generate eclipse project references from a reactor build. Now i'm not sure if this really speeds up the development cycle , but having our modules depend on each other as eclipse projects is another step in the right direction I hope. Regards Jorg
Re: Getting response in any particular format required by client
Sumit wrote: Hi All, I have one issue i.e. while developing a dynamic web page i want the response in any particular format required by user, it can be in PDF, TXT, DOC, HTML, XML or WML or any other format whichsoever user chooses, so according to his/her choice the response should be dynamically converted in that particular format and should be visible to user. Can Cocoon and XSP + XSL help in this. I have written some code but not fully successful with that . You should ask this question on the user list. It is a better place for such a question. And the short answer is yes, Cocoon can help with that. Regards, Upayavira
Re: Getting response in any particular format required by client
Upayavira wrote: Sumit wrote: Hi All, I have one issue i.e. while developing a dynamic web page i want the response in any particular format required by user, it can be in PDF, TXT, DOC, HTML, ... You should ask this question on the user list. It is a better place for such a question. And the short answer is yes, Cocoon can help with that. The slightly longer answer is Apache Forrest [1] is a Cocoon app that already does it. See you on the Cocoon and/or Forrest user list ;-) Ross [1] http://forrest.apache.org
Re: Jetty and Eclipse
Jorg Heymans skrev: Jorg Heymans wrote: Anyhow, there seems to be something not quite right yet with our eclipse setup. If you run eclipse:eclipse from the top level pom in whiteboard/cocoon-flat-layout, you'll see that the plugin generates eclipse project dependencies between the different modules (very useful!) . For some reason, it's not doing this in trunk. I'm currently investigating this ... The trick here is to do $mvn clean install eclipse:clean eclipse:eclipse before importing the project. The plugin seems to need the projects to be *installed* before it will generate eclipse project references from a reactor build. I tried it and it worked. Now i'm not sure if this really speeds up the development cycle , but having our modules depend on each other as eclipse projects is another step in the right direction I hope. Absolutely! When you work at several blocks at once it is important. And it also give you connection to the latest source, when you get to e.g. core during debuging. /Daniel
Re: Jetty and Eclipse
Daniel Fagerstrom wrote: Absolutely! When you work at several blocks at once it is important. And it also give you connection to the latest source, when you get to e.g. core during debuging. Cool! I've updated the docs [1] to reflect this. Jorg [1] http://cocoon.zones.apache.org/daisy/documentation/g2/756.html
[M10N] please add yourself as developer in /trunk/pom.xml
subject says most of it :) If you're unsure about what to provide for certain elements have a look at the maven docs [1] or as an example the maven2 root pom [2]. The idea is that this information is used in the (auto-generated) maven site documentation for all blocks by default, meaning that we are all listed as developer for all blocks. This element can then be overriden at the module level if necessary - for example if we find that certain modules are really only maintained/developed by a few developers then we could reflect this in the modules' pom. Thanks Jorg [1] http://maven.apache.org/maven-model/maven.html#class_developer [2] http://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x/pom.xml
Re: Jetty and Eclipse
On 1/15/06, Daniel Fagerstrom [EMAIL PROTECTED] wrote: Jorg Heymans skrev: Jorg Heymans wrote: Anyhow, there seems to be something not quite right yet with our eclipse setup. If you run eclipse:eclipse from the top level pom in whiteboard/cocoon-flat-layout, you'll see that the plugin generates eclipse project dependencies between the different modules (very useful!) . For some reason, it's not doing this in trunk. I'm currently investigating this ... The trick here is to do $mvn clean install eclipse:clean eclipse:eclipse before importing the project. The plugin seems to need the projects to be *installed* before it will generate eclipse project references from a reactor build. I tried it and it worked. Guys, sorry for the wasted electrons but I just feel the compelling need to thank you so much for this most promising work. You made me open my eyes on how Maven 2 could help us getting a solid build system which is a huge first step towards semplification: I'm sold on your approach. I hope this short note from the skeptical camp might cheer you up and let you know how welcome your efforts are! Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [VOTE] Stable CForms
Hi, On 13 Jan 2006, at 16:32, Vadim Gritsenko wrote: We need official vote to mark CForms stable, so let's start it. Please vote to mark CForms as stable, to be included in imminent 2.1.9 release: [ ] +1, Let's do it! [ ] 0, What is CForms? [ ] -1, It's not stable, because... +1 Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
