Mailing-List: contact felix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: felix-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of Jeff_McAffer@ca.ibm.com
 designates 32.97.182.141 as permitted sender)
In-Reply-To: <200602242306.59396.marrs@xs4all.nl>
To: felix-dev@incubator.apache.org
MIME-Version: 1.0
Subject: Re: Issues with installing bundles by reference
From: Jeff McAffer <Jeff_McAffer@ca.ibm.com>
Message-ID: 
 <OFF6D0542E.1D0B87AC-ON8525711F.007D401F-8525711F.007F2441@ca.ibm.com>
Date: Fri, 24 Feb 2006 18:08:48 -0500
Content-Type: multipart/alternative;
 boundary="=_alternative 007EB25A8525711F_="

--=_alternative 007EB25A8525711F_=
Content-Type: text/plain; charset="US-ASCII"

Marcel Offermans <marrs@xs4all.nl> wrote on 02/24/2006 05:06:59 PM:
> The first scenario I thought of was when developing and deploying 
bundles, 
> being able to actually have bundles that reference a directory structure 

> would eliminate the need to (re)build bundle jars (and after triggering 
an 
> update in the framework, having that framework extract them again). This 

> scenario seems to be used in J2EE appservers too (for .war and .ear 
files).

Certainly this is an important one however it actually requires more than 
just install by reference.  For example, if you have some project 
(whatever) of source and you build it and want to install the result by 
reference as a bundle, the result has to be in the shape the bundle 
describes.  In particular, the Bundle-Classpath has to correctly identify 
the location of hte classes and resources.  Since the common case is to 
have a classpath of . then it means that the package dirs for the classes 
have to be directly in the parent of the MANIFEST.MF file or you have to 
implement a mechanism that allows you to map the classpath elements to 
build locations.  The latter is what we do in Eclipse to enable PDE's 
direct launching of plugins/projects.  This allows people to structure 
their output locations however they want and still just write code, save 
and launch.  No explicit compile or build steps needed.

> What other scenario's did you have in mind (if any)?

The other main usecase we have for by-reference is scaleablity.  If your 
system is actually installed on disk (as opposed to downloaded 
dynamically) then installing bundles by value duplicates the storage 
required.  Further, if you have the same disk-based bundle in multiple 
configurations/profiles, you would have to have one copy for each.  The 
approach we have taken is to allow for pools of bundles to be placed on 
disk and then define configurations that identify the plugins from that 
pool that should be run together.  No duplication, no copying, ...  Since 
some of the systems built on Eclipse are >1GB, this is an obvious win.

Jeff
--=_alternative 007EB25A8525711F_=--