-105 that I am about to
revert.
With latest cocoon-block-deployment and cocoon-service-impl SNAPSHOTs,
integration tests fail
-
Key: COCOON3-107
URL
actual file system
With latest cocoon-block-deployment and cocoon-service-impl SNAPSHOTs,
integration tests fail
-
Key: COCOON3-107
URL: https
-block-deployment and cocoon-service-impl SNAPSHOTs,
integration tests fail
-
Key: COCOON3-107
URL: https://issues.apache.org/jira/browse/COCOON3-107
Project
;)
With latest cocoon-block-deployment and cocoon-service-impl SNAPSHOTs,
integration tests fail
-
Key: COCOON3-107
URL: https://issues.apache.org/jira
Francesco Chicchiriccò created COCOON3-107:
--
Summary: With latest cocoon-block-deployment and
cocoon-service-impl SNAPSHOTs, integration tests fail
Key: COCOON3-107
URL: https://issues.apache.org/jira
, by upgrading
cocoon-servlet-service-impl to 1.3.2-SNAPSHOT and cocoon-block-deployment to
1.2.2-SNAPSHOT
Basically, since there is no more an installed URLStreamHandlerFactory, every
new URL() should include an instance of BlockContextURLStreamHandler.
This makes every other URL loading (including XSLT
On 08/06/2012 10:41, Francesco Chicchiriccò wrote:
I've created a Cocoon Block Deployment 1.2.1 release, with the
following artifacts up for a vote:
SVN source tag (r1347947):
https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-block-deployment/tags/cocoon-block-deployment-1.2.1
Hi all,
72 hours have almost passed but we still need at least one vote for this
release: anyone willing to check?
Thanks!
Regards.
On 08/06/2012 10:41, Francesco Chicchiriccò wrote:
I've created a Cocoon Block Deployment 1.2.1 release, with the
following artifacts up for a vote:
SVN
2012/6/11 Francesco Chicchiriccò ilgro...@apache.org
Hi all,
72 hours have almost passed but we still need at least one vote for this
release: anyone willing to check?
Thanks!
Regards.
On 08/06/2012 10:41, Francesco Chicchiriccň wrote:
I've created a Cocoon Block Deployment 1.2.1
Hi all,
after 72 hours, the vote for Cocoon Block Deployment 1.2.1 [1] *passes*
with 3 PMC + 0 non-PMC votes.
+1 (PMC / binding)
* Simone Tripodi
* Francesco Chicchiriccò
* Javier Puerto
+1 (non binding)
none
0
none
-1
none
Thanks to everyone participating.
I will now copy this release
[X] +1 approve
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
I've created a Cocoon Block Deployment 1.2.1 release, with the following
artifacts up for a vote:
SVN source tag (r1347947):
https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-block-deployment/tags/cocoon-block-deployment-1.2.1/
List of changes:
https://svn.apache.org/repos/asf/cocoon
Reinhard Pötz pisze:
This majority vote stays open for 72 hours.
Please cast your votes.
Here is my +1 (after successfully testing with Cocoon trunk and Corona).
Argh, sorry for being late but still:
+1
I've discovered some bug that makes SSF not working properly with Cocoon Core 2.2.0.
David Crossley wrote:
Reinhard P?tz wrote:
Currently the proposed artifacts can only be tested either with latest
trunk or Corona.
Actual testing is beyond me.
You can find the staged files for all modules (sources, binaries,
javadocs, checksums, gpg signatures) at
I verified
is necessary because the block deployment functionality
was rewritten and moved into the separate Block-Deployment module.
Apart from this there have been some minor bug fixes and improvements.
Cocoon JNet 1.0.0
~
Cocoon JNet allows the dynamic registration of URLStreamHandler
Please cast your votes.
+1
Felix
Reinhard P?tz wrote:
Currently the proposed artifacts can only be tested either with latest
trunk or Corona.
Actual testing is beyond me.
You can find the staged files for all modules (sources, binaries,
javadocs, checksums, gpg signatures) at
I verified all checksums for *.tar.gz and
still be
used by registering them with JNet.
Cocoon Spring Configurator 2.0.0
A major release is necessary because the block deployment functionality
was rewritten and moved into the separate Block-Deployment module.
Apart from this there have been some minor bug
[ http://issues.apache.org/jira/browse/COCOON-1750?page=all ]
Reinhard Poetz closed COCOON-1750:
--
Resolution: Won't Fix
the deployer will get redesigned so that it works together with an OSGi-based
Cocoon
Make tutorial I (simple block
[ http://issues.apache.org/jira/browse/COCOON-1751?page=all ]
Reinhard Poetz closed COCOON-1751:
--
Resolution: Won't Fix
the deployer will get redesigned so that it works together with an OSGi-based
Cocoon
Make tutorial I (simple block
. Declarative services in OSGi could be the answer.
OK to make it short, I think that the top priority is to have the
block deployment working again. Polymorphism and inheritance
are brilliant ideas, but should not be considered short-term
development.
If we want to release 2.2, we
much
undefined. Declarative services in OSGi could be the answer.
OK to make it short, I think that the top priority is to have the
block deployment working again. Polymorphism and inheritance
are brilliant ideas, but should not be considered short-term
development
like. That's pretty much
undefined. Declarative services in OSGi could be the answer.
OK to make it short, I think that the top priority is to
have the block deployment working again. Polymorphism and
inheritance are brilliant ideas, but should not be considered
short-term
Jean-Baptiste Quenot wrote:
...
Then can you explain the current tasks left to do to have the
blocks framework?
https://issues.apache.org/jira/secure/IssueNavigator.jspa?requestId=12310712
It's not completely up to date. Since we wrote it we have changed from
ECM++ to Spring for Cocoon.
* Daniel Fagerstrom:
These artifact is newer than the latest update of the snapshot
repository, you need to compile and install cocoon-blocks-fw and
cocoon-sitemap in you local repository to get it to work.
And in general you need to get all Cocoon blocks from your
local repository
Jean-Baptiste Quenot wrote:
* Daniel Fagerstrom:
These artifact is newer than the latest update of the snapshot
repository, you need to compile and install cocoon-blocks-fw and
cocoon-sitemap in you local repository to get it to work.
And in general you need to get all Cocoon blocks
* Reinhard Poetz:
uuups, the run.bat is obsolete. I've just removed it.
Move to .\cocoon\trunk\cocoon-block-deployer\cocoon-deployer-plugin-demo and
call
mvn clean cocoon:simple-deploy
from there.
Yet another error:
[ERROR] BUILD ERROR
[INFO]
Jean-Baptiste Quenot wrote:
* Reinhard Poetz:
uuups, the run.bat is obsolete. I've just removed it.
Move to .\cocoon\trunk\cocoon-block-deployer\cocoon-deployer-plugin-demo and
call
mvn clean cocoon:simple-deploy
from there.
Yet another error:
[ERROR] BUILD ERROR
[INFO]
* Reinhard Poetz:
I think David reported the same error. If you build the
_complete_ trunk, org.apache.cocoon:cocoon-deployer-plugin-demo
should have been put into your local repository. Are you sure
that you haven't commented out the module in the parent POM
Jean-Baptiste Quenot wrote:
* Reinhard Poetz:
I think David reported the same error. If you build the
_complete_ trunk, org.apache.cocoon:cocoon-deployer-plugin-demo
should have been put into your local repository. Are you sure
that you haven't commented out the module in the
These artifact is newer than the latest update of the snapshot
repository, you need to compile and install cocoon-blocks-fw and
cocoon-sitemap in you local repository to get it to work.
And in general you need to get all Cocoon blocks from your local
repository as the one from the snapshot
Jean-Baptiste Quenot wrote:
* Reinhard Poetz:
snip/
In the future the plugin will also support a cocoon:deploy
goal that works based on a configuration file which describes
the blocks that should be installed and how they are configured.
Isn't that exactly what we need to automate
* Reinhard Poetz:
Jean-Baptiste Quenot wrote:
* Reinhard Poetz:
In the future the plugin will also support a cocoon:deploy
goal that works based on a configuration file which
describes the blocks that should be installed and how they
are configured.
Isn't that
Make tutorial I (simple block deployment) work - Part I
---
Key: COCOON-1750
URL: http://issues.apache.org/jira/browse/COCOON-1750
Project: Cocoon
Type: Sub-task
Components: - Build System: Maven
Reporter
Make tutorial I (simple block deployment) work - Part II
Key: COCOON-1751
URL: http://issues.apache.org/jira/browse/COCOON-1751
Project: Cocoon
Type: Sub-task
Components: - Build System: Maven
Reporter
Giacomo Pati skrev:
On Fri, 13 Jan 2006, Reinhard Poetz wrote:
Giacomo Pati wrote:
Ok, seems like we need a structured proposal :-)
1. All files needed at deployment time should go into META-INF
- block.xml
- block.xconf
- xconf/*.xconf (includes? do we need more that one
Agree about not using Castor for the blocks framework. On the same time
it would be better to have a common model, but I don't know how to best
achieve that.
Yes, I was also thinking about this. The best (or even better) alternative
istXMLBeans but that's also far from being light-weight. ...
Reinhard Poetz skrev:
Giacomo Pati wrote:
snip/
In Reinhards document it is META-INF/block.xml on the Wiki it's
COB-INF/block.xml. So we need to make a decision:-)
Please use META-INF/block.xml, AFAIK we agreed on making our blocks
valid JAR files.
Ok.
...
Now to answer your question ;)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 13 Jan 2006, Daniel Fagerstrom wrote:
Date: Fri, 13 Jan 2006 11:19:26 +0100
From: Daniel Fagerstrom [EMAIL PROTECTED]
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: Block deployment: working with blocks from a user's
Giacomo Pati wrote:
On Fri, 13 Jan 2006, Daniel Fagerstrom wrote:
Date: Fri, 13 Jan 2006 11:19:26 +0100
From: Daniel Fagerstrom [EMAIL PROTECTED]
...
block.xml contains or point to the block.xconf, so it can be place
anywhere.
I haven't found any formal specification about this pointer
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Agree about not using Castor for the blocks framework. On the same
time it would be better to have a common model, but I don't know how
to best achieve that.
Yes, I was also thinking about this. The best (or even better)
alternative
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Giacomo Pati wrote:
In Reinhards document it is META-INF/block.xml on the Wiki it's
COB-INF/block.xml. So we need to make a decision:-)
Please use META-INF/block.xml, AFAIK we agreed on making our blocks
valid JAR files.
Any zip file with
. internal config file)
- I'm sure there are more
WDYT?
Ciao
Giacomo
On Fri, 13 Jan 2006, Vadim Gritsenko wrote:
Date: Fri, 13 Jan 2006 09:22:06 -0500
From: Vadim Gritsenko [EMAIL PROTECTED]
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: Block deployment: working
Giacomo Pati wrote:
Ok, seems like we need a structured proposal :-)
1. All files needed at deployment time should go into META-INF
- block.xml
- block.xconf
- xconf/*.xconf (includes? do we need more that one .xconf for a
block?)
- block.xlog (if we do have logging support)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 13 Jan 2006, Reinhard Poetz wrote:
Date: Fri, 13 Jan 2006 19:20:43 +0100
From: Reinhard Poetz [EMAIL PROTECTED]
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: Block deployment: working with blocks from a user's point
Giacomo Pati schrieb:
I've missed to place the dependant jars of a block. So I propose they go
to META-INF/lib with no strong agruments for it but they are needed to
setup the classloader for the block or to populate the parent
classloader and that's done at initialization time.
WDYT?
Giacomo Pati schrieb:
I've missed to place the dependant jars of a block. So I propose they
go to META-INF/lib with no strong agruments for it but they are needed
to setup the classloader for the block or to populate the parent
classloader and that's done at initialization time.
WDYT?
IMO
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 13 Jan 2006, Reinhard Poetz wrote:
Date: Fri, 13 Jan 2006 21:56:10 +0100
From: Reinhard Poetz [EMAIL PROTECTED]
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: Block deployment: working with blocks from a user's point
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 11 Jan 2006, Reinhard Poetz wrote:
Date: Wed, 11 Jan 2006 22:47:43 +0100
From: Reinhard Poetz [EMAIL PROTECTED]
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Block deployment: working with blocks from a user's point
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 11 Jan 2006, Reinhard Poetz wrote:
[1] http://cocoon.zones.apache.org/daisy/documentation/g2/796.html
[2] http://cocoon.zones.apache.org/daisy/documentation/g2/797.html
If I want to edit those Daisy docs above I probably need additional
--- Giacomo Pati [EMAIL PROTECTED] schrieb:
[1]
http://cocoon.zones.apache.org/daisy/documentation/g2/796.html
[2]
http://cocoon.zones.apache.org/daisy/documentation/g2/797.html
The above two tutorials seems to be a good start.
Now I think I need to
get in touch with the two below to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 12 Jan 2006, Reinhard Poetz wrote:
Date: Thu, 12 Jan 2006 09:27:43 +0100 (CET)
From: Reinhard Poetz [EMAIL PROTECTED]
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: Block deployment: working with blocks from a user's
Giacomo Pati wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 11 Jan 2006, Reinhard Poetz wrote:
[1] http://cocoon.zones.apache.org/daisy/documentation/g2/796.html
[2] http://cocoon.zones.apache.org/daisy/documentation/g2/797.html
If I want to edit those Daisy docs above I
--- Giacomo Pati [EMAIL PROTECTED] schrieb:
The first thing we need to have is the archetype for
a block skeleton to
get a step ahead through the first tutorial. So
let's define a list of
items we need and requirements one has.
If I understand your tutorials correctly [1] is
about
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 12 Jan 2006, Ross Gardler wrote:
Date: Thu, 12 Jan 2006 09:38:54 +
From: Ross Gardler [EMAIL PROTECTED]
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: Editing Daisy docs. was Block deployment: working with blocks
Btw, what's the best way to edit docs offline? Is there a locking
mechanism or something like that?
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
On 12 Jan 2006, at 13:26, Carsten Ziegeler wrote:
Btw, what's the best way to edit docs offline? Is there a locking
mechanism or something like that?
There's a locking mechanism but not for the purpose of offline editing.
/Steven
--
Steven Noels
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 12 Jan 2006, Reinhard Poetz wrote:
Date: Thu, 12 Jan 2006 10:44:56 +0100 (CET)
From: Reinhard Poetz [EMAIL PROTECTED]
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: Block deployment: working with blocks from a user's
Giacomo Pati wrote:
I'll move the archetypes directory to cocoon-archetypes (to synchronize
it with the naming of the other modules) and integrate them into the
main cocoon/pom.xml (to make it also easily available in IDEs).
I'll create a cocoon-archetype-block in that directory for it.
Ok?
for it.
Ok?
+1
The whiteboard is mainly for personal experiments. There is, IMO, enough
community interest in block deployment to move both the archetype and
the rest of the deployment code to trunk.
/Daniel
Daniel Fagerstrom wrote:
Looks good!
I will restructure the cocoon-blocks-fw projects so that it contains sub
projects, then we can move the Schema files and configuration model
beans, so that we share a common implementation.
yes, good idea.
I will also synchronize the schema files as I
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Looks good!
I will restructure the cocoon-blocks-fw projects so that it contains
sub projects, then we can move the Schema files and configuration
model beans, so that we share a common implementation.
yes, good idea.
I will also
Daniel Fagerstrom wrote:
Agree about not using Castor for the blocks framework. On the same time
it would be better to have a common model, but I don't know how to best
achieve that.
Yes, I was also thinking about this. The best (or even better) alternative
istXMLBeans but that's also far
Giacomo Pati wrote:
My final concern in this will be that Cocoon can be used as a platform
(not just a framework) to host an arbitrary number of independant
applications maintainable by the set of tools we develop/deliver here
for deployment of such application and management of the Cocoon
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 12 Jan 2006, Stefano Mazzocchi wrote:
Date: Thu, 12 Jan 2006 13:12:25 -0500
From: Stefano Mazzocchi [EMAIL PROTECTED]
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: Block deployment: working with blocks from a user's
Daniel Fagerstrom wrote:
The whiteboard is mainly for personal experiments. There is, IMO, enough
community interest in block deployment to move both the archetype and
the rest of the deployment code to trunk.
ok, I will move it to trunk then.
--
Reinhard Pötz Independent
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 12 Jan 2006, Reinhard Poetz wrote:
Date: Thu, 12 Jan 2006 20:01:59 +0100
From: Reinhard Poetz [EMAIL PROTECTED]
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: Block deployment: working with blocks from a user's point
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 12 Jan 2006, Reinhard Poetz wrote:
Date: Thu, 12 Jan 2006 10:44:56 +0100 (CET)
From: Reinhard Poetz [EMAIL PROTECTED]
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: Block deployment: working with blocks from a user's
Giacomo Pati skrev:
...
Where should .xconf file be located so they will be included?
There is a working example of the blocks architecture that runs under
servletunit (and soon under Jetty) at
cocoon-blocks-fw/src/test/resources/org/apache/cocoon/blocks
It is not yet adapted to Reinhards
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 12 Jan 2006, Daniel Fagerstrom wrote:
Date: Thu, 12 Jan 2006 21:44:29 +0100
From: Daniel Fagerstrom [EMAIL PROTECTED]
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: Block deployment: working with blocks from a user's
Giacomo Pati wrote:
snip/
In Reinhards document it is META-INF/block.xml on the Wiki it's
COB-INF/block.xml. So we need to make a decision:-)
Please use META-INF/block.xml, AFAIK we agreed on making our blocks valid JAR
files. The skeleton in my tutorial should be compiled and packaged to
As mentioned in a mail a couple of days ago, I've started to work on the block
deployment mechanism. This forced me to think a lot about how I (and hopefully
others) want to develop Cocoon 2.2 applications.
I wrote two tutorials that guide a developer step by step through the process
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 11 Jan 2006, Reinhard Poetz wrote:
Date: Wed, 11 Jan 2006 22:47:43 +0100
From: Reinhard Poetz [EMAIL PROTECTED]
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Block deployment: working with blocks from a user's point
Giacomo Pati wrote:
Ok, I was wondering when I saw the commit mail what those hard coded
dependencies would be all about in the Mojo. :-)
The Mojo only contains some code to learn how I can use Maven 2 dependency
resolution and download artifacts.
It will use
74 matches
Mail list logo
