Mailing-List: contact felix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: felix-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Date: Fri, 10 Nov 2006 08:11:04 +0100
From: Peter Kriens <Peter.Kriens@aQute.biz>
Organization: aQute
Message-ID: <1408083014.20061110081104@aQute.biz>
To: "Tim Moloney (JIRA)" <jira@apache.org>
CC: felix-dev@incubator.apache.org
Subject: Re: [jira] Commented: (FELIX-171) Document process of creating
 bundles using bnd
In-Reply-To: <11361060.1163080837676.JavaMail.jira@brutus>
References: <7347096.1163079397003.JavaMail.jira@brutus>
 <11361060.1163080837676.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

I see you create the transitive dependencies for maven but use
import/export package for OSGi. I thought it would be sufficient to
treat bundles as stand alone units? OBR can resolve the package
dependencies in run time from a repository.

Maintaining the transitive dependencies looks like a horrendous
maintenance job. It means that if a downstream version changes, all the
requirees must be changed.

Another issue is optional dependencies. Many libraries are written
that have a lot of optional dependencies. Bnd is a point in case. It
requires Ant when it is used in the Ant context but it when it runs in
Eclipse it should not require ant. These imports should be ignored or
at least be optional. This implies that not all dependencies should be
mandated.

Note that a very important feature of the framework is that "your
installed bundles are your configuration". The set of installed
bundles is something you can play with. You want logging? Installer a
logging bundle, but things should still work without. This flexibility
is very much at odds with the hard transitive dependency model from
maven.

I do not claim I have all the answers, but personally I would lean to
not make the bundles transitively depend on other bundles, I think
that model is too static for OSGi.

If that is the case, you could use bnd in build mode with only the
specific bundle on the class path. The bnd file can contain the
classpath (-classpath: LIST). Exporting all and importing all then
does the trick, the bnd file can then set all the details like
version, description. If you want to, I can support URLs for the
-classpath which means you could directly load them from the net.

I have written a small deploy tool for an ftp server, it would be easy
to add an file server so you could deploy them to the maven repo
without the support from maven. The conversion would then only consist
of a bunch of bnd files, you could then daily do:

   bnd build *.bnd
   deploy -r file:~/.m2/repository *.jar

The deploy automatically makes the POM file from the manifest
information.

Anyway, most important decision is how to handle the transitive
dependencies. Very curious about your, Richard's and other opinions.
This is a pretty import decision.

Kind regards,

     Peter kriens
   

TMJ>     [
TMJ> http://issues.apache.org/jira/browse/FELIX-171?page=comments#action_12448473 ]
TMJ>             
TMJ> Tim Moloney commented on FELIX-171:
TMJ> -----------------------------------

TMJ> 1. Use bnd to analyze the library jar (e.g., java -jar
TMJ> bnd-0.0.jar print path/to/FOO.jar)
TMJ> 2. At the bottom of the bnd output, look for "Unresolved
TMJ> references to ..." which identify package dependencies.  If found,
TMJ>   a. Identifiy the library jars that provide the missing packages
TMJ>   b. Recursively use this process on each dependency
TMJ> 3. Create a directory that will be the project directory for the bundle (e.g., mkdir FOO-osgi)
TMJ> 4. Copy the template pom.xml file to the bundle's project directory
TMJ> 5. Edit the pom.xml file to tailor it for the library jar.  Specifically,
TMJ>   a. change artifactId
TMJ>   b. verify description
TMJ>   c. change version
TMJ>   d. change FOO's library jar dependency (groupId, artifactId)
TMJ>   e. add any other dependencies (from step 2b)
TMJ>   f. change Export-Package
TMJ>   g. change Private-Package or delete it if it's not needed
TMJ> 6. Run "mvn package" to in the project directory to create the bundle
TMJ> 7. Use bnd to verify the bundle's contents (e.g., java -jar
TMJ> bnd-0.0.jar print target/FOO-osgi-VERSION.jar)
TMJ> 8. Run "mvn install" to install the bundle in the local repository


>> Document process of creating bundles using bnd
>> ----------------------------------------------
>>
>>                 Key: FELIX-171
>>                 URL: http://issues.apache.org/jira/browse/FELIX-171
>>             Project: Felix
>>          Issue Type: Improvement
>>          Components: Felix Commons
>>         Environment: OSGi application development
>>            Reporter: Tim Moloney
>>            Priority: Trivial
>>
>> Provide the list of steps required to create a library bundle by wrapping the library jar using bnd (http://www.aqute.biz/Code/Bnd).


-- 
Peter Kriens                              Tel +33467542167
9C, Avenue St. Drézéry                    AOL,Yahoo: pkriens
34160 Beaulieu, France                    ICQ 255570717
Skype pkriens                             Fax +1 8153772599