cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [2.2] Runtime deployment
Date Sun, 05 Nov 2006 10:44:55 GMT
Jorg Heymans skrev:
> Daniel Fagerstrom wrote:
>> We could use the artifactId from the 
>> META-INF/maven/org.apache.cocoon/cocoon-block-name/ file.
> is included by default, but it's inclusion can be 
> disabled. For this I think the manifest entry would be a better option 
> here.


>> Maven also sometimes (?) creates some field in the manifest file that 
>> could be used e.g.:
>> Manifest-Version: 1.0
>> Archiver-Version: Plexus Archiver
>> Created-By: Apache Maven
>> Built-By: maven
>> Build-Jdk: 1.4.2_06
>> Extension-Name: cocoon-batik-impl
>> Specification-Title:
>> Specification-Vendor: The Apache Software Foundation
>> Implementation-Vendor: The Apache Software Foundation
>> Implementation-Title: cocoon-batik-impl
>> Implementation-Version: 1.0.0-SNAPSHOT
>> I doesn't create such manifest files all the time though. The jars 
>> created when I compile locally with Maven 2.0.4 looks like:
>> Manifest-Version: 1.0
>> Archiver-Version: Plexus Archiver
>> Created-By: Apache Maven
>> Built-By: Daniel Fagerstrom
>> Build-Jdk: 1.5.0_06
> The generated default manifest is different for artifacts produced using 
> mvn deploy/release versus those produced using mvn install.


>> One possibility would to have a block specific manifest entry with the 
>> block name:
>> Cocoon-Block-Name: cocoon-batik-impl
> Yup, just include this in the root pom:
> <plugin>
>   <groupId>org.apache.maven.plugins</groupId>
>   <artifactId>maven-jar-plugin</artifactId>
>   <version>2.1</version>
>   <configuration>
>     <archive>
>       <manifestEntries>
>         <Cocoon-Block-Name>${pom.artifactId}</Cocoon-Block-Name>
>       </manifestEntries>
>     </archive>
>   </configuration>
> </plugin>

So, the conclusion this far is that we cannot use jar file name or 
information that Maven happen to generate anyway for getting the block 
name. We have to add the block name ourselves i some way.

Having the block name in the manifest is convenient as it is easy to 
read from jars and it is fairly easy to set up in a POM as Jorg showed.

A possible drawback is that Maven generated manifest info might be hsrd 
to use during development in a IDE. Especially for Eclipse it might be a 
problem to use the manifest file as Eclipse AFAIU requires the manifest 
to be in the root of the project.

Another solution that is somewhat less convenient but might work better 
with IDEs, would be to put the block name in a block property file, 
COB-INF/ e.g.


View raw message