cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: Cocoon 2.2 - Build and deployment with Maven2
Date Mon, 05 Dec 2005 06:47:44 GMT
Jorg Heymans wrote:
> 
> 
> Reinhard Poetz wrote:
> 
>>                                       - o -
>>
>> +-------------------------------------------------------------------+
>> |          Build and deployment from a Cocoon user's POV            |
>> +-------------------------------------------------------------------+
> 
> 
>>
>> ROOT
>>  +-- block.xml
>>  +-- pom.xml
>>  +-- src
>>      +-- main
>>      |   +-- java
>>      |       +-- myApp
>>      |           +-- MyJavaFlowController.java
>>      |   +-- webapp
>>      |       +-- sitemap.xmap
>>      |       +-- hello.xml
>>      +-- test
>>
>>
>> Note that this follows the standard M2 project structure which makes 
>> the M2 life much easier as it saves you configuration time (greetings 
>> from RoR).
>>
> yes. Include also src/main/resources , contents here gets automatically 
> added to the classpath as well.
> 
>> The next step is adding your block to Cocoon application server by
>>
>> mvn cocoon:deploy
>>  -Dserver=/home/rpoetz/cocoon2.2
>>  -Dmount-point=/myBlock
>>
> 
> at a later stage we could also provide
> 
> mvn cocoon:deploy
>   -Dserver=/home/rpoetz/cocoon2.2
>   -Dmount-point=/myBlock
>   -DartifactId=myblock
>   -DgroupId=org.apache.cocoon.blocks
>   -Dversion=1.0beta
> 
> which would just fetch the block and install it.
> 
>> This will add an entry to the wiring.xml and will resolve all block 
>> dependencies by putting them into the "<connections>" part.
>>
> 
> I'm assuming it will deploy the block dependencies as well ?

Future versions, yes ;-) The first implementation will show a meaningful error 
that dependencies are missing.

> 
>> For Cocoon 2.2 this will also make sure that all library dependencies 
>> specified in pom.xml are resolved.
> 
> 
> If we hook in to the normal lifecycle then maven will resolve declared 
> library dependencies for us. They should be available from the local 
> repo by the time our deployer kicks in.

yes

we only have to take care that library dependencies are different from block 
dependencies *at deployment*. During development they are equal.

> 
>> Now you can start your Cocoon server and enter 
>> http://[server]/myBlock/hello or
>> http://[server]/myBlock/javaflow-hello
>>
>>
>> If you want to use the block from other blocks you simply have to call
>>
>> mvn install
>>
>> and it is available for other local projects.
>>
> 
> this standard maven goal would jar up the compiled project and put it as 
> is in the local maven repo.

it also has to put in the "block application" (sitemaps, templates, images, ...)

> 
> What do you mean by "use the block from other blocks", from 
> IDE/container/... ?

 From IDE or during build as another block can compile against my block.

> 
> 
>>
>>                                     - o -
>>
>> +-------------------------------------------------------------------+
>> |             Build and deployment :: in depth                      |
>> +-------------------------------------------------------------------+
>>
>>
>> Now let's look a bit deeper into the implementation. A Cocoon block is
>>
>>  1. well, a valid Cocoon block by providing "block.xml"
>>  2. a valid Maven2 artifact
>>  3. a valid JAR file
>>
> 
> IMO 2. and 3. are equivalent, or maybe i don't fully understand what a 
> valid jar file encompasses.

yes, but until last week I believed that there is a different as I had put Java 
binaries into /BLOCK-INF/classes and not directly into the root directory.

> 
>> The jar (packaged block) has following content:
>>
>> ROOT
>>  +-- block.xml
>>  +-- myApp
>>  |   +-- MyJavaFlowController.java
>>  +-- sitemap.xmap
>>  +-- hello.xml
>>  +-- META-INF
>>      +-- maven
>>          +-- ...
>>              +-- pom.properties
>>              +-- pom.xml
>>
> 
> Are you sure we want to include the sources in each block by default?

Sorry, replace "MyJavaFlowController.java" with "MyJavaFlowController.class".

> By 
> "packaged block" i'm assuming you're referring to the artifact that 
> get's deployed to the repository for others to grab.
> 
>> Same should work for creating IDEA and Eclipse project properties 
>> files. For the purpose of RAD, the output directory of the IDE can be 
>> set to the target
>> directory of Maven.
> 
> 
> maven creates idea and eclipse project files out of the box. These mojos 
> are highly configurable so we wouldn't need to do much there.
> 
> http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html

yes
the only  thing I'm not sure about is how to differentiate between binary 
dependencies (one Eclipse project depends on a block as JAR) and project 
dependencies (one Eclipse project depends on a block as another Eclipse 
project). How do I set this?

>> This requires special Maven goal. Thanks to Maven2 it has become very
>> easy to write your own goals (they call them MOJOs). This goal will be 
>> able to deploy a block and
>>
>>  - resolve all JAR dependencies (pom.xml)
>>  - resolve all block dependencies (block.xml)
>>
> again i think if we hook up the deployer to the correct lifecycle phase 
> the jar dependencies will be resolved already. Resolving the block 
> dependencies should be trivial as at this point they are nothing but 
> plain artifacts from a maven point of view.

for building blocks, right but not for the deployment as we can't put all blocks 
into WEB-INF/lib as a block is more than Java binaries (sitemaps, templates, 
...). These additional resources have to be put into /WEB-INF/blocks/myblock/... 
as we can't look them up in JARs. Right Daniel?

> 
>> and copies (and for now unpacks) the block into
>> /cocoon-app/WEB-INF/blocks/myBlock. And, in Cocoon 2.2 it will also 
>> copy all JARs the block depends on into /WEB-INF/lib. The mojo has to 
>> be smart enough to avoid JAR version conflicts. Thanks to the Maven 
>> naming conventions for JARs this should be at least possible. (Note: 
>> OSGi will help us to overcome this
>> problem once and for all).
>>
> yes.
> 
>>
>> And Jorg, if you agree with my ideas, are the proposed changes 
>> difficult to implement?
> 
> 
> 
> Thanks for the summary.
> 
> No I don't think any of this stuff is difficult to implement at all. 
> Have a look at the ArtifactFactory for artifact resolution. maven's jar 
> conflict strategy is pluggable so we should be able to reuse that as well.
> 
> Maybe you could start a block deployer directory in the whiteboard ?

Yes, I will start with the initial code base this week. It's only important for 
me that we get a deployer API that is independant from Maven and can be included 
in other tools (e.g. a future GUI-based deployer). I now that Maven offers a 
high level API to be included in other tools but I have to think more about what 
this means for our deployer.


-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

Mime
View raw message