Mailing-List: contact users-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@felix.apache.org
Received-SPF: pass (athena.apache.org: domain of heavy@ungoverned.org
 designates 209.85.213.177 as permitted sender)
Message-ID: <4E81F3C9.2020905@ungoverned.org>
Date: Tue, 27 Sep 2011 12:03:21 -0400
From: "Richard S. Hall" <heavy@ungoverned.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: users@felix.apache.org
Subject: Re: Graphical OSGi development tools?
References: 
 <1663037671.1943269.1317137915593.JavaMail.root@sz0116a.westchester.pa.mail.comcast.net>
 <CAGagL=e2dRypq68xUaiR_2oFgMMa8w+N2Ktomw8pJEAOkbvEmQ@mail.gmail.com>
In-Reply-To: 
 <CAGagL=e2dRypq68xUaiR_2oFgMMa8w+N2Ktomw8pJEAOkbvEmQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

On 9/27/11 11:54 AM, Teemu Kanstr�n wrote:
> OSGI solves some set of classloading issues if you need to run plenty of
> fullblown apps inside a single container. In other cases it just provides a
> big pile of additional classloader issues. In many cases it is even rather
> unclear to me why people wish to run many full apps inside a single
> container.

This is not really true and was never the reason why I got into OSGi in 
the first place. If you are building an application out of independently 
developed third-party components, then you cannot control the precise 
version of everyone's dependencies, thus you need a module system to do 
it for you because you will likely end up with conflicts if you don't.

> In the case of customizing some wizards I would definitely not
> apply OSGI but just some basic interface design and plugin architecture.

A plugin architecture is the perfect example of building a single 
application out of third-party components. For example, you cannot 
control which version of Apache Commons some arbitrary plugin uses, so 
if you load two plugins that both need different versions, you'd be dead 
in the water without something like OSGi.

Of course, you are free to create something plugin mechanism that 
minimally provides some of OSGi's isolation features, but this starts 
you down the slippery slope of reinventing the wheel, because you'll 
eventually decide you need shared library support, native library 
support, dynamism, etc.

The real reason people run into so many issues when trying OSGi is 
because they are either knowingly or unknowingly trying to use legacy 
code that makes tons of assumptions about global type visibility. It has 
very little to do with multiple versions being present at the same time.

-> richard

>
> Of course, if you just wish to learn a new technology while doing some app
> regardless, then why not, that is another choice with different
> perspectives.
>
> For OSGI IDE, I do not think it makes sense to look for one. What could it
> do for you? Provide an interface where you type some information that it
> directly writes into the manifest? You are mostly better of learning to do
> it yourself from the beginning. Then you know where to look when you google
> for all those classloader issues.. And then use the IDE of your choice in
> general :)
>
> Teemu
>
> 2011/9/27<mvangeertruy@comcast.net>
>
>>
>> David,
>>
>>
>>
>> Don't give up on OSGi too soon. The fact that almost all of the traditional
>> JEE containers (Weblogic, Webspere, etc) use OSGi internally is a testament
>> to the strong capabilities that OSGi gives.
>>
>>
>>
>> The learning curve for OSGi is pretty interesting. OSGi basically fixes
>> classpath issues present in JEE and Java Application development.  So,
>> learning OSGi is really learning truly modular development and unlearning
>> the cludges required by JEE and Java application development to get around
>> various classpath issues.
>>
>>
>>
>> Many of the Karaf Team's developers use IntelliJ for development.  This is
>> a fairly small GUI and because it is targeted to Java developers, it doesn't
>> carry the overhead of Eclipse. That said, Eclipse is also a strong tool for
>> developing OSGi applications.
>>
>>
>> Please let me know if this helps.
>>
>>
>> ----- Original Message -----
>>
>>
>> From: "David Griffin"<david.griffin@parasense.co.uk>
>> To: users@felix.apache.org
>> Sent: Tuesday, September 27, 2011 11:22:56 AM
>> Subject: RE: Graphical OSGi development tools?
>>
>> Neil,
>>
>> Thanks for the reply. Yes, I had already read through the components
>> tutorial. The problem for me is that I'm having to learn many new things all
>> at the same time to achieve my goal, so wherever it becomes too involved,
>> I'm tending to steer away. What I end up choosing as a set of technologies
>> will need to be explained to other developers in my team, so I need to keep
>> everything a simple as possible.
>>
>> I'm sure OSGi and BndTool will do everything I need, the problem is
>> learning how to make it do just what I need.
>>
>> FTR - I'm currently taking a peek at NetBeans Platform application
>> development to see if that will suffice for my needs. It seems somewhat
>> similar to OSGi. What might win it for me is the availability of various
>> sample applications and the fact the development can be done almost entirely
>> in a Graphical IDE.
>>
>> Still open to other suggestions though.
>>
>> Dave
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org