Re: Javadocs
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
But now I run into another problem: When I use the find/xargs command,
the working directory is the directory where I entered this command
and not the directory where the create-apidocs.sh script is located.
Is there a way to set the working directory the way I have expected it?
Yep. Put this script say in your home dir, name it 'x.sh' and make it
executable:
#!/bin/sh
cd `dirname $1`
# Both "sh $1" and ". $1" should work
. $1
From your home dir (where x.sh is):
find /x1/www/cocoon.apache.org/2.2 -name "create-apidocs.sh" | grep
apidocs/ | xargs -n 1 ./x.sh
thanks, works like a charm!
Alternatively you can put cd `dirname $1` in each of create-apidocs.sh
but I figured you'd want to avoid this :)
:-)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Java 1.5
Joerg Heinicke wrote:
On 25.09.2007 15:45 Uhr, Vadim Gritsenko wrote:
Our problem is not minimum Java requirement for Cocoon 2.2. The
problem is release time lines. [..] Java requirements? Nah, that's
peanuts...
Thanks, you hit the nail. When was the vote? 1 year ago?
Despite being still convinced that raising the requirement to Java 5
does not buy as a lot if anything (Just think of java.nio, which is
supposed to bring a big performance gain and would so be a real
advantage for the user. I never saw ANY code in Cocoon using it.) I
herewith withdraw my -1 since I'm just tired of discussing this over and
over again.
I finally managed to create all the release artifacts. The problem was that
hardly any (or nobody) of the committers is using Maven 2 with Java 1.4. (The
funny thing is that our Continuum instance does not suffer from this problems.)
This combination leads to some problems and I was tired of fixing them just for
the sake of a release.
I think for 2.2 it is fine to stick with Java 1.4 and go for Java 5 with 2.3.
This should also give the Websphere 6 users enough time and is for all the Java
5 fans motivation to make 2.3 happen soon ;-)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Java 1.5
On 28.09.2007 0:46 Uhr, Ralph Goers wrote: However, the language features of 1.5 are worth it. For example, I would love to replace some pieces of code that require synchronized blocks with java.util.concurent. I would love to be able to specify the object types on Maps and Lists. It just makes for better code. That's unlikely to happen before the release I guess. Maybe you should have this in mind when deciding about the requirement for Cocoon 2.2 - even if this locks it to 1.4. java.util.concurrent is also available as backwards-compatible version for 1.4. Joerg
Re: Java 1.5
On 28.09.2007 0:46 Uhr, Ralph Goers wrote: I'm sure we could find a way to take advantage of NIO if we really thought about it. But we can't do any of that because we are stuck at 1.4. NIO is 1.4. Joerg
Re: Java 1.5 [was svn commit: r579132 - in /cocoon/trunk/core/cocoon-core/src/test/java/org/apache/cocoon/transfo rmation:I18NTransformerTestCase.java I18NTransformerTestCase.java.disabl
On 25.09.2007 15:45 Uhr, Vadim Gritsenko wrote: Our problem is not minimum Java requirement for Cocoon 2.2. The problem is release time lines. [..] Java requirements? Nah, that's peanuts... Thanks, you hit the nail. When was the vote? 1 year ago? Despite being still convinced that raising the requirement to Java 5 does not buy as a lot if anything (Just think of java.nio, which is supposed to bring a big performance gain and would so be a real advantage for the user. I never saw ANY code in Cocoon using it.) I herewith withdraw my -1 since I'm just tired of discussing this over and over again. So if you really think it's worth it go ahead. Otherwise I'm with Vadim's plan: I'm completely expecting Cocoon 2.3 to be at Java 1.5 level, and 2.4 may be at Java 1.6 level. Joerg
Re: Java 1.5
Joerg Heinicke wrote: On 25.09.2007 16:20 Uhr, Felix Knecht wrote: May I ask why can't just make a jump and goto java 1.6? What's the benefit of using not the latest version - do any contracts exists that we can't jump over a java version? And what's the use of it? I just don't get it why a framework should set restrictions on its user base. While nothing prevents you to use 1.6. I don't necessarily agree with setting 1.6 as the minimum myself. Mostly because it doesn't add much over 1.5. However, the language features of 1.5 are worth it. For example, I would love to replace some pieces of code that require synchronized blocks with java.util.concurent. I would love to be able to specify the object types on Maps and Lists. It just makes for better code. I'm sure we could find a way to take advantage of NIO if we really thought about it. But we can't do any of that because we are stuck at 1.4. Ralph
Re: Java 1.5
On 25.09.2007 16:20 Uhr, Felix Knecht wrote: May I ask why can't just make a jump and goto java 1.6? What's the benefit of using not the latest version - do any contracts exists that we can't jump over a java version? And what's the use of it? I just don't get it why a framework should set restrictions on its user base. While nothing prevents you to use 1.6. Joerg
Re: Javadocs
Reinhard Poetz wrote: But now I run into another problem: When I use the find/xargs command, the working directory is the directory where I entered this command and not the directory where the create-apidocs.sh script is located. Is there a way to set the working directory the way I have expected it? Yep. Put this script say in your home dir, name it 'x.sh' and make it executable: #!/bin/sh cd `dirname $1` # Both "sh $1" and ". $1" should work . $1 From your home dir (where x.sh is): find /x1/www/cocoon.apache.org/2.2 -name "create-apidocs.sh" | grep apidocs/ | xargs -n 1 ./x.sh Alternatively you can put cd `dirname $1` in each of create-apidocs.sh but I figured you'd want to avoid this :) Vadim
Re: Javadocs
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
thanks. The command seems to work but I have a problem to execute the
script because David is the owner and neither chown nor chmod are
permitted using my account:
/x1/www/cocoon.apache.org/2.2/core-modules/pipeline-api/1.0/apidocs
> ls -lsa
total 14
2 drwxrwxr-x 3 crossley cocoon 512 Sep 26 17:08 .
2 drwxrwxr-x 6 crossley cocoon 512 Sep 26 17:08 ..
2 drwxrwxr-x 6 crossley cocoon 512 Sep 27 14:33 .svn
2 -rw-rw-r-- 1 crossley cocoon 581 Sep 26 17:08 create-apidocs.sh
You don't need chmod/chown; permissions are looking fine as it is. But
when I try to run it, I get an error:
[EMAIL PROTECTED]
/x1/www/cocoon.apache.org/2.2/core-modules/pipeline-api/1.0/apidocs $
bash create-apidocs.sh
Creating JavaDocs for cocoon-pipeline-api:1.0.0-RC2
create-apidocs.sh: line 9: syntax error near unexpected token `else'
create-apidocs.sh: line 9: `else'
When I fixed both if/then/else:
if [ ! -f $f ]
then
wget --header "User-Agent: Mozilla/5.0 Firefox/2.0.0.7"
http://repo1.maven.org/maven2/$jd
dl=1
fi
This seems to be subtle difference between shell script interpreters:
find . -name "create-apidocs.sh" | grep apidocs | xargs sh
works fine without having to change the if/then/else syntax.
But now I run into another problem: When I use the find/xargs command, the
working directory is the directory where I entered this command and not the
directory where the create-apidocs.sh script is located. Is there a way to set
the working directory the way I have expected it?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Javadocs
Reinhard Poetz wrote: thanks. The command seems to work but I have a problem to execute the script because David is the owner and neither chown nor chmod are permitted using my account: /x1/www/cocoon.apache.org/2.2/core-modules/pipeline-api/1.0/apidocs > ls -lsa total 14 2 drwxrwxr-x 3 crossley cocoon 512 Sep 26 17:08 . 2 drwxrwxr-x 6 crossley cocoon 512 Sep 26 17:08 .. 2 drwxrwxr-x 6 crossley cocoon 512 Sep 27 14:33 .svn 2 -rw-rw-r-- 1 crossley cocoon 581 Sep 26 17:08 create-apidocs.sh You don't need chmod/chown; permissions are looking fine as it is. But when I try to run it, I get an error: [EMAIL PROTECTED] /x1/www/cocoon.apache.org/2.2/core-modules/pipeline-api/1.0/apidocs $ bash create-apidocs.sh Creating JavaDocs for cocoon-pipeline-api:1.0.0-RC2 create-apidocs.sh: line 9: syntax error near unexpected token `else' create-apidocs.sh: line 9: `else' When I fixed both if/then/else: if [ ! -f $f ] then wget --header "User-Agent: Mozilla/5.0 Firefox/2.0.0.7" http://repo1.maven.org/maven2/$jd dl=1 fi It was working fine: [EMAIL PROTECTED] /x1/www/cocoon.apache.org/2.2/core-modules/pipeline-api/1.0/apidocs $ bash create-apidocs.sh Creating JavaDocs for cocoon-pipeline-api:1.0.0-RC2 --15:33:08-- http://repo1.maven.org/maven2/org/apache/cocoon/cocoon-pipeline-api/1.0.0-RC2/cocoon-pipeline-api-1.0.0-RC2-javadoc.jar => `cocoon-pipeline-api-1.0.0-RC2-javadoc.jar' Resolving repo1.maven.org... 63.246.20.112 Connecting to repo1.maven.org|63.246.20.112|:80... connected. HTTP request sent, awaiting response... 404 Not Found 15:33:08 ERROR 404: Not Found. --15:33:08-- http://people.apache.org/builds/cocoon/org/apache/cocoon/cocoon-pipeline-api/1.0.0-RC2/cocoon-pipeline-api-1.0.0-RC2-javadoc.jar => `cocoon-pipeline-api-1.0.0-RC2-javadoc.jar' Resolving people.apache.org... 140.211.11.9 Connecting to people.apache.org|140.211.11.9|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 362,072 (354K) [application/java-archive] 100%[===>] 362,072 --.--K/s 15:33:08 (41.75 MB/s) - `cocoon-pipeline-api-1.0.0-RC2-javadoc.jar' saved [362072/362072] [EMAIL PROTECTED] /x1/www/cocoon.apache.org/2.2/core-modules/pipeline-api/1.0/apidocs $ ls META-INF/ help-doc.html overview-tree.html allclasses-frame.html index-all.html package-list allclasses-noframe.html index.html packages cocoon-pipeline-api-1.0.0-RC2-javadoc.jar options packages.html constant-values.htmlorg/ resources/ create-apidocs.sh overview-frame.html serialized-form.html deprecated-list.htmloverview-summary.html stylesheet.css Vadim
Re: Javadocs
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Could somebody help me with an additional script which recursivly
scans for the download scripts, sets the "x" attribute on the file
and executes it then?
Sure; what's the script name / name pattern?
It will be located in apidocs/create-apidocs.sh
This will do it:
find . -name "create-apidocs.sh" | grep apidocs | xargs bash
thanks. The command seems to work but I have a problem to execute the script
because David is the owner and neither chown nor chmod are permitted using my
account:
/x1/www/cocoon.apache.org/2.2/core-modules/pipeline-api/1.0/apidocs
> ls -lsa
total 14
2 drwxrwxr-x 3 crossley cocoon 512 Sep 26 17:08 .
2 drwxrwxr-x 6 crossley cocoon 512 Sep 26 17:08 ..
2 drwxrwxr-x 6 crossley cocoon 512 Sep 27 14:33 .svn
2 -rw-rw-r-- 1 crossley cocoon 581 Sep 26 17:08 create-apidocs.sh
6 -rw-rw-r-- 1 crossley cocoon 5385 Sep 26 17:08 index.html
(When I copy the script into my home directory, it works fine.)
Can anybody help?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Code freeze - over
Reinhard Poetz wrote:
Reinhard Poetz wrote:
All release artifacts and their docs have been created. This means
that the code freeze is over and our SVN is happily awaiting your
commits again!
Currently trunk doesn't build because the parent pom references are
not set correctly. I will take care for this tommorrow morning if
nobody else is doing it in the meantime:
You would just have to use tools/pom-updater/pu.sh and set
org.apache.cocoon:cocoon
org.apache.cocoon:cocoon-blocks-modules
org.apache.cocoon:cocoon-core-modules
org.apache.cocoon:cocoon-tools-modules
to 6-SNAPSHOT.
I have some unexpected free time this evening and I'm going to run the
pom-updater now.
the build runs through again for me. If you find any problems pls let us know
via this list - filing a Jira issue shouldn't be necessary.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Code freeze - over
Reinhard Poetz wrote:
All release artifacts and their docs have been created. This means that
the code freeze is over and our SVN is happily awaiting your commits again!
Currently trunk doesn't build because the parent pom references are not
set correctly. I will take care for this tommorrow morning if nobody
else is doing it in the meantime:
You would just have to use tools/pom-updater/pu.sh and set
org.apache.cocoon:cocoon
org.apache.cocoon:cocoon-blocks-modules
org.apache.cocoon:cocoon-core-modules
org.apache.cocoon:cocoon-tools-modules
to 6-SNAPSHOT.
I have some unexpected free time this evening and I'm going to run the
pom-updater now.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
[continuum] BUILD FAILURE: Apache Cocoon
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=8469&projectId=51 Build statistics: State: Failed Previous State: Failed Started at: Thu 27 Sep 2007 11:00:34 -0700 Finished at: Thu 27 Sep 2007 11:00:48 -0700 Total time: 13s Build Trigger: Schedule Build Number: 24 Exit code: 1 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: Changed: reinhard @ Thu 27 Sep 2007 10:06:33 -0700 Comment: snapshot mode Files changed: /cocoon/trunk/blocks/cocoon-ajax/cocoon-ajax-impl/pom.xml ( 580098 ) Changed: reinhard @ Thu 27 Sep 2007 10:08:25 -0700 Comment: [maven-release-plugin] prepare release cocoon-apples-impl-1.0.0-RC2 Files changed: /cocoon/trunk/blocks/cocoon-apples/cocoon-apples-impl/pom.xml ( 580099 ) Changed: reinhard @ Thu 27 Sep 2007 10:08:41 -0700 Comment: [maven-release-plugin] prepare for next development iteration Files changed: /cocoon/trunk/blocks/cocoon-apples/cocoon-apples-impl/pom.xml ( 580101 ) Changed: reinhard @ Thu 27 Sep 2007 10:15:55 -0700 Comment: snapshot mode Files changed: /cocoon/trunk/blocks/cocoon-apples/cocoon-apples-impl/pom.xml ( 580103 ) Changed: reinhard @ Thu 27 Sep 2007 10:20:51 -0700 Comment: [maven-release-plugin] prepare release cocoon-forms-impl-1.0.0-RC1 Files changed: /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/pom.xml ( 580104 ) Changed: reinhard @ Thu 27 Sep 2007 10:21:21 -0700 Comment: [maven-release-plugin] prepare for next development iteration Files changed: /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/pom.xml ( 580106 ) Dependencies Changes: No dependencies changed Build Defintion: POM filename: pom.xml Goals: clean install Arguments: --batch-mode -P allblocks Build Fresh: false Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Java 1.4, Large Memory Description: Test Summary: Tests: 2307 Failures: 0 Total time: 47661 Output: [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.cocoon ArtifactId: cocoon-blocks-modules Version: 6-SNAPSHOT Reason: Unable to download the artifact from any repository org.apache.cocoon:cocoon-blocks-modules:pom:6-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache.cocoon:cocoon-blocks-modules for project: null:cocoon-ajax-impl:jar:1.0.0-RC2-SNAPSHOT for project null:cocoon-ajax-impl:jar:1.0.0-RC2-SNAPSHOT at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: org.apache.cocoon:cocoon-blocks-modules for project: null:cocoon-ajax-imp
Code freeze - over
All release artifacts and their docs have been created. This means that the code
freeze is over and our SVN is happily awaiting your commits again!
Currently trunk doesn't build because the parent pom references are not set
correctly. I will take care for this tommorrow morning if nobody else is doing
it in the meantime:
You would just have to use tools/pom-updater/pu.sh and set
org.apache.cocoon:cocoon
org.apache.cocoon:cocoon-blocks-modules
org.apache.cocoon:cocoon-core-modules
org.apache.cocoon:cocoon-tools-modules
to 6-SNAPSHOT.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Renewing Apache Fop processor
Robby Pelssers wrote: Hi, I regularly seem to have problems because the current distributed version of apache fop processor (fop-0.5.20.jar) does not support a lot of needed attributes like for instance "linefeed-treatment". http://xmlgraphics.apache.org/fop/compliance.html#fo-object-block-sectio n How difficult/easy would it be to use a newer version (0.93 or 0.94)? Is it only a matter of replacing the jar with a newer jar or do I run into problems in that case? Easy: just use fop-ng block. You also have to update your fop config file, if you are using it. Vadim
[continuum] BUILD FAILURE: Apache Cocoon
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=8462&projectId=51 Build statistics: State: Failed Previous State: Failed Started at: Thu 27 Sep 2007 10:00:33 -0700 Finished at: Thu 27 Sep 2007 10:00:43 -0700 Total time: 9s Build Trigger: Schedule Build Number: 24 Exit code: 1 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: Changed: reinhard @ Thu 27 Sep 2007 09:12:26 -0700 Comment: [maven-release-plugin] prepare release cocoon-servlet-service-impl-1.0.0-RC1 Files changed: /cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/pom.xml ( 580074 ) Changed: reinhard @ Thu 27 Sep 2007 09:12:47 -0700 Comment: [maven-release-plugin] prepare for next development iteration Files changed: /cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/pom.xml ( 580076 ) Changed: reinhard @ Thu 27 Sep 2007 09:22:46 -0700 Comment: snapshot mode Files changed: /cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/pom.xml ( 580080 ) Changed: reinhard @ Thu 27 Sep 2007 09:30:46 -0700 Comment: [maven-release-plugin] prepare release cocoon-servlet-service-components-1.0.0-RC1 Files changed: /cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-components/pom.xml ( 580082 ) Changed: reinhard @ Thu 27 Sep 2007 09:31:02 -0700 Comment: [maven-release-plugin] prepare for next development iteration Files changed: /cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-components/pom.xml ( 580084 ) Changed: reinhard @ Thu 27 Sep 2007 09:41:30 -0700 Comment: snapshot mode Files changed: /cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-components/pom.xml ( 580088 ) Changed: reinhard @ Thu 27 Sep 2007 09:45:15 -0700 Comment: [maven-release-plugin] prepare release cocoon-ajax-impl-1.0.0-RC1 Files changed: /cocoon/trunk/blocks/cocoon-ajax/cocoon-ajax-impl/pom.xml ( 580091 ) Changed: reinhard @ Thu 27 Sep 2007 09:45:35 -0700 Comment: [maven-release-plugin] prepare for next development iteration Files changed: /cocoon/trunk/blocks/cocoon-ajax/cocoon-ajax-impl/pom.xml ( 580093 ) Dependencies Changes: No dependencies changed Build Defintion: POM filename: pom.xml Goals: clean install Arguments: --batch-mode -P allblocks Build Fresh: false Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Java 1.4, Large Memory Description: Test Summary: Tests: 2307 Failures: 0 Total time: 47661 Output: [INFO] Scanning for projects... Downloading: http://repo1.maven.org/maven2/org/apache/cocoon/cocoon-blocks-modules/5/cocoon-blocks-modules-5.pom [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.cocoon ArtifactId: cocoon-blocks-modules Version: 5 Reason: Unable to download the artifact from any repository org.apache.cocoon:cocoon-blocks-modules:pom:5 from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache.cocoon:cocoon-blocks-modules for project: null:cocoon-ajax-impl:jar:1.0.0-RC2-SNAPSHOT for project null:cocoon-ajax-impl:jar:1.0.0-RC2-SNAPSHOT at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMe
Renewing Apache Fop processor
Hi, I regularly seem to have problems because the current distributed version of apache fop processor (fop-0.5.20.jar) does not support a lot of needed attributes like for instance "linefeed-treatment". http://xmlgraphics.apache.org/fop/compliance.html#fo-object-block-sectio n How difficult/easy would it be to use a newer version (0.93 or 0.94)? Is it only a matter of replacing the jar with a newer jar or do I run into problems in that case? Cheers, Robby Pelssers
[continuum] BUILD FAILURE: Apache Cocoon
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=8445&projectId=51 Build statistics: State: Failed Previous State: Failed Started at: Thu 27 Sep 2007 07:01:38 -0700 Finished at: Thu 27 Sep 2007 07:02:08 -0700 Total time: 29s Build Trigger: Schedule Build Number: 24 Exit code: 1 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: Changed: reinhard @ Thu 27 Sep 2007 06:15:30 -0700 Comment: fix paths for creation of subproject docs; move javadocs-script reporting plugin into its own profile Files changed: /cocoon/trunk/pom.xml ( 580002 ) Changed: reinhard @ Thu 27 Sep 2007 06:25:53 -0700 Comment: fix paths Files changed: /cocoon/trunk/site/cocoon-configuration-site/pom.xml ( 580004 ) /cocoon/trunk/site/cocoon-servlet-service-site/pom.xml ( 580004 ) Changed: reinhard @ Thu 27 Sep 2007 06:26:30 -0700 Comment: [maven-release-plugin] prepare release cocoon-5 Files changed: /cocoon/trunk/pom.xml ( 580005 ) Changed: reinhard @ Thu 27 Sep 2007 06:27:06 -0700 Comment: fix paths; move javadocs-script report into its own profile Files changed: /cocoon/trunk/core/cocoon-configuration/cocoon-configuration-api/pom.xml ( 580006 ) /cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/pom.xml ( 580006 ) Changed: reinhard @ Thu 27 Sep 2007 06:27:49 -0700 Comment: fix paths; move javadocs-script report into its own profile Files changed: /cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-components/pom.xml ( 580007 ) /cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/pom.xml ( 580007 ) Changed: reinhard @ Thu 27 Sep 2007 06:31:48 -0700 Comment: [maven-release-plugin] prepare for next development iteration Files changed: /cocoon/trunk/pom.xml ( 580011 ) Dependencies Changes: No dependencies changed Build Defintion: POM filename: pom.xml Goals: clean install Arguments: --batch-mode -P allblocks Build Fresh: false Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Java 1.4, Large Memory Description: Test Summary: Tests: 2307 Failures: 0 Total time: 47661 Output: [INFO] Scanning for projects... Downloading: http://repo1.maven.org/maven2/org/apache/cocoon/cocoon-blocks-modules/5/cocoon-blocks-modules-5.pom [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.cocoon ArtifactId: cocoon-blocks-modules Version: 5 Reason: Unable to download the artifact from any repository org.apache.cocoon:cocoon-blocks-modules:pom:5 from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache.cocoon:cocoon-blocks-modules for project: null:cocoon-databases-hsqldb-server:jar:1.0.0-RC3-SNAPSHOT for project null:cocoon-databases-hsqldb-server:jar:1.0.0-RC3-SNAPSHOT at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.L
Re: Springifying CForms
Felix Knecht wrote:
Do you know why we have these extra directories at all instead of flat
block directory?
Just my 2 cents
Why do some blocks have 'super' poms including api/impl/sample and
others don't?
I've removed those extra POM level from all blocks that I have to release
because this would double my work. Since not all blocks have seen a release yet,
not all extra POMs are removed.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Springifying CForms
> Do you know why we have these extra directories at all instead of flat > block directory? > Just my 2 cents Why do some blocks have 'super' poms including api/impl/sample and others don't? Felix > Vadim >
Re: Springifying CForms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vadim Gritsenko wrote: > Giacomo Pati wrote: >>> BTW: Do we create a branch of cocoon-form-(sample|impl) so that we >>> will have a new version for the >>> sprinigied blocks? >> >> As nobody commented on this I'll going to branch cocoon-form before I >> commit the sprinified CForms, >> as soon as Reinhard has finished releasing. Do I have to branch each >> block (cocoon-forms-impl and >> cocoon-forms-sample) individually or is branching their upper >> directory (cocoon-forms) enough? > > I'd guess branching upper directory is enough, with editing of trunk > POMs to set versions to the next one. Sure. > Do you know why we have these extra directories at all instead of flat > block directory? Probably because of structuring purpose grouping the impl/api/sample into its own directory, but this is just a guess. - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.6 (GNU/Linux) iD8DBQFG+6TLLNdJvZjjVZARAivOAJ0UyRctz7Znh2GY28YPXZuQbsNTxwCdEpz5 X1nVIkJtEZRbaCK2K2G4oUA= =czZS -END PGP SIGNATURE-
Re: Springifying CForms
Giacomo Pati wrote:
Reinhard Poetz wrote:
As nobody commented on this I'll going to branch cocoon-form before I
commit the sprinified CForms,
as soon as Reinhard has finished releasing. Do I have to branch each
block (cocoon-forms-impl and
cocoon-forms-sample) individually or is branching their upper
directory (cocoon-forms) enough?
I think branching the upper directoy is the way to go.
Ok, what is the status of the releasing? Will you give e the OK to branch and
commit CForms?
The creation of the release artifacts should be finished by the end of the day.
I will let you know when it's definitly done.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Springifying CForms
Giacomo Pati wrote: BTW: Do we create a branch of cocoon-form-(sample|impl) so that we will have a new version for the sprinigied blocks? As nobody commented on this I'll going to branch cocoon-form before I commit the sprinified CForms, as soon as Reinhard has finished releasing. Do I have to branch each block (cocoon-forms-impl and cocoon-forms-sample) individually or is branching their upper directory (cocoon-forms) enough? I'd guess branching upper directory is enough, with editing of trunk POMs to set versions to the next one. Do you know why we have these extra directories at all instead of flat block directory? Vadim
Re: Springifying CForms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Reinhard Poetz wrote: > >> As nobody commented on this I'll going to branch cocoon-form before I >> commit the sprinified CForms, >> as soon as Reinhard has finished releasing. Do I have to branch each >> block (cocoon-forms-impl and >> cocoon-forms-sample) individually or is branching their upper >> directory (cocoon-forms) enough? > > I think branching the upper directoy is the way to go. Ok, what is the status of the releasing? Will you give e the OK to branch and commit CForms? Thanks and ciao - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.6 (GNU/Linux) iD8DBQFG+6M6LNdJvZjjVZARAtz2AKCszdlbkbpBjE2Ni1biPEaTHtzarwCeKgQt zGOKhuHKiee4AhesuZx9Nys= =BfxR -END PGP SIGNATURE-
Re: Springifying CForms
Giacomo Pati wrote:
Giacomo Pati wrote:
Giacomo Pati wrote:
Hi all
If there is nobody working on the subject I'll spend a few hours on doing that.
I'm done with it :-) but need an advice on a special case:
There are some special 'custom' stuff which had been referenced in form
definitions/bindings by the
mentioned 'class' attribute which is now replaced by a 'ref' attribute and must
be a Spring bean.
Those classes were handled by LifecycleHelper as Avalon Components (which I've
eliminated in that
block). Those custom classes could have implemented the Avalon Configurable
interface to get access
to the XML snippet in the definition/binding file as a Avalon Configuration
object. So how should
that be handled now as they are all managed by Spring?
I have 2 possibilities:
a) check the custom class/bean whether it has a 'setConfiguration' method by
reflection and pass
the DOM snipped to it
b) extend the base interfaces (WidgetValidator, etc) to a ie.
ConfigurableWidgetValidator, etc.)
that has that setConfiguration method to pass the DOM snipped to.
As Felix was the only one giving oppinion about stuff above, I'll implement b)
which leads to 2 new
interfaces ATM to conform semantically to Avalonian CForm version:
My favorite is also b)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Springifying CForms
As nobody commented on this I'll going to branch cocoon-form before I commit
the sprinified CForms,
as soon as Reinhard has finished releasing. Do I have to branch each block
(cocoon-forms-impl and
cocoon-forms-sample) individually or is branching their upper directory
(cocoon-forms) enough?
I think branching the upper directoy is the way to go.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Springifying CForms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Giacomo Pati wrote: > > > Giacomo Pati wrote: >> Hi all > >> If there is nobody working on the subject I'll spend a few hours on doing >> that. > > I'm done with it :-) but need an advice on a special case: > > There are some special 'custom' stuff which had been referenced in form > definitions/bindings by the > mentioned 'class' attribute which is now replaced by a 'ref' attribute and > must be a Spring bean. > Those classes were handled by LifecycleHelper as Avalon Components (which > I've eliminated in that > block). Those custom classes could have implemented the Avalon Configurable > interface to get access > to the XML snippet in the definition/binding file as a Avalon Configuration > object. So how should > that be handled now as they are all managed by Spring? > > I have 2 possibilities: > > a) check the custom class/bean whether it has a 'setConfiguration' method by > reflection and pass >the DOM snipped to it > > b) extend the base interfaces (WidgetValidator, etc) to a ie. > ConfigurableWidgetValidator, etc.) >that has that setConfiguration method to pass the DOM snipped to. As Felix was the only one giving oppinion about stuff above, I'll implement b) which leads to 2 new interfaces ATM to conform semantically to Avalonian CForm version: ConfigurableWidgetListener extends WidgetListener and ConfigurableWidgetValidator extends WidgetValidator each having a method of: void setConfiguration(org.w3c.Element) throws Exception; > So, a) could be said being black magic, and b) could be said being > overdesigned. > > So I'd like you guys give your oppinions so that I can polish that last thing > up and commit. > > BTW: Do we create a branch of cocoon-form-(sample|impl) so that we will have > a new version for the > sprinigied blocks? As nobody commented on this I'll going to branch cocoon-form before I commit the sprinified CForms, as soon as Reinhard has finished releasing. Do I have to branch each block (cocoon-forms-impl and cocoon-forms-sample) individually or is branching their upper directory (cocoon-forms) enough? Ciao - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.6 (GNU/Linux) iD8DBQFG+5+tLNdJvZjjVZARAsIrAKDSAUdNQEal4ZgkxMfM2LS6me7CxACggF2/ wCKMumfazsMP8dozC9qrpiA= =q534 -END PGP SIGNATURE-
Re: ObjectModel exception
Grzegorz Kossakowski wrote: Leszek Gawron pisze: Grzegorz Kossakowski wrote: Leszek Gawron pisze: Because stack implementation used to maintain local scopes uses some variation of ListArray class that uses equals() when remove() method is called. Just for efficiency I guess that real scope could be implemented and need for proper equals() implementation would be eliminated but I think it's minor issue. Most probably because you are having some NativeObjects produced by flow put on OM. That's enough to obtain such effect. Anyway, it is valid to call equals() with object of different class passed as parameter. In such case, equals() should return false before trying to cast. Yeah I know that but why isn't the NativeObject unwrapped for comparison? Because comparison is made by low-level class like ArrayList that is unaware of wrapping objects. Do you want to say that NativeObjects should be unwrapped always whenever they are used in Java code? Seems natural to me. Otherwise anything put into object model from flow would be a native object - would you like to work with these in your java code? This can be done easily in o.a.c.components.flow.FlowHelper.setContextObject() but I must be sure that this will not introduce another problems. -- Leszek Gawron http://www.mobilebox.pl/krs.html CTO at MobileBox Ltd.
Re: [DAISY] CollectionCreated
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
Grzegorz Kossakowski wrote:
[EMAIL PROTECTED] pisze:
The formatting of a nice message for this event hasn't been
implemented yet, so I'll just put an XML dump of the event here.
http://outerx.org/daisy/1.0";>
Isn't site just for servlet-service-fw enough?
AFAICS there is no collection servlet-service-fw. Or do I overlook it?
Yep, there is cdocs-site-servlet-service with ID 31.
My question was more about why do we need separate sites for
cocoon-servlet-service-component and
cocoon-servlet-service-impl? Would not single site for cocoon-servlet-service-*
be enough?
For the project reports (description, javadocs, status, etc.) we already create
seperate docs. But you're probably right that we will put all docs related to
servlet-services in cdocs-site-servlet-service and don't distribute it over
three modules. But I leave it to the doc writer how he wants to organize them.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Springifying CForms
Giacomo Pati schrieb: > I'm done with it :-) Great, I'm looking forward to make my first experiences with it :-) > but need an advice on a special case: > > There are some special 'custom' stuff which had been referenced in form > definitions/bindings by the > mentioned 'class' attribute which is now replaced by a 'ref' attribute and > must be a Spring bean. > Those classes were handled by LifecycleHelper as Avalon Components (which > I've eliminated in that > block). Those custom classes could have implemented the Avalon Configurable > interface to get access > to the XML snippet in the definition/binding file as a Avalon Configuration > object. So how should > that be handled now as they are all managed by Spring? > > I have 2 possibilities: > > a) check the custom class/bean whether it has a 'setConfiguration' method by > reflection and pass >the DOM snipped to it > > b) extend the base interfaces (WidgetValidator, etc) to a ie. > ConfigurableWidgetValidator, etc.) >that has that setConfiguration method to pass the DOM snipped to. > > So, a) could be said being black magic, and b) could be said being > overdesigned. > I'd preferre b) because it's more obvious how to implement your own WidgetValidator when having a look at the JavaDocs Package API. You can see the 2 Interfaces what should make you more sensible about the difference/choice you have to make. With a) it'll be probably 'hidden' somewhere in the documentation and therefore less obvious how to implement your own WidgetValidator. Felix
[continuum] BUILD FAILURE: Apache Cocoon
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=8400&projectId=51 Build statistics: State: Failed Previous State: Failed Started at: Thu 27 Sep 2007 00:02:34 -0700 Finished at: Thu 27 Sep 2007 00:03:09 -0700 Total time: 34s Build Trigger: Schedule Build Number: 24 Exit code: 1 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: Changed: reinhard @ Wed 26 Sep 2007 23:07:21 -0700 Comment: [maven-release-plugin] prepare release cocoon-databases-hsqldb-client-1.0.0-RC2 Files changed: /cocoon/trunk/blocks/cocoon-databases/cocoon-databases-hsqldb-client/pom.xml ( 579899 ) Changed: reinhard @ Wed 26 Sep 2007 23:07:39 -0700 Comment: [maven-release-plugin] prepare for next development iteration Files changed: /cocoon/trunk/blocks/cocoon-databases/cocoon-databases-hsqldb-client/pom.xml ( 579901 ) Changed: reinhard @ Wed 26 Sep 2007 23:12:48 -0700 Comment: snapshot mode Files changed: /cocoon/trunk/blocks/cocoon-databases/cocoon-databases-hsqldb-client/pom.xml ( 579903 ) Changed: reinhard @ Wed 26 Sep 2007 23:16:28 -0700 Comment: [maven-release-plugin] prepare release cocoon-databases-hsqldb-server-1.0.0-RC2 Files changed: /cocoon/trunk/blocks/cocoon-databases/cocoon-databases-hsqldb-server/pom.xml ( 579904 ) Changed: reinhard @ Wed 26 Sep 2007 23:16:41 -0700 Comment: [maven-release-plugin] prepare for next development iteration Files changed: /cocoon/trunk/blocks/cocoon-databases/cocoon-databases-hsqldb-server/pom.xml ( 579906 ) Changed: reinhard @ Wed 26 Sep 2007 23:23:31 -0700 Comment: snapshot mode Files changed: /cocoon/trunk/blocks/cocoon-databases/cocoon-databases-hsqldb-server/pom.xml ( 579908 ) Changed: reinhard @ Wed 26 Sep 2007 23:25:17 -0700 Comment: [maven-release-plugin] prepare release cocoon-databases-mocks-1.0.0-RC2 Files changed: /cocoon/trunk/blocks/cocoon-databases/cocoon-databases-mocks/pom.xml ( 579909 ) Changed: reinhard @ Wed 26 Sep 2007 23:25:33 -0700 Comment: [maven-release-plugin] prepare for next development iteration Files changed: /cocoon/trunk/blocks/cocoon-databases/cocoon-databases-mocks/pom.xml ( 579911 ) Changed: reinhard @ Wed 26 Sep 2007 23:31:50 -0700 Comment: snapshot mode Files changed: /cocoon/trunk/blocks/cocoon-databases/cocoon-databases-mocks/pom.xml ( 579914 ) Changed: reinhard @ Wed 26 Sep 2007 23:34:23 -0700 Comment: [maven-release-plugin] prepare release cocoon-databases-impl-1.0.0-RC2 Files changed: /cocoon/trunk/blocks/cocoon-databases/cocoon-databases-impl/pom.xml ( 579915 ) Changed: reinhard @ Wed 26 Sep 2007 23:34:42 -0700 Comment: [maven-release-plugin] prepare for next development iteration Files changed: /cocoon/trunk/blocks/cocoon-databases/cocoon-databases-impl/pom.xml ( 579917 ) Changed: reinhard @ Wed 26 Sep 2007 23:42:26 -0700 Comment: snapshot mode Files changed: /cocoon/trunk/blocks/cocoon-databases/cocoon-databases-impl/pom.xml ( 579919 ) Dependencies Changes: No dependencies changed Build Defintion: POM filename: pom.xml Goals: clean install Arguments: --batch-mode -P allblocks Build Fresh: false Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Java 1.4, Large Memory Description: Test Summary: Tests: 2307 Failures: 0 Total time: 47661 Output: [INFO] Scanning for projects... Downloading: http://repo1.maven.org/maven2/org/apache/cocoon/cocoon-blocks-modules/5/cocoon-blocks-modules-5.pom [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.cocoon ArtifactId: cocoon-blocks-modules Version: 5 Reason: Unable to download the artifact from any repository org.apache.cocoon:cocoon-blocks-modules:pom:5 from t
