Re: svn line-endings config (Was: svn commit: r279905 - in /cocoon/site/site/link: livesites-2.1.html livesites-2.1.pdf)
On Sunday 11 September 2005 17:20, Jorg Heymans wrote: > That is wierd though, I had noticed this and checked my svn config : > *.html = svn:eol-style=native and auto-props enabled. I figured > something else must have been in play so I didn't think much of it. > Maybe my TortoiseSVN messed up, dunno. The "auto props" only applies to newly generated files, never to files already existing in the repository. Cheers Niclas
Re: patch commit request
Confirmed - thanks. Went and corrected a few typos just to get my feet wet. Simple and quick - just what we have needed. Thanks to all who worked to get this set up! Anyone have ideas on how to edit disconnected? (e.g., on the plane) Geoff On 9/9/05, Upayavira <[EMAIL PROTECTED]> wrote: > Geoff Howard wrote: > > ooops > > > > so can you boost my rights too? > > done. > > Upayavira >
Bug report for Cocoon 2 [2005/09/11]
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) |
| | +-+
| | | Severity: BLK=Blocker CRI=CriticalMAJ=Major |
| | | MIN=Minor NOR=Normal ENH=Enhancement |
| | | +-+
| | | | Date Posted |
| | | | +--+
| | | | | Description |
| | | | | |
| 5978|Ass|Nor|2002-01-23|Java SecurityManager java.lang.RuntimePermission c|
| 6200|New|Maj|2002-02-03|Parser failure with validate=true when processing |
| 9916|New|Enh|2002-06-17|Support passing of object parameters into sitemap |
|10203|Opn|Enh|2002-06-25|Docs referenced by XSLT's document() are not inclu|
|10827|New|Enh|2002-07-15|ESQL doesn't support namespaces|
|15302|Ass|Nor|2002-12-12|XSPUtil.relativeFilename() returns differents resu|
|15316|New|Nor|2002-12-12|FOP does not resolve relative paths |
|16537|New|Nor|2003-01-29|[PATCH] fixed redirect under JRun 3.1 |
|17594|New|Nor|2003-03-03|WebSphere redirect bug|
|17771|New|Enh|2003-03-07|[PATCH] new logging category never set when using |
|19138|New|Enh|2003-04-18|[PATCH] Made SQLTransformer paginatable |
|19641|New|Nor|2003-05-05|[PATCH] HSSFSerializer Support for FreezePane |
|20508|New|Nor|2003-06-05|[PATCH] Namespace cleanup in HTMLSerializer |
|20631|New|Enh|2003-06-10|[PATCH] Support for transactions in SQLTransformer|
|21177|Inf|Nor|2003-06-30|a crash in the name() function of the xslt, when u|
|22732|Opn|Nor|2003-08-26|Cocoon Servlet can't be included |
|23002|Ass|Nor|2003-09-08|[PATCH]: HSSF Serializer does not process are sometim|
|23901|New|Nor|2003-10-17|[PATCH] adding and moving load() and|
|23939|Inf|Nor|2003-10-20|document('relative-URI') seems to resolve wrongly |
|24135|Ass|Min|2003-10-26|carselector sample: reloading page puts old values|
|24389|New|Enh|2003-11-04|[PATCH] New ResourceLoadAction|
|24391|New|Nor|2003-11-04|[PATCH] wsinclude and htmlinclude transformers|
|24402|New|Enh|2003-11-04|[PATCH] XML posting from SourceWritingTransformer |
|24498|New|Enh|2003-11-07|Need to be able to use "cinclude" or "xinclude" to|
|24529|New|Enh|2003-11-08|[PATCH] file upload component for usage with flows|
|24741|New|Nor|2003-11-17|XSP: returns nothing|
|24871|New|Maj|2003-11-20|jsp block functionality broken, running on resin 3|
|24891|New|Nor|2003-11-21|raw-request-param returns null when used with cinc|
|25083|Opn|Nor|2003-11-29|JXTemplate evaluates expressions in comments, need|
|25099|New|Enh|2003-12-01|[Roadmap] CocoonForms |
|25100|New|Nor|2003-12-01|[PATCH] sitemap parameters support for SVGSerializ|
|25110|New|Enh|2003-12-01|[Roadmap] CocoonForms - release 1.0 |
|25113|New|Enh|2003-12-01|[Roadmap] CocoonForms - FUTURE releases |
|25114|New|Enh|2003-12-01|[Roadmap] Support for multi-page forms|
|25115|New|Enh|2003-12-01|[Roadmap] General review of all XML elements |
|25116|New|Enh|2003-12-01|[Roadmap] Tree widget |
|25280|New|Enh|2003-12-08|[Roadmap] Flowscript |
|25281|New|Enh|2003-12-08|Make it possible to use continuations in clustered|
|25284|New|Enh|2003-12-08|[Roadmap] Flowscript - FUTURE releases|
|25287|New|Enh|2003-12-08|Datatypes repository - widget definition reuse|
|25288|Ass|Enh|2003-12-08|JXTemplate: One base implementation which is easil|
|25289|New|Enh|2003-12-08|[Roadmap] Multi-sources binding |
|25290|New|Enh|2003-12-08|[Roadmap] Change expression language |
|25294|Opn|Enh|2003-12-08|Refactoring current styles for making extension si|
|25295|New|Enh|2003-12-08|XUL support |
|25298|New|Enh|2003-12-08|Calculated fields |
|25299|New|Enh|2003-12-08|Default values for fields |
|25301|New|Enh|2003-12-08|Subforms |
|25302|New|Enh|2003-12-08|Utility checking form definition and form template|
|25303|New|Enh|2003-12-08|Enhanced validation for selection lists |
|25305|New|Enh|2003-12-08|Form-model - JavaScript model |
|25306|New|Enh|2003-12-08|[Roadmap] Binding isolation m
Re: [vote] Arje Cahn as a new Cocoon committer
Daniel Fagerstrom wrote: Sylvain Wallez wrote: Hi all, I'd like to be the voice of a general opinion among Cocoon developers that Arjé Cahn should be made a Cocoon committer. +1 Upayavira
Re: Identifying expression language, Re: svn commit: r279283 - /cocoon/trunk/status.xml
Carsten Ziegeler wrote:
Leszek Gawron wrote:
It is not hardcoded, see
src\blocks\template\trunk\WEB-INF\xconf\cocoon-template-expression.xconf:
class="org.apache.cocoon.components.expression.jxpath.JXPathCompiler"
name="default"/>
class="org.apache.cocoon.components.expression.jexl.JexlCompiler"
name="jexl"/>
class="org.apache.cocoon.components.expression.jxpath.JXPathCompiler"
name="jxpath"/>
So you can choose whatever prefix you like. Moreover you are are allowed
to use {expr} which will use default expression compiler. You've got it
even shorter than before.
Ok, you *can* change the prefixes but overall it's not a good idea. If
you are using the preconfigured values everyone knows what {jexl:ddd}
means, if you change the prefix to something else, you first have to
search through the xconf and see what the prefix means.
On the same topic, what about defining the default on a per template
base? For example havign a "default-expression-language-prefix" element
on top of the template?
Doable. There is one small but for all settings like this: the jx:import
behaviour.
--
Leszek Gawron [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [vote] Arje Cahn as a new Cocoon committer
Sylvain Wallez wrote: Hi all, I'd like to be the voice of a general opinion among Cocoon developers that Arjé Cahn should be made a Cocoon committer. +1 /Daniel
[GT2005] The program: draft
Hi all, Here's a draft version of the GT program. 09:00-09:15 Welcome 09:15-09:30 Opening talk from the PMC chair: "State of the Project" 09:30-10:30 Bertrand Delacretaz: "Cocoon Bricks: best practices by example" 10:30-11:00 BREAK 11:00-11:45 Andrew Savory: "Simplifying Cocoon" 11:45-12:30 Daniel Fagerstrom: "Cocoon Blocks" 12:30-13:30 LUNCH 13:30-14:15 Sylvain Wallez: "AJAX" + Max Pfingsthorn: "CForms made easy: libraries" 14:15-15:00 Torsten Schlabach: "All about URIs or: Find your resources" 15:00-15:30 BREAK 15:30-16:15 Torsten Curdt: "Rapid Application Development with Cocoon" 16:15-17:00 Vadim/Jack: "Cocoon performance / memory consumption and XSLT" + Nico Verwer: "Cocoon performance on big documents" + Pier Fumagalli? 17:00-18:00 Reception Wow! Looks great. What about a townhall meeting? We could squeeze it in between 17:00 and 17:30. It's possible to stay until 19:00 hours, but then we'll have to pay a little bit extra... (if we have enough people this will be fine) Some interesting thoughts came up, should we do something with those? - Lightning talks - Presentations on paper - BoF sessions Please let me know if there are any objections or remarks! I might have mixed some things on the PMC list? :/ Also, if people are interesting in sponsoring, please drop me an email. Kind regards, Arjé Cahn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / www.hippo.nl --
RE: [GT2005] Cocoon GT Talks!
> BTW: at the conferences I usually attend, there is always the > opportunity to put up posters, i.e. a large paper that explains the > topic. Is there space available to put up poster boards with posters > (either in A0 size or just plain A4 pages pasted together) > for the talks > "that don't make it"? Not to mention the cost. Could do. What do you have in mind exactly? Arje
RE: [vote] Arje Cahn as a new Cocoon committer
Hi all, Many thanks for all the positive votes that have been brought out so far! Although it's not final yet, I'd like to express that I would be very happy to receive committership from the Cocoon community. For me, this comes as a big, pleasant surprise. I've always enjoyed "being around" in the Cocoon community, and Sylvain's expression that I should be made a committer simply validates what I've already felt for a long time: one can feel accepted as a Cocoon community member, just by being oneself. You don't need to be a committer to be welcome, and that's exactly why I've enjoyed all those moments where Cocoon developers meet up and why I was so happy to be able to host this year's GetTogether. Now, being proposed by that same community for becoming a committer, I sense that my feeling was right. Whatever the contribution; as long as it's good, it's very well appreciated. Organizing the GT is my way of saying "thank you" to this great community, and I wasn't expecting to get one in return! Not now, and *CERTAINLY* not like this ! :-D So, I'll do my best to live up to being a committer. Although my commits might not be in code (yet! ;) ), I promise I'll do my best to commit plenty. I'd like to thank everyone for collaborating on such a great project, and also I'd like to thank my colleagues at Hippo, who've been doing so much great work on and with Cocoon, and who should definitely get more time to spend on Cocoon commitment too :). Thanks, everyone! Now, let's get this GT program online!! 8-D Arjé > -Original Message- > From: Sylvain Wallez [mailto:[EMAIL PROTECTED] > Posted At: donderdag 8 september 2005 20:42 > Posted To: Cocoon Dev List > Conversation: [vote] Arje Cahn as a new Cocoon committer > Subject: [vote] Arje Cahn as a new Cocoon committer > > > Hi all, > > I'd like to be the voice of a general opinion among Cocoon developers > that Arjé Cahn should be made a Cocoon committer. > > Arjé has been using Cocoon for years and has taken the > responsibility of > organizing the upcoming GetTogether, which shows how much he > cares for > Cocoon and its community. And we value this a lot. > > This isn't the usual committer vote, since Arjé hasn't > provided a lot of > code patches. But quoting Stefano, "committer means 'being > committed to > the project' rather than being able to commit code". > > There are some precendents for this: Matthew Langham and > Andrew Savory > were made committers, because we felt they were important citizens of > the Cocoon community. The same applies to Arjé today. > > Please cast your votes! > > Sylvain > > -- > Sylvain WallezAnyware Technologies > http://people.apache.org/~sylvain http://www.anyware-tech.com > Apache Software Foundation Member Research & Technology Director > >
Re: cocoon maven repository
Stefan Podkowinski schrieb: > How are you going to ship cocoon distributions after moving to m2? > Will you have all dependencies included in a whatever.tar.gz archive > or let maven do the downloads from a remote repo (and break the > current download/mirroring process)? In second case, whats the reason > not to setup a m1 remote repo as well? > The bin dist will contain all required jars while the src dist will use m2 to build. All dependencies will be available on publically reachable repositories. Most of our dependencies are available from the usual Maven repos. The rest will be put on http://cvs.apache.org/repository which is a m1 style repository. You'll find the required snapshots (e.g. Rhino) there. On the long term we will not use snapshorts but only released versions and hope that the projects we depend on put their jars into the usual maven repositories. HTH Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[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 50 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-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-chaperon : Java XML Framework - 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-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-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-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-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] -DEBUG- Dependency on avalon-framework-api exists, no need to add for property avalonapi.jar. -INFO- Made directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-11092005/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-11092005/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-11092005/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: 16 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/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Davalonapi.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-11092005.jar -Dlogkit.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-11092005.jar -Dbuild=build/cocoon-11092005 gump-core [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-11092005/classes:/usr/local/gump/public/workspace/cocoon/build/coco
[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 50 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-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-chaperon : Java XML Framework - 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-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-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-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-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] -DEBUG- Dependency on avalon-framework-api exists, no need to add for property avalonapi.jar. -INFO- Made directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-11092005/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-11092005/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-11092005/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: 16 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/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Davalonapi.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-11092005.jar -Dlogkit.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-11092005.jar -Dbuild=build/cocoon-11092005 gump-core [Working Directory: /usr/local/gump/public/workspace/cocoon] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-11092005/classes:/usr/local/gump/public/workspace/cocoon/build/coco
Re: svn line-endings config (Was: svn commit: r279905 - in /cocoon/site/site/link: livesites-2.1.html livesites-2.1.pdf)
Jorg Heymans wrote: > David Crossley wrote: > > Erk, something went wrong. This generated file has Windows > > end-of-line markers, so that makes it look like the whole > > file was changed. It is not your fault Jorg. The svn:eol-style > > property is not set, so this is the effect. Each time someone > > generates it on different platforms, then line endings will > > change and therefore huge diffs. > > That is wierd though, I had noticed this and checked my svn config : > *.html = svn:eol-style=native and auto-props enabled. I figured > something else must have been in play so I didn't think much of it. > Maybe my TortoiseSVN messed up, dunno. No, as i said it is not you. Because none of these files had their svn properties set, then for me on unix and you on windows, we kept changing the line-endings back and forth. Anyway it is fixed now. -David
Re: svn commit: r279762 - in /cocoon/branches/BRANCH_2_1_X: legal/msv-20030225.jar.license.txt lib/optional/msv-20030225.jar src/blocks/validation/java/org/apache/cocoon/components/validation/Validator.java
On 11 Sep 2005, at 07:05, David Crossley wrote: Ah i see now where my extra comments in msg18202 came from: I refererred to an additional file called "copyright.txt" which must have had extra restrictions. Don't know if that is still the same today. The copyright.txt just states that it's (C) Sun and that it might contain some of their patents... So, stating the obvious, but not restrictions. Pier smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r279762 - in /cocoon/branches/BRANCH_2_1_X: legal/msv-20030225.jar.license.txt lib/optional/msv-20030225.jar src/blocks/validation/java/org/apache/cocoon/components/validation/Validator.java
On 11 Sep 2005, at 08:07, Antonio Gallardo wrote: Pier Fumagalli wrote: On 10 Sep 2005, at 20:17, Antonio Gallardo wrote: Darn... I wish you found that when I posted the license before committing... http://www.mail-archive.com/dev@cocoon.apache.org/msg34406.html Yep. I am really sorry for not having time to search the mail before the weekend. :-( No worries... My bad... I should've checked more thoroughly first. Pier smime.p7s Description: S/MIME cryptographic signature
Re: cocoon maven repository
How are you going to ship cocoon distributions after moving to m2? Will you have all dependencies included in a whatever.tar.gz archive or let maven do the downloads from a remote repo (and break the current download/mirroring process)? In second case, whats the reason not to setup a m1 remote repo as well? On 9/10/05, Niclas Hedhman <[EMAIL PROTECTED]> wrote: > On Saturday 10 September 2005 23:33, Jorg Heymans wrote: > > Stefan Podkowinski wrote: > > > The project will be hosted on sourceforge so I can't really setup my > > > own repository for this. Another option would be to ship dependencies > > > not available on public repos with my distribution. But I want do > > > avoid this if possible to keep download size for updates as small as > > > possible. > > > > Actually, i think we have created a small m2 cocoon repository somewhere > > on the Apache servers. I can't remember exactly where and how, but > > possibly we could provide an m1 style repository as well. > > There is a general "avoid snapshots" policy for ASF repositories, as they will > not be guaranteed to be there 'forever' which may cause trouble to users, and > a "no snapshot" policy for the repository that gets replicated to > ibiblio.org. > > If special builds, snapshots and what not can't be avoided, the best practice > is probably to ship those explicitly. > > > Cheers > Niclas >
Re: Identifying expression language, Re: svn commit: r279283 - /cocoon/trunk/status.xml
Leszek Gawron wrote:
> It is not hardcoded, see
> src\blocks\template\trunk\WEB-INF\xconf\cocoon-template-expression.xconf:
>
>
> class="org.apache.cocoon.components.expression.jxpath.JXPathCompiler"
> name="default"/>
> class="org.apache.cocoon.components.expression.jexl.JexlCompiler"
> name="jexl"/>
> class="org.apache.cocoon.components.expression.jxpath.JXPathCompiler"
> name="jxpath"/>
>
>
> So you can choose whatever prefix you like. Moreover you are are allowed
> to use {expr} which will use default expression compiler. You've got it
> even shorter than before.
>
Ok, you *can* change the prefixes but overall it's not a good idea. If
you are using the preconfigured values everyone knows what {jexl:ddd}
means, if you change the prefix to something else, you first have to
search through the xconf and see what the prefix means.
On the same topic, what about defining the default on a per template
base? For example havign a "default-expression-language-prefix" element
on top of the template?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: svn line-endings config (Was: svn commit: r279905 - in /cocoon/site/site/link: livesites-2.1.html livesites-2.1.pdf)
David Crossley wrote: > Erk, something went wrong. This generated file has Windows > end-of-line markers, so that makes it look like the whole > file was changed. It is not your fault Jorg. The svn:eol-style > property is not set, so this is the effect. Each time someone > generates it on different platforms, then line endings will > change and therefore huge diffs. > That is wierd though, I had noticed this and checked my svn config : *.html = svn:eol-style=native and auto-props enabled. I figured something else must have been in play so I didn't think much of it. Maybe my TortoiseSVN messed up, dunno. Thanks Jorg
Re: svn commit: r279762 - in /cocoon/branches/BRANCH_2_1_X: legal/msv-20030225.jar.license.txt lib/optional/msv-20030225.jar src/blocks/validation/java/org/apache/cocoon/components/validation/Validator.java
Pier Fumagalli wrote: On 10 Sep 2005, at 20:17, Antonio Gallardo wrote: Ralph Goers wrote: Ralph Goers wrote: I seem to remember reading on legal-discuss that the "nuclear clause" is incompatible with the ASL. If true, any components with such a license can not be disctributed with our code or reside in SVN. Ralph Faulty memory. The only reference I could find was at http:// wiki.apache.org/jakarta/LicenceIssues which, of course, is not "official" ASF policy. I found it! http://www.mail-archive.com/dev@cocoon.apache.org/msg18202.html Darn... I wish you found that when I posted the license before committing... http://www.mail-archive.com/dev@cocoon.apache.org/msg34406.html Yep. I am really sorry for not having time to search the mail before the weekend. :-( Best Regards, Antonio Gallardo.
