Mailing-List: contact felix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: felix-dev@incubator.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <45C257A2.9030204@verticon.com>
Date: Thu, 01 Feb 2007 15:12:02 -0600
From: "John E. Conlon" <jconlon@verticon.com>
Reply-To: jconlon@verticon.com
Organization: Verticon, Inc.
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: felix-dev@incubator.apache.org
Subject: Re: Improving integration between maven and osgi
References: <1a5b6c410701310942l75915d06w4565da217a6edc1a@mail.gmail.com>
	 <45C0F596.8040608@ungoverned.org>
	 <1a5b6c410701311213k5e1176dfjb7db6287c0113a4c@mail.gmail.com>
	 <1907901706.20070201090640@aQute.biz>
 <1a5b6c410702011127q19f240a0x3e56a0a65bef35e5@mail.gmail.com>
In-Reply-To: <1a5b6c410702011127q19f240a0x3e56a0a65bef35e5@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi Carlos,

So you will label a bundles exports with the version of the jar and 
label the bundles import versions with the versions of the dep jars?

John

Carlos Sanchez wrote:
> A very important step that is not there yet is the version in the
> import-packages, it's very different to depend on commons-logging 1.0
> than 1.1
> It'd be easier to do it with Require-Bundle but as everybody seems to
> agree in using Import-Packages I'll try to generate them finding what
> Maven dependency provides that package and then get the version.
>
> On 2/1/07, Peter Kriens <Peter.Kriens@aqute.biz> wrote:
>> CS> afaik the current status of the bundle plugin doesn't read pom
>> CS> dependencies to generate the import-packages but the imports in the
>> CS> classes. The only thing used from the pom if not explicitly 
>> configured
>> CS> is the Maven generated classpath, am I wrong?
>> The plugin uses the classpath as defined by the POM file. From this
>> classpath, you can define what you want to include (Private-Package
>> and Export-Package). This contained set of classes is then parsed for
>> references. References that can not be found in the Private/Export set
>> are then turned in imports.
>>
>> This model significantly reduces the dependencies.
>>
>> Kind regards,
>>
>>      Peter Kriens
>>
>>
>> CS> On 1/31/07, Richard S. Hall <heavy@ungoverned.org> wrote:
>> >> Carlos Sanchez wrote:
>> >> > Hi all,
>> >> >
>> >> > I'm trying to make maven generate OSGi bundles based in the 
>> information
>> >> > of the pom as much as possible. That implies generating 
>> "Require-bundle"
>> >> > headers based on the dependencies section of the pom instead of
>> >> > autodiscovered "Import-packages".
>> >> >
>> >> > I'd take groupId.artifactId as bundle name and dependency 
>> version as
>> >> > bundle version.
>> >> >
>> >> > In the future this could be the standard for any jar generated 
>> by Maven.
>> >> >
>> >> > It will assume that dependencies are already available as OSGi 
>> bundles,
>> >> > although I'm working on a recursive mode that will generate
>> >> > one bundle for each dependency scanning the whole tree of 
>> transitive
>> >> > dependencies.
>> >> >
>> >> > Please let me know if this sounds right for the 
>> maven-bundle-plugin.
>> >> > Any comments appreciated ;)
>> >>
>> >> I'm of two minds on this...
>> >>
>> >>    1. I think that use of require-bundle should be discouraged as a
>> >>       general mechanism, since it creates brittle systems and has odd
>> >>       side effects.
>>
>> CS> the reason i heard to discourage require-bundle was that only 
>> specific
>> CS> packages of a bundle may be needed. Maven encourages splitting big
>> CS> projects into reusable components so you usually end with few 
>> packages
>> CS> in each bundle, being pretty close to the import-packages is.
>>
>> >>    2. I admit that if we want to support require-bundle at all,
>> >>       maven-bundle-plugin is probably the place to put it.
>> >>
>> >> In general, I do not have a goal to get OSGi bundle developers
>> >> integrating more tightly with Maven, since Maven's dependency 
>> model is
>> >> not as sophisticated as OSGi's. I prefer to find ways to make it 
>> easier
>> >> to follow OSGi best practices, than Maven best practices.
>>
>> CS> the point is to compliment both by easily generating OSGi bundles 
>> from
>> CS> any Maven project.
>>
>> >>
>> >> Ultimately, except for split packages, you can mimic require-bundle
>> >> fairly nicely with the existing plugin by exporting all project 
>> packages
>> >> and importing everything else, which is essentially what Peter was
>> >> trying to work with Jason van Zyl on previously. This can be done to
>> >> achieve a similar level of integration with Maven as proposed without
>> >> any additional information other than what is in the pom too. So,
>> >> explicit support for require-bundle may not really be necessary.
>>
>> CS> afaik the current status of the bundle plugin doesn't read pom
>> CS> dependencies to generate the import-packages but the imports in the
>> CS> classes. The only thing used from the pom if not explicitly 
>> configured
>> CS> is the Maven generated classpath, am I wrong?
>>
>> >>
>> >> -> richard
>> >>
>>
>>
>>
>>
>> -- 
>> Peter Kriens                              Tel +33467542167
>> 9C, Avenue St. Dr�z�ry                    AOL,Yahoo: pkriens
>> 34160 Beaulieu, France                    ICQ 255570717
>> Skype pkriens                             Fax +1 8153772599
>>
>>
>
>