You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2006/02/27 16:43:52 UTC
Block deployment
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 webapp build? How many
> Maven plugins are needed? Just this one right?
yes, only that the "cocoon:deploy" goal does nothing ATM.
>>This configuration file is based on an XML schema and can be
>>unmarshalled into a Java object. (I'm using Castor-XML for
>>this.)
>
>
> Isn't it just another pom.xml? Do we really need to write yet
> another XML schema?
pom.xml describes *Java* *implementation* dependencies. But blocks will have a
polymorphic behaviour. This means that a block doesn't depend on a
implementation but on a contract. pom.xml (Maven 2) doesn't fit this requirement.
A block can depend on other blocks (polymorphic) and on components provided by
other blocks (Java interfaces).
How this can be achieved isn't carved in stone yet. That's the reason why I
stopped my work on the deployer until the contracts become clearer (hopefully soon).
>>Writing some Eclipse plugin in order to get a visual
>>interface, shouldn't be too difficult as it can collect the
>>same information as the content of XML file would be. Of
>>course the Eclipse plugin can directly call the API of the
>>deployer-core. For now I've stopped development as I have to
>>completly understand what the contract of blocks will be. As
>>soon as I know this, I will finish the deployer-core.
>
> What is the advantage of calling the API directly? We need a
> persistent storage to keep the blocks selection anyway.
yes, right
>>If you need/want to know more, just let me know! I don't know if
>>you have Eclipse plugin-development experience, but setting up a
>>project that does a simple deploy would be very helpful.
>
> Designing this plugin should be feasible, I think we could reuse
> part of [1]Lepido that helps to handle XML documents in an Eclipse
> plugin.
ok
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Block deployment
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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. This change is not yet done for the blocks
fw, which still use ECM++.
I have not yet thought out the details about how to switch the blocks fw
to Spring.
For more general background about component handling in blocks you can
take a look at:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113813135727508&w=2
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113916800307367&w=2
And a somewhat older overview about the blocks implementation:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113335919919804&w=2
/Daniel
Re: Block deployment
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* Reinhard Poetz:
> Jean-Baptiste Quenot wrote:
>
> >* Reinhard Poetz:
> >
> >>Jean-Baptiste Quenot wrote:
> >>
> >>
> >>>And I have a more general question: what concrete usecase and
> >>>existing blocks have motivated the design and development of
> >>>the wiring feature? Do we have several blocks implementing
> >>>the same interface?
> >>
> >>see http://wiki.apache.org/cocoon/BlockIntroduction, which was
> >>the originally written by Stefano looooong time ago.
> >>
> >>The wiki documents mainly deal with what we call
> >>"sitemap blocks". The last missing piece is how component
> >>dependencies will finally look 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 development.
>
> it was implemented by Daniel about one year ago.
Then can you explain the current tasks left to do to have the
blocks framework?
> >If we want to release 2.2, we must delay the development of
> >polymorphism and inheritance. What is missing to have this
> >block deployer working, without wiring concerns (hardcoded
> >wiring against cocoon-core)?
>
> I'm working on the deployer again and will give a status report
> very soon (sunday or monday).
OK, thanks a lot.
--
Jean-Baptiste Quenot
http://caraldi.com/jbq/
Re: Block deployment
Posted by Reinhard Poetz <re...@apache.org>.
Jean-Baptiste Quenot wrote:
> * Reinhard Poetz:
>
>
>>Jean-Baptiste Quenot wrote:
>>
>>
>>>And I have a more general question: what concrete usecase and
>>>existing blocks have motivated the design and development of
>>>the wiring feature? Do we have several blocks implementing
>>>the same interface?
>>
>>see http://wiki.apache.org/cocoon/BlockIntroduction, which was
>>the originally written by Stefano looooong time ago.
>>
>>The wiki documents mainly deal with what we call
>>"sitemap blocks". The last missing piece is how component
>>dependencies will finally look 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
> development.
it was implemented by Daniel about one year ago.
> If we want to release 2.2, we must delay the development of
> polymorphism and inheritance.
>
> What is missing to have this block deployer working, without
> wiring concerns (hardcoded wiring against cocoon-core)?
I'm working on the deployer again and will give a status report very soon
(sunday or monday).
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Block deployment
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* Reinhard Poetz:
> Jean-Baptiste Quenot wrote:
>
> > And I have a more general question: what concrete usecase and
> > existing blocks have motivated the design and development of
> > the wiring feature? Do we have several blocks implementing
> > the same interface?
>
> see http://wiki.apache.org/cocoon/BlockIntroduction, which was
> the originally written by Stefano looooong time ago.
>
> The wiki documents mainly deal with what we call
> "sitemap blocks". The last missing piece is how component
> dependencies will finally look 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
development.
If we want to release 2.2, we must delay the development of
polymorphism and inheritance.
What is missing to have this block deployer working, without
wiring concerns (hardcoded wiring against cocoon-core)?
--
Jean-Baptiste Quenot
http://caraldi.com/jbq/
Re: Block deployment
Posted by Reinhard Poetz <re...@apache.org>.
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 from your
>>local repository as the one from the snapshot repository are
>>obsolete. Do a
>>
>>$ mvn -Dmaven.test.skip=true clean install from cocoon-trunk.
>
>
> OK thanks.
>
> Now the mvn clean cocoon:simple-deploy in
> cocoon-block-deployer/cocoon-deployer-plugin-demo works.
>
> I'm wondering why installing library is so slow, like one second
> for each of these lines:
>
> [INFO] Installing library WEB-INF/lib/commons-jci-r306555.jar
Because transactional file acces of the commons-transaction project is used. I
plan to make this configureable (http://issues.apache.org/jira/browse/COCOON-1773)
> And BTW I read the tutorials about Cocoon block deployer, maybe it
> would be worth adding a TODO list to be sure what feature is
> available. For example, 795.html states that one of the Primary
> features is to define which blocks are installed. But is it
> really the case?
sorry, the sentence was misleading. I changed it to "define which blocks are to
be installed" or IOW, which blocks to you want to install.
> And I have a more general question: what concrete usecase and
> existing blocks have motivated the design and development of the
> wiring feature? Do we have several blocks implementing the same
> interface?
see http://wiki.apache.org/cocoon/BlockIntroduction, which was the originally
written by Stefano looooong time ago.
The wiki documents mainly deal with what we call "sitemap blocks". The last
missing piece is how component dependencies will finally look like. That's
pretty much undefined. Declarative services in OSGi could be the answer.
> I could imagine that if we had an eXist block, one
> would choose between eXist and Xindice, both implementing the same
> contract... could you please give an example?
If the link above and my (short) explanation is not enough, feel free to ask :-)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Block deployment
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* 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 as the one from the snapshot repository are
> obsolete. Do a
>
> $ mvn -Dmaven.test.skip=true clean install from cocoon-trunk.
OK thanks.
Now the mvn clean cocoon:simple-deploy in
cocoon-block-deployer/cocoon-deployer-plugin-demo works.
I'm wondering why installing library is so slow, like one second
for each of these lines:
[INFO] Installing library WEB-INF/lib/commons-jci-r306555.jar
And BTW I read the tutorials about Cocoon block deployer, maybe it
would be worth adding a TODO list to be sure what feature is
available. For example, 795.html states that one of the Primary
features is to define which blocks are installed. But is it
really the case?
And I have a more general question: what concrete usecase and
existing blocks have motivated the design and development of the
wiring feature? Do we have several blocks implementing the same
interface? I could imagine that if we had an eXist block, one
would choose between eXist and Xindice, both implementing the same
contract... could you please give an example?
Maybe you can point me to relevant cocoon-dev archives?
TIA,
--
Jean-Baptiste Quenot
http://caraldi.com/jbq/
Re: Block deployment
Posted by Reinhard Poetz <re...@apache.org>.
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 parent POM
>>(./cocoon/trunk/pom.xml)?
>
>
> After issuing « svn revert pom.xml » I issue a « mvn clean
> war:inplace » and get another error trying to build full trunk:
>
> [INFO] ----------------------------------------------------------------------------
> [INFO] Building cocoon-default
> [INFO] task-segment: [war:inplace]
> [INFO] ----------------------------------------------------------------------------
> [INFO] ----------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO] ----------------------------------------------------------------------------
> [INFO] Failed to resolve artifact.
>
> required artifacts missing:
> org.apache.cocoon:cocoon-sitemap-impl:jar:1.0-SNAPSHOT
> org.apache.cocoon:cocoon-blocks-fw-servlet-impl:jar:1.0-SNAPSHOT
> org.apache.cocoon:cocoon-blocks-fw-ecm-impl:jar:1.0-SNAPSHOT
>
> for the artifact:
> org.apache.cocoon:cocoon-default:jar:1.0-SNAPSHOT
>
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
Have you called
mvn clean install -Dmaven.test.skip=true
from
./cocoon/trunk
?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Block deployment
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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 repository are obsolete. Do a
$ mvn -Dmaven.test.skip=true clean install from cocoon-trunk.
/Daniel
Jean-Baptiste Quenot skrev:
> * 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
>> (./cocoon/trunk/pom.xml)?
>
> After issuing « svn revert pom.xml » I issue a « mvn clean
> war:inplace » and get another error trying to build full trunk:
>
> [INFO] ----------------------------------------------------------------------------
> [INFO] Building cocoon-default
> [INFO] task-segment: [war:inplace]
> [INFO] ----------------------------------------------------------------------------
> [INFO] ----------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO] ----------------------------------------------------------------------------
> [INFO] Failed to resolve artifact.
>
> required artifacts missing:
> org.apache.cocoon:cocoon-sitemap-impl:jar:1.0-SNAPSHOT
> org.apache.cocoon:cocoon-blocks-fw-servlet-impl:jar:1.0-SNAPSHOT
> org.apache.cocoon:cocoon-blocks-fw-ecm-impl:jar:1.0-SNAPSHOT
>
> for the artifact:
> org.apache.cocoon:cocoon-default:jar:1.0-SNAPSHOT
>
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
Re: Block deployment
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* 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
> (./cocoon/trunk/pom.xml)?
After issuing « svn revert pom.xml » I issue a « mvn clean
war:inplace » and get another error trying to build full trunk:
[INFO] ----------------------------------------------------------------------------
[INFO] Building cocoon-default
[INFO] task-segment: [war:inplace]
[INFO] ----------------------------------------------------------------------------
[INFO] ----------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ----------------------------------------------------------------------------
[INFO] Failed to resolve artifact.
required artifacts missing:
org.apache.cocoon:cocoon-sitemap-impl:jar:1.0-SNAPSHOT
org.apache.cocoon:cocoon-blocks-fw-servlet-impl:jar:1.0-SNAPSHOT
org.apache.cocoon:cocoon-blocks-fw-ecm-impl:jar:1.0-SNAPSHOT
for the artifact:
org.apache.cocoon:cocoon-default:jar:1.0-SNAPSHOT
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
--
Jean-Baptiste Quenot
http://caraldi.com/jbq/
Re: Block deployment
Posted by Reinhard Poetz <re...@apache.org>.
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] ----------------------------------------------------------------------------
> [INFO] Failed to resolve artifact.
>
> required artifacts missing:
> org.apache.cocoon:cocoon-default:jar:1.0-SNAPSHOT
>
> for the artifact:
> org.apache.cocoon:cocoon-deployer-plugin-demo:jar:1.0-SNAPSHOT
>
> from the specified remote repositories:
> apache-maven2 (http://cvs.apache.org/maven-snapshot-repository),
> central (http://repo1.maven.org/maven2),
> maven-snapshot (http://snapshots.maven.codehaus.org/maven2/),
> apache-cvs (http://cvs.apache.org/repository)
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 (./cocoon/trunk/pom.xml)?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Block deployment
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* 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] ----------------------------------------------------------------------------
[INFO] Failed to resolve artifact.
required artifacts missing:
org.apache.cocoon:cocoon-default:jar:1.0-SNAPSHOT
for the artifact:
org.apache.cocoon:cocoon-deployer-plugin-demo:jar:1.0-SNAPSHOT
from the specified remote repositories:
apache-maven2 (http://cvs.apache.org/maven-snapshot-repository),
central (http://repo1.maven.org/maven2),
maven-snapshot (http://snapshots.maven.codehaus.org/maven2/),
apache-cvs (http://cvs.apache.org/repository)
--
Jean-Baptiste Quenot
http://caraldi.com/jbq/
Re: Block deployment
Posted by Reinhard Poetz <re...@apache.org>.
Jean-Baptiste Quenot wrote:
> * 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 exactly what we need to automate webapp build? How
>>>many Maven plugins are needed? Just this one right?
>>
>>yes, only that the "cocoon:deploy" goal does nothing ATM.
>
>
> When do you think it will be ready? Is it possible to help?
>
> I'm having an error with
> cocoon-block-deployer/cocoon-deployer-plugin/run.bat. To try and
> solve it I make the following replacement:
>
> Index: run.bat
> ===================================================================
> --- run.bat (revision 381303)
> +++ run.bat (working copy)
> @@ -1 +1 @@
> -mvn -X -e org.apache.cocoon:cocoon-block-deployer-plugin:1.0-SNAPSHOT:simple-deploy1
> \ No newline at end of file
> +mvn -X -e org.apache.cocoon:cocoon-deployer-plugin:1.0-SNAPSHOT:simple-deploy1
>
> I get another error:
>
> [ERROR] BUILD FAILURE
> [INFO] ----------------------------------------------------------------------------
> [INFO] Required goal not found: org.apache.cocoon:cocoon-deployer-plugin:1.0-SNAPSHOT:simple-deploy1
>
> Where is defined « simple-deploy1 »?
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.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Block deployment
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* 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 exactly what we need to automate webapp build? How
> > many Maven plugins are needed? Just this one right?
>
> yes, only that the "cocoon:deploy" goal does nothing ATM.
When do you think it will be ready? Is it possible to help?
I'm having an error with
cocoon-block-deployer/cocoon-deployer-plugin/run.bat. To try and
solve it I make the following replacement:
Index: run.bat
===================================================================
--- run.bat (revision 381303)
+++ run.bat (working copy)
@@ -1 +1 @@
-mvn -X -e org.apache.cocoon:cocoon-block-deployer-plugin:1.0-SNAPSHOT:simple-deploy1
\ No newline at end of file
+mvn -X -e org.apache.cocoon:cocoon-deployer-plugin:1.0-SNAPSHOT:simple-deploy1
I get another error:
[ERROR] BUILD FAILURE
[INFO] ----------------------------------------------------------------------------
[INFO] Required goal not found: org.apache.cocoon:cocoon-deployer-plugin:1.0-SNAPSHOT:simple-deploy1
Where is defined « simple-deploy1 »?
--
Jean-Baptiste Quenot
http://caraldi.com/jbq/