Cocoon 2.2 Build Fails (continues to fail)
The issue reported here from September 17th... https://issues.apache.org/jira/browse/COCOON-2302 ...is still a problem for me. After adding the daisycms repo AND moving all the versions up from "1.5-dev" to "2.4" I was able to the build a little further. Also mixed in this list is "nekodtd" which I managed to find by downloading the jar from " http://repo1.maven.org/maven2/nekohtml/nekodtd/0.1.11/nekodtd-0.1.11.jar"; and installing directly. This still doesn't let me build because tests fail, starting with cocoon-html-sample block. Skipping the tests doesn't provide the "cocoon-serializers-impl" so I'm guessing html serializer is critically affected. For reference, these are the missing artifacts. 1) daisy:daisy-repository-api:jar:1.5-dev 2) daisy:daisy-repository-xmlschema-bindings:jar:1.5-dev 3) nekodtd:nekodtd:jar:0.1.11 4) daisy:daisy-repository-client-impl:jar:1.5-dev 5) daisy:daisy-repository-common-impl:jar:1.5-dev 6) daisy:daisy-repository-spi:jar:1.5-dev 7) daisy:daisy-jmsclient-api:jar:1.5-dev 8) daisy:daisy-htmlcleaner:jar:1.5-dev 9) daisy:daisy-util:jar:1.5-dev This: http://markmail.org/message/eaapichdrctmv5bx Was posted back in May with a reluctant workaround. I looks like 2.2 hasn't been able to build cleanly for months (and if it is for you, try clearing your local repo first and running).
Spring Bean Demo and RCL operational?
Hi Robby, Did you happen to test java RCL in your archetype block? That's really my pain point right now, I used to be able to make changes in .java files and it get automatic reloads, but no longer. Also! I forgot to thank you about 'setSelectionList' I ended up doing something slightly different and wanted to post my particular solution, but I got held up on something else. Maybe I'll try to dig it up. But thanks for the pointer, it was helpful! Best regards, -Will On Mon, Oct 4, 2010 at 5:09 PM, Will Heger wrote: > Thanks for the assistance. > > I'm actually not that concerned about the Spring Bean Demo, I just posted > it as a symptom. > > Java class reloading is very important to me, I find it really tough to > work when I need to start and restart jetty, even when eclipse is checking > my compiles. > > This hasn't been a problem in the past. > > In any case, I invite you to run: > mvn archetype:generate -DarchetypeCatalog=http://cocoon.apache.org > select 2, set a group/artifact and see if the bean is also broken for you > "out of the box." > > I crossposted to dev once I found that my colleague had the same problem. > > Best regards, > -Will > > > On Mon, Oct 4, 2010 at 1:36 PM, Will Heger wrote: > >> I tried this on a couple of other machines, windows etc. same problem. >> >> On Mon, Oct 4, 2010 at 4:51 AM, Will Heger wrote: >> >>> Hi, >>> >>> After creating a fresh cocoon from the archetype: >>> mvn archetype:generate -DarchetypeCatalog=http://cocoon.apache.org >>> >>> Using option 2, the block with a sample, I have two problems: >>> >>> * The Spring Demo Bean does not produces '#message' instead of the bean >>> output. >>> * RCL will not recompile after altering java files >>> >>> Is anyone experiencing a similar issue? >>> >>> Java = sun/oracle 1.6.0_21 >>> Ubuntu 10.04 >>> >>> Thanks, >>> -Will >>> >>> >> >
Spring Bean Demo and RCL operational?
Thanks for the assistance. I'm actually not that concerned about the Spring Bean Demo, I just posted it as a symptom. Java class reloading is very important to me, I find it really tough to work when I need to start and restart jetty, even when eclipse is checking my compiles. This hasn't been a problem in the past. In any case, I invite you to run: mvn archetype:generate -DarchetypeCatalog=http://cocoon.apache.org select 2, set a group/artifact and see if the bean is also broken for you "out of the box." I crossposted to dev once I found that my colleague had the same problem. Best regards, -Will On Mon, Oct 4, 2010 at 1:36 PM, Will Heger wrote: > I tried this on a couple of other machines, windows etc. same problem. > > On Mon, Oct 4, 2010 at 4:51 AM, Will Heger wrote: > >> Hi, >> >> After creating a fresh cocoon from the archetype: >> mvn archetype:generate -DarchetypeCatalog=http://cocoon.apache.org >> >> Using option 2, the block with a sample, I have two problems: >> >> * The Spring Demo Bean does not produces '#message' instead of the bean >> output. >> * RCL will not recompile after altering java files >> >> Is anyone experiencing a similar issue? >> >> Java = sun/oracle 1.6.0_21 >> Ubuntu 10.04 >> >> Thanks, >> -Will >> >> >
Spring Bean Demo and RCL operational?
I tried this on a couple of other machines, windows etc. same problem. On Mon, Oct 4, 2010 at 4:51 AM, Will Heger wrote: > Hi, > > After creating a fresh cocoon from the archetype: > mvn archetype:generate -DarchetypeCatalog=http://cocoon.apache.org > > Using option 2, the block with a sample, I have two problems: > > * The Spring Demo Bean does not produces '#message' instead of the bean > output. > * RCL will not recompile after altering java files > > Is anyone experiencing a similar issue? > > Java = sun/oracle 1.6.0_21 > Ubuntu 10.04 > > Thanks, > -Will > >
Spring Bean Demo and RCL operational?
Hi, After creating a fresh cocoon from the archetype: mvn archetype:generate -DarchetypeCatalog=http://cocoon.apache.org Using option 2, the block with a sample, I have two problems: * The Spring Demo Bean does not produces '#message' instead of the bean output. * RCL will not recompile after altering java files Is anyone experiencing a similar issue? Java = sun/oracle 1.6.0_21 Ubuntu 10.04 Thanks, -Will
root sitemap location in dev
When running a block in dev mode with jetty, the sitemap root is:
src/main/resources/COB-INF/sitemap.xmap
>From flow, I can determine this with:
cocoon.context.getRealPath("/")
But at startup, I can't locate the root sitemap. For example (using
SourceResolver from a java bean):
Source source = resolver.resolveURI("blockcontext:/my-app");
...will indicate: /target/classes/COB-INF
I believe this is accurate, that while the servlet context is the target
directory, in dev mode the sitemap root is in src.
I've looked through the beans in the application context and the
configuration settings, but I can't find anything that will point me to
where the sitemap root is. I can learn this from flow, but I'd really like
to know this at startup.
Thanks, any help is appreciated.
static setSelectionList
I have a cocoon form with many selection lists populated by flow. Until now I had believed that my 'setSelectionList()' method calls alone were changing the list contents. I did not realize the contents were dynamic by default. My problem is performance. I have many lists to update and I need fine-grained control over the list refreshes. I can't find a way to specify a static list (or the StaticSelectionList) anywhere. Thank in advance, -Will
