AnsweredAssumed Answered

custom war manifest incompatible with rpm

Question asked by dziggas on Jul 31, 2014
Latest reply on Aug 6, 2015 by jochen

If following the instructions here to create a new project (which really just consists of running the following command):

 

mvn -U jive:create-project


 

Picking version 7.0.2.0, and then building the combined war via:

 

mvn clean package


 

The resulting artifact contains the following manifest content in war/META-INF/MANIFEST.MF

 

Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven
Built-By: me
Build-Jdk: 1.7.0_51


 

This is a problem, because jive-war contains the following:

 


Manifest-Version: 1.0
Implementation-Vendor: Jive Software
Revision:
Implementation-Title: Jive Employee
Implementation-Version: 7.0.2.0_9fd4c00
Built-By: jenkins
Build-Jdk: 1.7.0_51
Created-By: Apache Maven 3.1.1
Archiver-Version: Plexus Archiver


 

If then deploying this war to a node which has previously had jive installed via RPM, we'll see that without some combination of the Revision and Implementation-Version entries in the manifest, the Jive RPM won't start, giving the following error:

 


[root@node1 ju]# su -c 'jive start' - jive
Traceback (most recent call last):
  File "/usr/local/jive/python/bin/jive", line 9, in <module>
    load_entry_point('jive-cli==1.1.4', 'console_scripts', 'jive')()
  File "/usr/local/jive/python/lib/python2.7/site-packages/jive_cli/jive.py", line 88, in main
    parser.add_argument('--version', action='version', version=get_version_string(APPARENT_JIVE_HOME))
  File "/usr/local/jive/python/lib/python2.7/site-packages/jive_cli/jive.py", line 61, in get_version_string
    versions.append('jive_war_manifest={}-{}'.format(vals.get('Implementation-Version').strip(),
AttributeError: 'NoneType' object has no attribute 'strip'


 

I was able to get around this by adding the following to the web pom:

 

<jive.revision>9fd4c00</jive.revision>
<jive.version>7.0.2.0_${jive.revision}</jive.version>


 

and (to the war plugin config)

 

<configuration>
<archive>
<manifestEntries>
<Implementation-Version>${jive.version}</Implementation-Version>
<Revision>${jive.revision}</Revision>
</manifestEntries>
</archive>
</configuration>


 

This worked until we then had to uncomment this line out (because we do need to override some javascript):

 


                    <!-- The execution below should be used when you place anything in /web/src/main/overlay, which
                         includes overrides or widget bean.properties files, or any core Javascript files -->
                    <!-- <execution> -->
                        <!-- <id>repackage-jive-jar</id> -->
                        <!-- <goals><goal>run</goal></goals> -->
                        <!-- <configuration> -->
                            <!-- <skip>false</skip> -->
                        <!-- </configuration> -->
                    <!-- </execution> -->


 

At that point the above changes the maven-war-plugin configuration for the manifest entries were no longer used, and the manifest was a plain manifest again.

 

It seems like the above workaround isn't ideal because it forces all consumers of the parent pom to also do the above, if they use an RPM, and it would be nicer to have the archetype/parent pom config generate a manifest correctly in all cases.

 

Does anybody have a workaround maven config that we can temporarily put into our overlay project that will work when doing the above?

Any idea what it takes to get the parent pom updated to support this automatically (and to remove the need to have children project poms be aware of specific jive.version/jive.revision numbers?

 

Thanks!

Outcomes