[continuum] BUILD SUCCESSFUL: Forms Block Implementation
Online report : http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/46/buildId/1249 Build statistics: State: Ok Previous State: Failed Started at: Sat, 27 May 2006 03:17:56 + Finished at: Sat, 27 May 2006 03:19:55 + Total time: 1m 59s Build Trigger: Schedule Exit code: 0 Building machine hostname: cocoon.zones.apache.org Operating system : SunOS(unknown) Java version : 1.4.2_06(Sun Microsystems Inc.) Changes simoneg Dependency to sv.apache.org xreporter-expression-r672, will move it back to xreporter on ibiblio when xreporter will release a new version /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/pom.xml Output: [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'source'. [INFO] [INFO] Building Forms Block Implementation [INFO]task-segment: [clean, source:jar, deploy] [INFO] [INFO] [clean:clean] [INFO] Deleting directory /home/maven/continuum-1.0.3/apps/continuum/working-directory/46/target [INFO] [source:jar] [INFO] Building jar: /home/maven/continuum-1.0.3/apps/continuum/working-directory/46/target/cocoon-forms-impl-1.0.0-SNAPSHOT-sources.jar [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] snapshot org.apache.cocoon:cocoon-ajax-impl:1.0.0-SNAPSHOT: checking for updates from central [INFO] snapshot org.apache.cocoon:cocoon-ajax-impl:1.0.0-SNAPSHOT: checking for updates from apache.snapshot [INFO] snapshot org.apache.cocoon:cocoon-ajax-impl:1.0.0-SNAPSHOT: checking for updates from apache-cvs [INFO] snapshot org.apache.cocoon:cocoon-ajax-impl:1.0.0-SNAPSHOT: checking for updates from apache.snapshots [INFO] snapshot org.apache.cocoon:cocoon-ajax:1-SNAPSHOT: checking for updates from central [INFO] snapshot org.apache.cocoon:cocoon-ajax:1-SNAPSHOT: checking for updates from apache.snapshot [INFO] snapshot org.apache.cocoon:cocoon-ajax:1-SNAPSHOT: checking for updates from apache-cvs [INFO] snapshot org.apache.cocoon:cocoon-ajax:1-SNAPSHOT: checking for updates from apache.snapshots [INFO] snapshot org.apache.cocoon:cocoon-core:2.2.0-SNAPSHOT: checking for updates from central [INFO] snapshot org.apache.cocoon:cocoon-core:2.2.0-SNAPSHOT: checking for updates from apache.snapshot [INFO] snapshot org.apache.cocoon:cocoon-core:2.2.0-SNAPSHOT: checking for updates from apache-cvs [INFO] snapshot org.apache.cocoon:cocoon-core:2.2.0-SNAPSHOT: checking for updates from apache.snapshots [INFO] snapshot org.apache.cocoon:cocoon-core-modules:1-SNAPSHOT: checking for updates from central [INFO] snapshot org.apache.cocoon:cocoon-core-modules:1-SNAPSHOT: checking for updates from apache.snapshot [INFO] snapshot org.apache.cocoon:cocoon-core-modules:1-SNAPSHOT: checking for updates from apache-cvs [INFO] snapshot org.apache.cocoon:cocoon-core-modules:1-SNAPSHOT: checking for updates from apache.snapshots [INFO] snapshot org.apache.cocoon:cocoon-bootstrap:1.0.0-SNAPSHOT: checking for updates from central [INFO] snapshot org.apache.cocoon:cocoon-bootstrap:1.0.0-SNAPSHOT: checking for updates from apache.snapshot [INFO] snapshot org.apache.cocoon:cocoon-bootstrap:1.0.0-SNAPSHOT: checking for updates from apache-cvs [INFO] snapshot org.apache.cocoon:cocoon-bootstrap:1.0.0-SNAPSHOT: checking for updates from apache.snapshots [INFO] snapshot org.apache.cocoon:cocoon-licenses:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot org.apache.cocoon:cocoon-licenses:1.0-SNAPSHOT: checking for updates from apache.snapshot [INFO] snapshot org.apache.cocoon:cocoon-licenses:1.0-SNAPSHOT: checking for updates from apache-cvs [INFO] snapshot org.apache.cocoon:cocoon-licenses:1.0-SNAPSHOT: checking for updates from apache.snapshots Downloading: http://mirrors.dotsrc.org/maven2/xreporter/xreporter-expression/r672/xreporter-expression-r672.pom [WARNING] Unable to get resource from repository central (http://ibiblio.org/maven2) Downloading: http://svn.apache.org/maven-snapshot-repository/xreporter/xreporter-expression/r672/xreporter-expression-r672.pom [WARNING] Unable to get resource from repository apache.snapshot (http://svn.apache.org/maven-snapshot-repository) Downloading: http://svn.apache.org/repository/xreporter/poms/xreporter-expression-r672.pom 213b downloaded Downloading: http://mirrors.dotsrc.org/maven2/xreporter/xreporter-expression/r672/xreporter-expression-r672.jar [WARNING] Unable to get resource from repository central (http://ibiblio.org/maven2) Downloading: http://svn.apache.org/maven-snapshot-repository/xreporter/xreporter-expression/r672/xreporter-expression-r
[jira] Created: (COCOON-1855) Can't load from fragment URLs
Can't load from fragment URLs - Key: COCOON-1855 URL: http://issues.apache.org/jira/browse/COCOON-1855 Project: Cocoon Type: Improvement Components: * Cocoon Core Versions: 2.1.9 Reporter: Laurens Holst Hi, When I try to load a document fragment with a file generator, e.g. toc.xml#dev, Cocoon throws a loading error (java.io.FileNotFoundException: C:\Development\Projects\BBCocoon\toc.xml#home), while it would be really nice if it would instead retrieve the fragment of that document which the fragment identifier indicates. This is how XSLT 1.0 behaves, quote: "If the URI reference does not contain a fragment identifier, then a node-set containing just the root node of the document is returned. If the URI reference does contain a fragment identifier, the function returns a node-set containing the nodes in the tree identified by the fragment identifier of the URI reference." This would have been convenient; now as a workaround I have to either split up the toc.xml file or pass the ID along as a parameter to the XSLT, which can then go to the desired fragment. ~Grauw p.s. I'm having xml:id attributes for IDs, and using Saxon as XSLT processor. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1854) Browser selector should have Opera before MSIE
Browser selector should have Opera before MSIE -- Key: COCOON-1854 URL: http://issues.apache.org/jira/browse/COCOON-1854 Project: Cocoon Type: Bug Components: - Components: Sitemap Versions: 2.1.9 Reporter: Laurens Holst Priority: Minor Hi, In current versions, Opera identifies itself in the UA string as MSIE by default. Nevertheless it can be identified because the string also contains 'Opera'. This however only works if browser checks check for Opera *before* they check for MSIE. To properly detect Opera the browser selector should thus be modified, from: into: i.e. Opera is moved five notches up to be tested before MSIE is. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [continuum] BUILD FAILURE: Forms Block Implementation
Hi Jorg, nope, my own server. BTW, i uploaded and signed the jar, and created and signed the new pom. Anyway the folder was called "xreporter-moved-to-ibiblio", i renamed it to xreporter again. Don't think this was necessary, but it gave me strange errors. As soon as a new release of xreporter is available and uploaded to ibiblio we can rename it again. Simone Jorg Heymans wrote: >Antonio Gallardo wrote: > > > >>>don't know if this mail will get to the list, since apache SMTPd decided >>>today that my mails are smap :( >>> >>> >>> > >i flagged this on asfInfra earlier on and apparently it has been fixed. >Were you posting from gmail by any chance ? > > >Jorg > > > -- Simone Gianni
Re: [continuum] BUILD FAILURE: Forms Block Implementation
Jorg Heymans escribió: Antonio Gallardo wrote: don't know if this mail will get to the list, since apache SMTPd decided today that my mails are smap :( i flagged this on asfInfra earlier on and apparently it has been fixed. Were you posting from gmail by any chance ? No, actually never I posted from gmail. In infra I read about this issue, the problem seems to be related to the points assigned to the spamcop black list rule (RCVD_IN_BL_SPAMCOP_NET) for our spamassassin installation. AFAIK, it should be fixed now. Simone had problems maybe due the same, but he is not posting from gmail, Simone posts from thebug.it Best Regards, Antonio Gallardo
Re: [continuum] BUILD FAILURE: Forms Block Implementation
Antonio Gallardo wrote: >> don't know if this mail will get to the list, since apache SMTPd decided >> today that my mails are smap :( >> i flagged this on asfInfra earlier on and apparently it has been fixed. Were you posting from gmail by any chance ? Jorg
Re: [continuum] BUILD FAILURE: Forms Block Implementation
Simone Gianni escribió: Hi all, don't know if this mail will get to the list, since apache SMTPd decided today that my mails are smap :( Anyway, i tried to find informations on how to put that jar anywhere to have it downloaded by maven, but found nothing. If you have a good pointer to some documentation I'll try to set it up ASAP. Hi Simone, It sounds really great! [1] Best Regards, Antonio Gallardo [1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113131563119981&w=2
Re: [continuum] BUILD FAILURE: Forms Block Implementation
Simone Gianni wrote: > Anyway, i tried to find informations on how to put that jar anywhere to > have it downloaded by maven, but found nothing. If you have a good > pointer to some documentation I'll try to set it up ASAP. > http://cocoon.zones.apache.org/daisy/documentation/g1/756.html - at the bottom of the page. I just updated the docs - thanks for having a look at this. It's not hard to do at all, but if you find the docs somehow misleading or wrong in any way let me know and i'll adjust them. Thanks Jorg
Re: Calculated fields
Hi Antonio, thanks a lot :) Just a few notes : - What's the locale of cocoon.zones.apache.org ? Field formatting currency displays a strange symbol - Please note that VAT calculation is somewhat floppy due to floating point division in xreporter expressions, which is still an open issue (http://issues.cocoondev.org/browse/XRP-115 ) but will be fixed asap. Simone -- Simone Gianni
Re: [continuum] BUILD FAILURE: Forms Block Implementation
Hi all, don't know if this mail will get to the list, since apache SMTPd decided today that my mails are smap :( Anyway, i tried to find informations on how to put that jar anywhere to have it downloaded by maven, but found nothing. If you have a good pointer to some documentation I'll try to set it up ASAP. Simone Antonio Gallardo wrote: > Jorg Heymans escribió: > >> Just FYI (and part of the ongoing maven education for everyone): this is >> currently failing because we upgraded to a new jar of the xreporter >> xpression library and that jar is not available on a maven mirror >> anywhere. >> >> I've requested a new release jar from outerthough, we should have it on >> maven central within the next few days. >> > > Thanks. In the mean time, would you place it in our cvs.apache.org > maven temporaly repo? > > Best Regards, > > Antonio Gallardo > -- Simone Gianni
Re: [continuum] BUILD FAILURE: Forms Block Implementation
Antonio Gallardo wrote: > Thanks. In the mean time, would you place it in our cvs.apache.org maven > temporaly repo? > I explicitly chose not to hoping that people would take an interest in this ;) Don't worry though, if it's not done by someone else tomorrow i'll see to it that it gets done. cheers, Jorg
GetTogether
It looks like ApacheCon US is going to be Oct 9-13 in Austin, TX. Given that the GetTogether is normally around this same time frame I'm afraid it will be virtually impossible for me to attend both. While it wasn't clear in the email, it appears to me that ApacheCon is a little different than what it was in San Diego where the tutorials were Saturday and Sunday. I'm just wondering if it would be possible to overlap the two and do the GetTogether in conjunction with the training days of ApacheCon. I know this is not our usual tradition and would probably increase the cost for many of you, but it also might increase U.S. participation. Thoughts? Ralph
Re: [continuum] BUILD FAILURE: Forms Block Implementation
Jorg Heymans escribió: Just FYI (and part of the ongoing maven education for everyone): this is currently failing because we upgraded to a new jar of the xreporter xpression library and that jar is not available on a maven mirror anywhere. I've requested a new release jar from outerthough, we should have it on maven central within the next few days. Thanks. In the mean time, would you place it in our cvs.apache.org maven temporaly repo? Best Regards, Antonio Gallardo
Re: [continuum] BUILD FAILURE: Forms Block Implementation
Just FYI (and part of the ongoing maven education for everyone): this is currently failing because we upgraded to a new jar of the xreporter xpression library and that jar is not available on a maven mirror anywhere. I've requested a new release jar from outerthough, we should have it on maven central within the next few days. Thanks Jorg [EMAIL PROTECTED] wrote: > Online report : > http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/46/buildId/1243 > Build statistics: > State: Failed > Previous State: Ok > Started at: Fri, 26 May 2006 03:11:01 + > Finished at: Fri, 26 May 2006 03:11:42 + > Total time: 41s > Build Trigger: Schedule > Exit code: 1 > Building machine hostname: cocoon.zones.apache.org > Operating system : SunOS(unknown) > Java version : 1.4.2_06(Sun Microsystems Inc.) > > Changes > simoneg Calculated fields > > /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/expression/DefaultExpressionManager.java > > /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/expression/ExpressionManager.java > > /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/expression/SumFunction.java > > /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/formmodel/CalculatedField.java > > /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/formmodel/CalculatedFieldAlgorithm.java > > /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/formmodel/CalculatedFieldAlgorithmBuilder.java > > /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/formmodel/CalculatedFieldDefinition.java > > /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/formmodel/CalculatedFieldDefinitionBuilder.java > > /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/formmodel/ExpressionContextImpl.java > > /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/formmodel/algorithms > > /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/formmodel/algorithms/AbstractBaseAlgorithm.java > > /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/formmodel/algorithms/AbstractBaseAlgorithmBuilder.java > > /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/formmodel/algorithms/JavaAlgorithmBuilder.java > > /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/formmodel/algorithms/JavaScript.java > > /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/formmodel/algorithms/JavaScriptBuilder.java > > /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/formmodel/algorithms/RepeatedFormula.java > > /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/formmodel/algorithms/RepeatedFormulaBuilder.java > > /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/formmodel/algorithms/SimpleFormula.java > > /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/formmodel/algorithms/SimpleFormulaBuilder.java > > /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/util/WidgetFinder.java > > > Output: > > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'source'. > [INFO] > > [INFO] Building Forms Block Implementation > [INFO]task-segment: [clean, source:jar, deploy] > [INFO] > > [INFO] [clean:clean] > [INFO] Deleting directory > /home/maven/continuum-1.0.3/apps/continuum/working-directory/46/target > [INFO] [source:jar] > [INFO] Building jar: > /home/maven/continuum-1.0.3/apps/continuum/working-directory/46/target/cocoon-forms-impl-1.0.0-SNAPSHOT-sources.jar > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] snapshot org.apache.cocoon:cocoon-ajax-impl:1.0.0-SNAPSHOT: checking > for updates from central > [INFO] snapshot org.apache.cocoon:cocoon-ajax-impl:1.0.0-SNAPSHOT: checking
Re: Template block in ibiblio maven repository
It would be nice to put this on the wiki. Better yet, why not also check the plugin into Cocoon in BRANCH_2_1_X? Giacomo Pati wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 24 May 2006, Gavin Carothers wrote: Date: Wed, 24 May 2006 10:49:33 -0400 From: Gavin Carothers <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: Template block in ibiblio maven repository I'm sure I'm not the only one who would love to see what a maven build for 2.1.X looks like. If you have the time any chance of a either a copy of the pom or a short article on how this was done? I know the 2.2 tree is built around maven and is fully mavenized but even a half mavenized solution for 2.1.X would be a great solution for those of us who would like to use maven with cocoon but need the stability of the 2.1.X branch in order to deploy applications. For those interested in getting a quick starter with building Cocoon 2.1.X apps with Maven 1 we do have a maven plugin for it (Credits: developed together with peoples at Luminas, Jeremy Quinn and Andrew Savory). It comes with no documentation at all only the code and comments in there which should give you a clue on how to setup an cocoon app Maven 1 project. Extend your maven.repo.remote property with http://project.otego.com/maven and do a maven plugin:download -DgroupId=maven \ -DartifactId=maven-cocoon-plugin \ -Dversion=1.0.13 Afterwards you'll be able to browse the plugin under $HOME/.maven/cache/maven-cocoon-plugin-1.0.13/. Especially have a look at plugin.jelly (or do a 'maven cocoon:usage') as well as plugin.properties. The plugin allows you to create Cocoon apps and build it completely with Maven 1, include customizing a somewhere (property maven.cocoon.home has to point to it) locally installed Cocoon distribution by use of Maven 1 project.properties. It also uses the mount-table.xml file to mount the app for RAD. HTH Giacomo Cheers, Gavin On Apr 29, 2006, at 11:50 PM, Jason Johnston wrote: I'm converting one of my projects to use Maven for its build process. I've set it up to pull down the needed Cocoon JARs from the ibiblio repository at http://www.ibiblio.org/maven2/cocoon/*. It's working great, except I noticed that the template block included in 2.1.9 is not available in that repository. Is that something someone on this list can add to ibiblio? Thanks much --Jason - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEdrv1LNdJvZjjVZARAuM5AJ92KYnJKCzfzJlwGMyIdfJFVAaqswCgrIY9 X8oA9u6cOj86qcBjXSjP+3w= =o6Xt -END PGP SIGNATURE-
Re: [2.2] Configuration
OK. I've tried to follow a fairly simple convention for naming the properties. If you look at the ones I've defined it should jump out at you. As there may be variations in the properties in 2.2 I think we should try to standardize on the convention. Also, once generators, etc. are converted to the ThreadSafe model a lot of the pool sizes will go away. By the way, are pipelines still pooled in trunk or can they (or should they) use a factory pattern instead? Ralph Carsten Ziegeler wrote: Ralph Goers wrote: Running mode is not. I brought back the property stuff to 2.1, although I'm not sure it is exactly the same as in 2.2. I had to implement it in a different place as the core has changed. Also, there are a lot of pre-defined properties in 2.1. I don't know if Carsten has done that in 2.2 and if he has then the variable names probably aren't the same. Currently there are no pre-defined properties in 2.2; I think we should try to use the same ones as in 2.1.x and introduce them in trunk now. Carsten
Re: Automatic releases
On Thursday 25 May 2006 04:06, Reinhard Poetz wrote: > But basically you're right that we have to clarify the situation in > general. How shall we proceed to get an answer to the question of > "unofficial" artifact releases? Is the [EMAIL PROTECTED] in the position to > decide > such things itself our do we have to discuss this issue with [EMAIL PROTECTED] > WDOT? "Automatic releases" are not a possibility, for two main reasons; 1. Resources ; Someone pointed out how many artifacts would be created (and in fact Maven will generate a bunch more, such as .pom, .sha1, .md5, .pom.md5, .pom.sha1. Someone else suggested that these would only exist until the next release. That is also not an option. Maven relies on the fact that any build will work 'forever', as old artifacts does not disappear. 2. Legal ; ALL releases from ASF MUST be under the oversight of the responsible PMC. That means active insight and control of what is put into the release, and vouching legally that this is a non-malicious artifact suitable for consumption under a set of constraints. "Automatic releases" bypasses such legal responsibility, and will be found unacceptable by the Board and legal counsel. The obvious solution to the "problem" is smaller components with independent release cycles, but we know that since *years*... Cheers Niclas
Re: Automatic releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 24 May 2006, Reinhard Poetz wrote: Date: Wed, 24 May 2006 18:46:29 +0200 From: Reinhard Poetz <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Automatic releases Is there any possibility to provide automatic *unofficial* releases of our artifacts? I'm asking because for me (and I think for others too) it's an important requirement that only non-SNAPSHOT artifacts are used in my POMs. That's the only way to guarantee that a POM working today will still work tommorrow or in two years. What I'm thinking of is using Continiuum to automatically release our artifacts once every one or two weeks. Any chance to get this done or in other words, does M2 support this? The release plugin is probably what you are looking for. It automatically updates the pom.xml to a releasable version string (no SNAPSHOT suffix), produces a tagged version in SVN and sets the version string of the pom to the next dvelopment version (scm connection must be setup correctly in the pom). The 'problem' I've faced so far is that the plugin won't make a release if your pom depends on SNAPSHOT versions (which obviously is a good ting). Why do I call it a 'problem'? I've alreday migrated some 2..1x apps to 2.2 but I cannot release them as they depend on cocoon SNAPSHOT releases ;-) - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEdr/DLNdJvZjjVZARAiGPAKCOBNiN19TGnxUcL55uxT0oFwu1CQCgh5Yr FuMZSjx9zlQs5t5u/2D2Gos= =rSrS -END PGP SIGNATURE-
Re: Template block in ibiblio maven repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 24 May 2006, Gavin Carothers wrote: Date: Wed, 24 May 2006 10:49:33 -0400 From: Gavin Carothers <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: Template block in ibiblio maven repository I'm sure I'm not the only one who would love to see what a maven build for 2.1.X looks like. If you have the time any chance of a either a copy of the pom or a short article on how this was done? I know the 2.2 tree is built around maven and is fully mavenized but even a half mavenized solution for 2.1.X would be a great solution for those of us who would like to use maven with cocoon but need the stability of the 2.1.X branch in order to deploy applications. For those interested in getting a quick starter with building Cocoon 2.1.X apps with Maven 1 we do have a maven plugin for it (Credits: developed together with peoples at Luminas, Jeremy Quinn and Andrew Savory). It comes with no documentation at all only the code and comments in there which should give you a clue on how to setup an cocoon app Maven 1 project. Extend your maven.repo.remote property with http://project.otego.com/maven and do a maven plugin:download -DgroupId=maven \ -DartifactId=maven-cocoon-plugin \ -Dversion=1.0.13 Afterwards you'll be able to browse the plugin under $HOME/.maven/cache/maven-cocoon-plugin-1.0.13/. Especially have a look at plugin.jelly (or do a 'maven cocoon:usage') as well as plugin.properties. The plugin allows you to create Cocoon apps and build it completely with Maven 1, include customizing a somewhere (property maven.cocoon.home has to point to it) locally installed Cocoon distribution by use of Maven 1 project.properties. It also uses the mount-table.xml file to mount the app for RAD. HTH Giacomo Cheers, Gavin On Apr 29, 2006, at 11:50 PM, Jason Johnston wrote: I'm converting one of my projects to use Maven for its build process. I've set it up to pull down the needed Cocoon JARs from the ibiblio repository at http://www.ibiblio.org/maven2/cocoon/*. It's working great, except I noticed that the template block included in 2.1.9 is not available in that repository. Is that something someone on this list can add to ibiblio? Thanks much --Jason - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEdrv1LNdJvZjjVZARAuM5AJ92KYnJKCzfzJlwGMyIdfJFVAaqswCgrIY9 X8oA9u6cOj86qcBjXSjP+3w= =o6Xt -END PGP SIGNATURE-
Re: [2.2] Configuration
Ralph Goers wrote: > Running mode is not. I brought back the property stuff to 2.1, although > I'm not sure it is exactly the same as in 2.2. I had to implement it in > a different place as the core has changed. Also, there are a lot of > pre-defined properties in 2.1. I don't know if Carsten has done that in > 2.2 and if he has then the variable names probably aren't the same. > Currently there are no pre-defined properties in 2.2; I think we should try to use the same ones as in 2.1.x and introduce them in trunk now. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Removing sitemap configurable
Andrew Stevens wrote: > > Presumably it'd still be possible to configure components in the sitemap by > (re-)declaring them in the map:components section anyway? > Yes, that's still possible. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
