[continuum] BUILD FAILURE: Apache Cocoon
Online report : http://vmbuild1.apache.org/continuum/buildResult.action?buildId=892&projectId=46 Build statistics: State: Failed Previous State: Failed Started at: Thu 16 Aug 2007 16:45:26 -0700 Finished at: Thu 16 Aug 2007 16:45:30 -0700 Total time: 4s Build Trigger: Forced Build Number: 0 Exit code: 1 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version "1.6.0" Java(TM) SE Runtime Environment (build 1.6.0-b105) Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing) Builder version : Maven version: 2.0.7 Java version: 1.6.0 OS name: "linux" version: "2.6.20-16-server" arch: "i386" SCM Changes: No files changed SCM Changes since last success: Dependencies Changes: No dependencies changed Test Summary: Tests: 0 Failures: 0 Total time: 0 Output: usage: mvn [options] [] [] Options: -q,--quietQuiet output - only show errors -C,--strict-checksums Fail the build if checksums don't match -c,--lax-checksumsWarn if checksums don't match -P,--activate-profilesComma-delimited list of profiles to activate -ff,--fail-fast Stop at first failure in reactorized builds -fae,--fail-at-endOnly fail the build afterwards; allow all non-impacted builds to continue -B,--batch-mode Run in non-interactive (batch) mode -fn,--fail-never NEVER fail the build, regardless of project result -up,--update-plugins Synonym for cpu -N,--non-recursiveDo not recurse into sub-projects -npr,--no-plugin-registry Don't use ~/.m2/plugin-registry.xml for plugin versions -U,--update-snapshots Forces a check for updated releases and snapshots on remote repositories -cpu,--check-plugin-updates Force upToDate check for any relevant registered plugins -npu,--no-plugin-updates Suppress upToDate check for any relevant registered plugins -D,--define Define a system property -X,--debugProduce execution debug output -e,--errors Produce execution error messages -f,--file Force the use of an alternate POM file. -h,--help Display help information -o,--offline Work offline -r,--reactor Execute goals for project found in the reactor -s,--settings Alternate path for the user settings file -v,--version Display version information Unable to parse command line options: Unrecognized option: --recursive
[continuum] BUILD FAILURE: Apache Cocoon
Online report : http://vmbuild1.apache.org/continuum/buildResult.action?buildId=893&projectId=98 Build statistics: State: Failed Previous Build: No previous build. Started at: Thu 16 Aug 2007 17:02:02 -0700 Finished at: Thu 16 Aug 2007 17:02:03 -0700 Total time: 1s Build Trigger: Forced Build Number: 0 Exit code: 1 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version "1.6.0" Java(TM) SE Runtime Environment (build 1.6.0-b105) Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing) Builder version : Maven version: 2.0.7 Java version: 1.6.0 OS name: "linux" version: "2.6.20-16-server" arch: "i386" SCM Changes: No files changed Dependencies Changes: No dependencies changed Test Summary: Tests: 0 Failures: 0 Total time: 0 Output: Unable to parse command line options: Unrecognized option: --recursive usage: mvn [options] [] [] Options: -q,--quietQuiet output - only show errors -C,--strict-checksums Fail the build if checksums don't match -c,--lax-checksumsWarn if checksums don't match -P,--activate-profilesComma-delimited list of profiles to activate -ff,--fail-fast Stop at first failure in reactorized builds -fae,--fail-at-endOnly fail the build afterwards; allow all non-impacted builds to continue -B,--batch-mode Run in non-interactive (batch) mode -fn,--fail-never NEVER fail the build, regardless of project result -up,--update-plugins Synonym for cpu -N,--non-recursiveDo not recurse into sub-projects -npr,--no-plugin-registry Don't use ~/.m2/plugin-registry.xml for plugin versions -U,--update-snapshots Forces a check for updated releases and snapshots on remote repositories -cpu,--check-plugin-updates Force upToDate check for any relevant registered plugins -npu,--no-plugin-updates Suppress upToDate check for any relevant registered plugins -D,--define Define a system property -X,--debugProduce execution debug output -e,--errors Produce execution error messages -f,--file Force the use of an alternate POM file. -h,--help Display help information -o,--offline Work offline -r,--reactor Execute goals for project found in the reactor -s,--settings Alternate path for the user settings file -v,--version Display version information
[continuum] BUILD FAILURE: Apache Cocoon
Online report : http://vmbuild1.apache.org/continuum/buildResult.action?buildId=891&projectId=46 Build statistics: State: Failed Previous Build: No previous build. Started at: Thu 16 Aug 2007 16:44:20 -0700 Finished at: Thu 16 Aug 2007 16:44:27 -0700 Total time: 6s Build Trigger: Forced Build Number: 0 Exit code: 1 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version "1.6.0" Java(TM) SE Runtime Environment (build 1.6.0-b105) Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing) Builder version : Maven version: 2.0.7 Java version: 1.6.0 OS name: "linux" version: "2.6.20-16-server" arch: "i386" SCM Changes: No files changed Dependencies Changes: No dependencies changed Test Summary: Tests: 0 Failures: 0 Total time: 0 Output: Unable to parse command line options: Unrecognized option: --recursive usage: mvn [options] [] [] Options: -q,--quietQuiet output - only show errors -C,--strict-checksums Fail the build if checksums don't match -c,--lax-checksumsWarn if checksums don't match -P,--activate-profilesComma-delimited list of profiles to activate -ff,--fail-fast Stop at first failure in reactorized builds -fae,--fail-at-endOnly fail the build afterwards; allow all non-impacted builds to continue -B,--batch-mode Run in non-interactive (batch) mode -fn,--fail-never NEVER fail the build, regardless of project result -up,--update-plugins Synonym for cpu -N,--non-recursiveDo not recurse into sub-projects -npr,--no-plugin-registry Don't use ~/.m2/plugin-registry.xml for plugin versions -U,--update-snapshots Forces a check for updated releases and snapshots on remote repositories -cpu,--check-plugin-updates Force upToDate check for any relevant registered plugins -npu,--no-plugin-updates Suppress upToDate check for any relevant registered plugins -D,--define Define a system property -X,--debugProduce execution debug output -e,--errors Produce execution error messages -f,--file Force the use of an alternate POM file. -h,--help Display help information -o,--offline Work offline -r,--reactor Execute goals for project found in the reactor -s,--settings Alternate path for the user settings file -v,--version Display version information
[continuum] BUILD SUCCESSFUL: Cocoon XML Implementation
Online report :
http://vmbuild1.apache.org/continuum/buildResult.action?buildId=1237&projectId=85
Build statistics:
State: Ok
Previous State: Building
Started at: Sat 18 Aug 2007 15:20:20 -0700
Finished at: Sat 18 Aug 2007 15:20:32 -0700
Total time: 11s
Build Trigger: Schedule
Build Number: 4
Exit code: 0
Building machine hostname: vmbuild
Operating system : Linux(unknown)
Java Home version :
java version "1.4.2_15"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_15-b02)
Java HotSpot(TM) Client VM (build 1.4.2_15-b02, mixed mode)
Builder version :
Maven version: 2.0.7
Java version: 1.4.2_15
OS name: "linux" version: "2.6.20-16-server" arch: "i386"
SCM Changes:
No files changed
Dependencies Changes:
org.apache.cocoon:cocoon-xml-api:1.0.0-RC2-SNAPSHOT
org.apache.cocoon:cocoon-core-modules:5-SNAPSHOT
Test Summary:
Tests: 0
Failures: 0
Total time: 0
Output:
[INFO] Scanning for projects...
[INFO]
[INFO] Building Cocoon XML Implementation
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory /home/continuum/data/working-directory/85/target
[INFO] Deleting directory
/home/continuum/data/working-directory/85/target/classes
[INFO] Deleting directory
/home/continuum/data/working-directory/85/target/test-classes
[INFO] Deleting directory /home/continuum/data/working-directory/85/target/site
[INFO] [enforcer:enforce-once {execution: enforce-maven}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 4 source files to
/home/continuum/data/working-directory/85/target/classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] No sources to compile
[INFO] [surefire:test]
[INFO] No tests to run.
[INFO] [jar:jar]
[INFO] Building jar:
/home/continuum/data/working-directory/85/target/cocoon-xml-impl-1.0.0-RC2-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing
/home/continuum/data/working-directory/85/target/cocoon-xml-impl-1.0.0-RC2-SNAPSHOT.jar
to
/home/continuum/.m2/repository/org/apache/cocoon/cocoon-xml-impl/1.0.0-RC2-SNAPSHOT/cocoon-xml-impl-1.0.0-RC2-SNAPSHOT.jar
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 8 seconds
[INFO] Finished at: Sat Aug 18 15:20:31 PDT 2007
[INFO] Final Memory: 11M/21M
[INFO]
Re: [VOTE] Division of Cocoon's JIRA project
Grzegorz Kossakowski wrote: Have you tried Mylyn (Mylar in the past)? I think that Mylyn is killer plug-in for Eclipse that makes task creation very easy and _natural_. That wouldn't help me. I use (and advocate) IntelliJ. Ralph
[jira] Closed: (COCOON-2120) Move sitemap.xmap and other stuff from cocoon-webapp to it's own block
[ https://issues.apache.org/jira/browse/COCOON-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-2120. Resolution: Fixed > Move sitemap.xmap and other stuff from cocoon-webapp to it's own block > -- > > Key: COCOON-2120 > URL: https://issues.apache.org/jira/browse/COCOON-2120 > Project: Cocoon > Issue Type: Task > Components: Blocks: (Undefined) >Affects Versions: 2.2-dev (Current SVN) >Reporter: Grzegorz Kossakowski >Assignee: Grzegorz Kossakowski > Fix For: 2.2-dev (Current SVN) > > > Welcome page and other stuff should be in it's own block. > After doing that, Cocoon blocks dispatcher could be used everywhere. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2121) Servlets mounted at "/" are handled improperly.
[ https://issues.apache.org/jira/browse/COCOON-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-2121. Resolution: Fixed > Servlets mounted at "/" are handled improperly. > --- > > Key: COCOON-2121 > URL: https://issues.apache.org/jira/browse/COCOON-2121 > Project: Cocoon > Issue Type: Bug > Components: - Servlet service framework >Affects Versions: 2.2-dev (Current SVN) >Reporter: Grzegorz Kossakowski >Assignee: Grzegorz Kossakowski > Fix For: 2.2-dev (Current SVN) > > > When servlet (block) is mounted at "/" and request with path like > "/something/" is being processed by DispatcherServlet servlet will not be > choosen to process such request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2121) Servlets mounted at "/" are handled improperly.
[ https://issues.apache.org/jira/browse/COCOON-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-2121: - Assignee: Grzegorz Kossakowski > Servlets mounted at "/" are handled improperly. > --- > > Key: COCOON-2121 > URL: https://issues.apache.org/jira/browse/COCOON-2121 > Project: Cocoon > Issue Type: Bug > Components: - Servlet service framework >Affects Versions: 2.2-dev (Current SVN) >Reporter: Grzegorz Kossakowski >Assignee: Grzegorz Kossakowski > Fix For: 2.2-dev (Current SVN) > > > When servlet (block) is mounted at "/" and request with path like > "/something/" is being processed by DispatcherServlet servlet will not be > choosen to process such request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2121) Servlets mounted at "/" are handled improperly.
Servlets mounted at "/" are handled improperly. --- Key: COCOON-2121 URL: https://issues.apache.org/jira/browse/COCOON-2121 Project: Cocoon Issue Type: Bug Components: - Servlet service framework Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Fix For: 2.2-dev (Current SVN) When servlet (block) is mounted at "/" and request with path like "/something/" is being processed by DispatcherServlet servlet will not be choosen to process such request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Division of Cocoon's JIRA project
Vadim Gritsenko pisze: I would hazard a guess that impossibility to plan independent releases in JIRA, assign issues to specific version will be main cause for failing to do independent releases. We agreed long ago to do more time based releases and less feature based releases. There is no need for Jira to plan time based releases. Moreover, there is also no need for Jira to plan feature based releases as well. You can as easily use status.xml (see todo section) to track features needed for a particular release. Vadim, I may be biased in favour of JIRA because I use it quite extensively (as you can see yourself) but from my own experience JIRA offers us much more than plain text. Sorry but I don't really understand if you are joking here but taking your course of argumentation we could say that version control system is redundant because we can do well with simple bash script that will make snapshots for us regularly. No need to install svn client, learn its commands, etc. JIRA offers nice, graphical overview over progress of particular release, can produce release notes automatically, and so on. Have you tried Mylyn (Mylar in the past)? I think that Mylyn is killer plug-in for Eclipse that makes task creation very easy and _natural_. Don't be. Think of a bright side - status.xml is easier and faster to edit than Jira! :) :) Let it be a joke ;) -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/ *** My Internet Service Provider breaks my internet connection *** *** incessantly so I'll not be able to respond to e-mails *** *** regularly and my work will be somehow irregular. *** *** I'm already trying to switch ISP but it will take handful amount of time. ***
Re: [VOTE] Division of Cocoon's JIRA project
I feel a need to do some deFUDging here... Grzegorz Kossakowski wrote: On the other hand, current situation is also rather unacceptable because our current versions defined in JIRA do mean /nothing/. We all agree we need separate (and more often, sight...) release cycles and this *must* be expressed in JIRA. Why? I don't see any relation. Moreover, we can stop using Jira completely and still merrily do all our releases, with independent release cycles for all components. Jira does not help nor impede our ability to do so. I would hazard a guess that impossibility to plan independent releases in JIRA, assign issues to specific version will be main cause for failing to do independent releases. We agreed long ago to do more time based releases and less feature based releases. There is no need for Jira to plan time based releases. Moreover, there is also no need for Jira to plan feature based releases as well. You can as easily use status.xml (see todo section) to track features needed for a particular release. I may speaking about obvious things, but possibility to assign bugs to specific versions can improve situation both on developer's and user's. We could have a better idea of what's need to be done before we can release specific piece of code and our users would have a better idea when a specific issue will get fixed and how far we are from releasing something. I'm depressed... Don't be. Think of a bright side - status.xml is easier and faster to edit than Jira! :) Vadim
Re: New expressions' syntax
Daniel Fagerstrom pisze:
Which IMO is a little bit less ugly than the "\{", "\}" escaping
mechanism. And furthermore you should have most of your CSS in own files
that you include, shouldn't you.
I agree it looks better.
I lend this code from our samples. There are even long JS snippets in JX
templates 8-)
Looking at the parsing code I get the impression that "}}" -> "}" isn't
implemented correctly.
Apart from who is going to fix it, could you file an issue?
Next choice could be to use ${}. The problem with this characters is
that they are already used in Template and if we don't pick Jexl
language as default it will break current templates not to mention
confusion it would cause. We could come up with %{}, !{} or whatever
is not used yet. Everyone's keyboard has lot of remaining symbols
waiting for use but I wonder if we really want/need new wrappers.
I woulf be OK, with chosing Jexl as default EL and using "${}", but I
prefer "{}".
Daniel, what about back incompatibility, then?
Simply choosing {} is not a solution because there will be no smooth migration
path for two reasons:
a) some JX may break as proved above
b) it's all or nothing situation, if someone (or we) decides to switch to new expressions their
existing applications simply break
Such radical step has its own benefits but I'm not sure if it's exactly what
you would agree with.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
*** My Internet Service Provider breaks my internet connection
***
*** incessantly so I'll not be able to respond to e-mails
***
*** regularly and my work will be somehow irregular.
***
*** I'm already trying to switch ISP but it will take handful amount of time.
***
Re: [Fwd: B-Fabric does not run on Windows]
Sorry, that was definitly the wrong list! Apologize Felix
Re: New expressions' syntax
Grzegorz Kossakowski skrev:
...
I want
to:
a) allow people migrate to new expressions both in Template and
Sitemap smoothly
b) stay 100% back-compatible with old code behaviour while
implementing new ways of expression evaluation and most importantly
Object Model construction
c) avoid confusion about what's new and what's old
This leads us to small but very important question: how we wrap new
expressions? If I'm not wrong, current preference has been to wrap new
expressions in {}, Daniel confirms[1] this view.
My own opinion is that plain {} are ok in sitemap but will not work well
in general. If choose {} as wrapping characters everything put between
this characters will be considered as expression. If you additionally
remember that all strings inside elements are treated as String
templates you may start to be warned. Take a look this[2] file's snippet:
#files { border-collapse: collapse; border-left: dotted black 1px; }
#files td { padding: 0.1em; border-bottom: dotted black 1px; }
.selected { background: #D0D0D0; }
It's a content of jx template but obviously we don't want
generator/transformer to interpret this CSS declarations as Cocoon
expressions! We would need to escape {} wrapping characters:
#files \{ border-collapse: collapse; border-left: dotted black 1px; \}
#files td \{ padding: 0.1em; border-bottom: dotted black 1px; \}
.selected \{ background: #D0D0D0; \}
It's ugly, don't you think?
The DefaultStringTemplateParser is actually implementing the escaping
mechanism from atribute value templates in XSLT
(http://www.w3.org/TR/xslt#dt-attribute-value-template. So the example
rather becomes:
#files {{ border-collapse: collapse; border-left: dotted black 1px; }}
#files td {{ padding: 0.1em; border-bottom: dotted black 1px; }}
.selected {{ background: #D0D0D0; }}
Which IMO is a little bit less ugly than the "\{", "\}" escaping
mechanism. And furthermore you should have most of your CSS in own files
that you include, shouldn't you.
Looking at the parsing code I get the impression that "}}" -> "}" isn't
implemented correctly.
Next choice could be to use ${}. The problem with this characters is
that they are already used in Template and if we don't pick Jexl
language as default it will break current templates not to mention
confusion it would cause. We could come up with %{}, !{} or whatever is
not used yet. Everyone's keyboard has lot of remaining symbols waiting
for use but I wonder if we really want/need new wrappers.
I woulf be OK, with chosing Jexl as default EL and using "${}", but I
prefer "{}".
/Daniel
I'm stuck. Thoughts?
[1] http://marc.info/?l=xml-cocoon-dev&m=118703810504930&w=2
[2]
http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/file_explorer_template.xml
Cocoon's overview page at Daisy
Hello, I just stumbled across this overview[1] and I think it looks very nice! :) (yes, I'm talking about image). I must missed it because there was no notification about this document on our docs list thus commenting now. Thanks Reinhard for your great work! :) [1] http://cocoon.zones.apache.org/daisy/cdocs-site-22/1327.html -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
[jira] Updated: (COCOON-2120) Move sitemap.xmap and other stuff from cocoon-webapp to it's own block
[ https://issues.apache.org/jira/browse/COCOON-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-2120: - Description: Welcome page and other stuff should be in it's own block. After doing that, Cocoon blocks dispatcher could be used everywhere. was:Welcome page and other stuff should be in it's own block. > Move sitemap.xmap and other stuff from cocoon-webapp to it's own block > -- > > Key: COCOON-2120 > URL: https://issues.apache.org/jira/browse/COCOON-2120 > Project: Cocoon > Issue Type: Task > Components: Blocks: (Undefined) >Affects Versions: 2.2-dev (Current SVN) >Reporter: Grzegorz Kossakowski >Assignee: Grzegorz Kossakowski > Fix For: 2.2-dev (Current SVN) > > > Welcome page and other stuff should be in it's own block. > After doing that, Cocoon blocks dispatcher could be used everywhere. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2120) Move sitemap.xmap and other stuff from cocoon-webapp to it's own block
Move sitemap.xmap and other stuff from cocoon-webapp to it's own block -- Key: COCOON-2120 URL: https://issues.apache.org/jira/browse/COCOON-2120 Project: Cocoon Issue Type: Task Components: Blocks: (Undefined) Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Assignee: Grzegorz Kossakowski Fix For: 2.2-dev (Current SVN) Welcome page and other stuff should be in it's own block. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2119) Implement put and get methods for manipulation and access of object available at given path in Object Model
Implement put and get methods for manipulation and access of object available at given path in Object Model --- Key: COCOON-2119 URL: https://issues.apache.org/jira/browse/COCOON-2119 Project: Cocoon Issue Type: Improvement Components: - Expression language Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Assignee: Grzegorz Kossakowski Fix For: 2.2-dev (Current SVN) Actually putAt() method is already implemented. The remaining part is equivalent getAt method that accepts paths like "cocoon/request". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2118) Implement map: expression language
[
https://issues.apache.org/jira/browse/COCOON-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Kossakowski updated COCOON-2118:
-
Description:
Implement expression language ("map:") that let's you to access sitemap
variables.
Actually, it's already implemented in PreparedVariableResolver for years but
the task is about implementing it as class imlementing
org.apache.cocoon.components.expression.Expression interface.
It was proposed here[1] and clarified here[2].
[1] http://article.gmane.org/gmane.text.xml.cocoon.devel/73700
[2] http://article.gmane.org/gmane.text.xml.cocoon.devel/73760
was:
Implement expression language ("map:") that let's you to access sitemap
variables.
Actually, it's already implemented in PreparedVariableResolver for years but
the task is about implementing it as class imlementing
org.apache.cocoon.components.expression.Expression interface.
> Implement map: expression language
> --
>
> Key: COCOON-2118
> URL: https://issues.apache.org/jira/browse/COCOON-2118
> Project: Cocoon
> Issue Type: New Feature
> Components: - Components: Sitemap
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Grzegorz Kossakowski
>Assignee: Grzegorz Kossakowski
> Fix For: 2.2-dev (Current SVN)
>
>
> Implement expression language ("map:") that let's you to access sitemap
> variables.
> Actually, it's already implemented in PreparedVariableResolver for years but
> the task is about implementing it as class imlementing
> org.apache.cocoon.components.expression.Expression interface.
> It was proposed here[1] and clarified here[2].
> [1] http://article.gmane.org/gmane.text.xml.cocoon.devel/73700
> [2] http://article.gmane.org/gmane.text.xml.cocoon.devel/73760
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2118) Implement map: expression language
Implement map: expression language
--
Key: COCOON-2118
URL: https://issues.apache.org/jira/browse/COCOON-2118
Project: Cocoon
Issue Type: New Feature
Components: - Components: Sitemap
Affects Versions: 2.2-dev (Current SVN)
Reporter: Grzegorz Kossakowski
Assignee: Grzegorz Kossakowski
Fix For: 2.2-dev (Current SVN)
Implement expression language ("map:") that let's you to access sitemap
variables.
Actually, it's already implemented in PreparedVariableResolver for years but
the task is about implementing it as class imlementing
org.apache.cocoon.components.expression.Expression interface.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2117) Put sitemap variables on Object Model
Put sitemap variables on Object Model
-
Key: COCOON-2117
URL: https://issues.apache.org/jira/browse/COCOON-2117
Project: Cocoon
Issue Type: Sub-task
Components: - Components: Sitemap, - Expression language
Affects Versions: 2.2-dev (Current SVN)
Reporter: Grzegorz Kossakowski
Assignee: Grzegorz Kossakowski
Fix For: 2.2-dev (Current SVN)
Goal of this task is to implementing pushing of sitemap variables (like {1}) on
Object Model.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2116) Put sitemap execution information on Object Model
Put sitemap execution information on Object Model
-
Key: COCOON-2116
URL: https://issues.apache.org/jira/browse/COCOON-2116
Project: Cocoon
Issue Type: New Feature
Components: - Components: Sitemap, - Expression language
Affects Versions: 2.2-dev (Current SVN)
Reporter: Grzegorz Kossakowski
Assignee: Grzegorz Kossakowski
Fix For: 2.2-dev (Current SVN)
Sitemap execution information term needs clarification. Currenlty I have two
things in mind:
1. Sitemap variables (those coming from matching like {1})
2. Component parameters (those coming from elements)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: FYI: New Continuum instance
Grzegorz Kossakowski pisze: Grzegorz Kossakowski pisze: 3. It's considerably faster and has new neat options like projects group. Actually it's going to be upgraded soon so you may experience something opposite - slowness and instability but it's temporary. Ok, basic setup is up and running here: http://vmbuild1.apache.org/continuum/projectGroupSummary.action?projectGroupId=23 I set up separate build for each module using new capabilities of Continuum 1.1 beta 2. One caveat is that Continuum cannot import automatically modules pointed by profile (allblocks). It can use profiles while building, though. To work-around this limitation, current setup is as follows: 1. We have one big build of project Apache Cocoon that builds recursively all our blocks 2. We have separate builds of modules that are built by default by Maven (without -P allblocks flag) I'm going to ask Continuum folks how to import all our modules so we will have separate builds for all our modules and more fine grained control over their health. All builds are done with Java 1.4. Notifications (as you probably noticed) work ok. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
