Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <430A3A16.8020004@nada.kth.se>
Date: Mon, 22 Aug 2005 22:48:22 +0200
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: svn commit: r234450 - in /cocoon/trunk:
 legal/jakarta-regexp-1.3.jar.license.txt
 legal/jakarta-regexp-1.4.jar.license.txt lib/endorsed/jakarta-regexp-1.3.jar
 lib/endorsed/jakarta-regexp-1.4.jar lib/jars.xml status.xml
References: <20050822075551.32749.qmail@minotaur.apache.org>
 <4309A03C.1080506@nada.kth.se> <430A1538.4020207@gmx.de>
In-Reply-To: <430A1538.4020207@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Joerg Heinicke wrote:
>> Could you please update the Bundle-Classpath (used by OSGi) in 
>> trunk/src/java/Manifest.mf when you update jars in lib/core or 
>> lib/endorsed. I did it for your update, but I might miss updates so it 
>> is good if more people remember it. This is only a temporary 
>> situation, the jars should be separate bundles instead of being 
>> packaged in the Cocoon core bundle, also I didn't felt to write 
>> something more automatic until we have finished changning build system 
>> to Maven2.
> 
> What about generating this file?

We have discussed that, some people would prefer to generate the 
manifest files from block.xml and some other, I for example, prefer to 
have explicit manifest files. There are a number of configuration files 
that we will need that might have some overlap: Manifest.mf, block.xml 
gump.xml and pom.xml. We decided to wait a little bit until we have 
implemented more of the block and sitemap handling stuff in the block 
architecture before we decide.

Also there is some activity in the Oscar project on writing a 
OSGi-plugin for Maven2.

Normally bundle (block) manifest files will not be as complicated as the 
  one for the Cocoon core bundle, which currently is far to monolithic. 
The long term plan is to remove almost all of the jars that currently is 
part of the Cocoon core bundle (most of lib/core and lib/endorsed) and 
package them as bundles. But it will require some work to write (or 
generate) bundle files for all these jars. Hopefully we can work 
together with the maintainers for at least some of these jars so that 
they put a bundle manifest file in the jars, (this should IMO be 
possible for the Excalibur and Commons jars).

The Cocoon core bundle should probably also be split into a number of 
blocks.

OTH, it should be rather easy to generate the Bundle-Classpath during 
the build, so if anyone have feel like it, please go ahead.

/Daniel