Description of problem:
Consider a system on which the following application RPMs are installed:
Now consider, setting up a server instances containing two applications:
<ccm:application name="myapp" prettyName="myapp" buildOrder="1"/>
<ccm:application name="ccm-cms" version="6.1.0" buildOrder="1"/>
<ccm:application name="ccm-core" version="6.1.0" buildOrder="1"/>
If you then run 'ccm load' for example, it has all the JARs for all
installed applications in the CLASSPATH, even though only two of them
are actually configured in this server.
This is because ccm.classpath globs everything in /usr/share/java
rather than just the bits it needs.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Classpath contains JARs for all installed applications
Classpath contains JARs only for applications in the server instance.
This will cause particular problems if /usr/share/java contains
multiple versions of the same application / 3rd party JAR.
This caused peculiar errors when diagnosing bug 110923
In my local checkout I have build-template.xsl and
classpath-template.xsl modified so that instead of including
/usr/share/java, they include /usr/share/java/<required jar>. For
example, ccm-core has
The list of required jars comes from the ccm:requires tags in
application.xml. Note that this isn't perfect because there is no
ccm-tools.jar. Still, it's probably a better approach than what we
Also, this doesn't address deployment installs or prebuilt
applications. However, we can fix those two scenarios by including
application.xml with the RPM and using it in the %post script for
/etc/ccm/ccm.classpath and by
Dan, what do you think?
Ok, so we've got a domain mismatch in the uses of ccm:dependancies
here really. Originally I intended it to just list build time
dependancies on other CCM applications. We've expanded this to include
dependancies on 3rd RPMs such as junit, httpunit, etc. We're now
trying to extend that still further by assuming that the package name
corresponds to a JAR name & thus adding JARs to the classpath. If we
use it to generate /etc/ccm/ccm.classpath, this will also be extending
it further to list run time dependancies.
As far as I'm aware, we don't need anything form /usr/share/java
included in the classpath for a runtime production system. All the
depenadant libs are already in /usr/share/java/ccm-core/*.jar
So we've got the scenarios:
* Generate the ant build order 'depends' attribute on <target>
* Development build time 3rd party jars junit, httpunit, servletapi,
* RPM dependancies on CCM apps
To resolve this, I think its time to start using the
ccm:buildRequires tag in addition to ccm:requires. buildRequires would
list any 3rd party JARs required. requires would list deps on CCM
applications only. So for CMS, for example,
<ccm:requires name="ccm-core" version="6.1.0" relation="ge"/>
<ccm:buildRequires name="httpunit" version="1.5.1" relation="ge"/>
<ccm:buildRequires name="junit" version="3.8" relation="ge"/>
<ccm:buildRequires name="servlet" version="2.3" relation="ge"/>
Does the ccm-tools line really need to be here, or can we put it
straight into the rpm.spec.in template file instead ?
> As far as I'm aware, we don't need anything form /usr/share/java
> included in the classpath for a runtime production system. All the
> depenadant libs are already in /usr/share/java/ccm-core/*.jar
We do depend on servlet.jar when not running inside of a servlet
container (e.g. ccm load). Also, we depend on classes12.jar. For the
latter, our scripts attempt to automatically add it to the CLASSPATH.
We could do the same for servlet.jar. However, I wonder if there
will be more cases that need special treatment like this.
> To resolve this, I think its time to start using the
> ccm:buildRequires tag in addition to ccm:requires. buildRequires
> would list any 3rd party JARs required.
I like this idea. Just to be clear: these items would be added to the
RPM spec as BuildRequires lines, right?
> requires would list deps on CCM applications only.
Again, I am concerned about runtime dependencies on 3rd party
libraries that are not included in the application, such as
servlet.jar and classes12.jar. In fact, one scenario that intrigues
me is where we removed all of the jars from //core-platform/dev/lib
and make them into build/runtime requirements of core. However, I
think you are right that for now let's keep it simple and only list
CCM apps with the requires tag.
> Does the ccm-tools line really need to be here, or can we put it
> straight into the rpm.spec.in template file instead ?
makes sense to move it to rpm.spec.in
*** Bug 112981 has been marked as a duplicate of this bug. ***
changes checked in @39259