Properties replacement (was Re: Connecting 2 blocks with C3.0)

[Thorsten Scherler <sc...@gmail.com>]

Hi Mansour,

we are happy you are so active but please use the dev list for your
questions since c3 is not stable. Meaning by definition we have devs no
user working on c3. Please let us discuss this mail and other on the dev
list. TIA.

On 02/25/2013 05:42 AM, Mansour Al Akeel wrote:
> Francesco,
> I know this is an old thread, but I was trying to update my pom.xml so
> that I get the
>
> <servlet:context mount-path="/mysite"
> context-path="jar:classpath:lib/${project.build.finalName}.jar!/COB-INF/"/>
>
> replaced by maven at build time.
> Now the whole build is failing.
> Is there another way to get this placeholder replaced without using
> the pom included with your project, especially that it has many
> missing dependencies:
>
> [INFO] ------------------------------------------------------------------------
> [INFO] Building contents SNAPSHOT-1.0
> [INFO] ------------------------------------------------------------------------
> [WARNING] The POM for org.springframework:spring-dao:jar:3.1.2.RELEASE
> is missing, no dependency information available
> [WARNING] The POM for commons-jexl:commons-jexl:jar:2.1.1 is missing,
> no dependency information available
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 1.534s
> [INFO] Finished at: Sun Feb 24 23:35:48 GMT 2013
> [INFO] Final Memory: 7M/88M
> [INFO] ------------------------------------------------------------------------

The only thing from the pom you need is something along the lines of:

<build>
    <resources>
      <resource>
        <directory>src/main/resources</directory>
        <filtering>false</filtering>
        <excludes>
          <exclude>META-INF/cocoon/spring/**</exclude>
        </excludes>
      </resource>
      <resource>
        <directory>src/main/resources/META-INF/cocoon/spring</directory>
        <filtering>true</filtering>
        <targetPath>${project.build.outputDirectory}/META-INF/cocoon/spring
        </targetPath>
      </resource>
    </resources>
  </build>

That is doing the filtering and replacing the properties.

However in our latest project we have dropped a bit the configuration of
cocoon in terms of properties from
META-INF/cocoon/properties/xxx.properties and use a central place for
the configuration. This allows to use the project specific properties in
a wide range of modules from a central place.

<build>
    <filters>
      <filter>../src/main/filter/general.properties</filter>
      <filter>../src/main/filter/${env}.properties</filter>
    </filters>
    <resources>
      <resource>
        <directory>src/main/resources</directory>
        <filtering>false</filtering>
        <excludes>
          <exclude>META-INF/cocoon/spring/**</exclude>
          <exclude>META-INF/cocoon/properties/**</exclude>
        </excludes>
      </resource>
      <resource>
        <directory>src/main/resources/META-INF/cocoon/spring</directory>
        <filtering>true</filtering>
       
<targetPath>${project.build.outputDirectory}/META-INF/cocoon/spring</targetPath>
      </resource>
      <resource>
        <directory>src/main/resources/META-INF/cocoon/properties</directory>
        <filtering>true</filtering>
       
<targetPath>${project.build.outputDirectory}/META-INF/cocoon/properties</targetPath>
      </resource>
    </resources>

Here we assume that you have a couple of general properties that may not
change but as well some environment specific properties. Then in our
properties file in cocoon we just use 
common.resources=${common.resources}
extractor.host=${extractor.host}

and the "real" values come from ../src/main/filter/general.properties
and ../src/main/filter/${env}.properties
common.resources=${project.parent.basedir}/api/src/main/resources/COB-INF/resources/
extractor.host=http://localhost:8888/

We may want to look into changing our artifacts to
1) parent provides filter
2) modules uses this filter from parent module

The advantages is that the configuration is taken place in a single
place and can be used in a cross module manner. For us we use the same
properties in c3 and in our droids module.

wdyt?

salu2

-- 
Thorsten Scherler <scherler.at.gmail.com>
codeBusters S.L. - web based systems
<consulting, training and solutions>

http://www.codebusters.es/