directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <ole_er...@yahoo.com>
Subject Re: [OSGi] Implementing OSGi for 1.5
Date Sat, 10 Feb 2007 01:17:57 GMT
Sounds really cool :-)
+2

Incidentally - I'm writing a Unit Testing Guide.

In it I'm recommending that all methods be made
public,
and if the temptation was to make them private, put
them in "Helper" classes instead that are named

ClassToBeHelpedHelper, indicating that they have a
very close relationship with ClassToBeHelped, so be
careful.

I'm anticipating objections, which is ok, it's just a
suggestion to get unit tests coupled tightly to code,
although it sounds like 

> implementation in private packages within the
> module.

Might be helpful with respect to this.

Thoughts?

Thanks,
- Ole



In it 
--- "John E. Conlon" <jconlon@verticon.com> wrote:

> Think it is time to begin the process of moving OSGi
> into our trunk for 
> the 1.5.0-SNAPSHOT. 
> 
> Propose that instead of adding parallel projects
> that wrap our existing 
> projects in OSGi bundles, that we instead add OSGi
> metadata to the jars 
> that are created by our existing projects.   This is
> easily done by 
> adding the org.apache.felix maven-bundle-plugin to
> our subproject 
> pom.xml files. 
> 
> While Enrique and I used wrapping techniques in our
> initial OSGi 
> parallel project experimentations, working more
> directly on each of our 
> subprojects offers IMO significant advantages.
> 
> 1. Fewer projects. It's basically a few lines in an
> existing project 
> versus a new project.
>     + N existing projects versus N x 2 projects via
> the wrapper approach.
>     + While it is possible to wrap multiple
> subprojects in uber OSGi 
> bundles, this still will produce N number of
> additional projects for us 
> to maintain. 
> 
> 2.  Direct control of OSGi metadata would offer
> techniques for improved 
> decoupling between subprojects
>     + Working directly with OSGi  (Subproject)
> developers will have the 
> tools (via plugin instructions) to begin to focus on
> offering to users 
> of their jars (bundles) public exported packages as
> well as hiding 
> implementation in private packages within the
> module.
> 
> 3.  Better modularity at deploy time.
> 
> What does everyone think?
> 
> cheers,
> John
> 
> 
> 
> 
> 
> 
> 



 
____________________________________________________________________________________
The fish are biting. 
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php

Mime
View raw message