On Sat, Sep 6, 2008 at 11:13 PM, Stuart McCulloch <[EMAIL PROTECTED]> wrote:

> 2008/9/6 Richard Wallace <[EMAIL PROTECTED]>
>
>>
>> P.S.  I've also been struggling with what scope to give things.  Does what
>> I have look reasonably correct?
>>
>
> Here's what I personally use for scopes, but note there isn't a perfect
> mapping:
>
>    compile  -  non-OSGi dependencies I need during compilation
>                     (btw, no-scope == compile)
>
>    runtime  -  non-OSGi dependencies I don't need during compilation,
>                     but do need at runtime (I don't use this much - often
> just
>                     when embedding runtime artifacts inside bundles)
>
>    provided  -  OSGi bundle dependencies
>

Ok, that's kind of the same logic as I was following.  Nice to have
confirmation.


>
> of course the downside of using provided for bundle dependencies is that
> you
> don't get their dependencies pulled in, because provided dependencies
> aren't
> transitive.
>
> But OSGi supports replaceable components/dependencies - so I don't see this
> as a major downside, because it lets me choose which bundles I actually
> want
> to deploy (which might be different to the ones used to compile with).
>
> That's where the pax-construct tools (like pax-import-bundle) come in -
> with the
> pax-import-bundle command I can add a bundle dependency, and optionally
> pull
> in all its bundle dependencies (which I can then tweak as necessary).
>
> FYI, I also tend to mark compile and runtime scoped dependencies as
> <optional>
> which means they won't get pulled in when another project depends on my
> bundle
> (because typically the bundle is a replacement for the non-OSGi
> compile/runtime
> dependency - ie. the non-OSGi dependencies never leak through)
>

Hmm... I don't know, I would think in the common case that what you compile
with is what you want to deploy with so its better to make it pull all that
you want/expect in by default and only override it later if/when you really
need to.  That's how I'm approaching it at least.

Also, right now I'm just trying to create a reusable bundle.  But I'd also
like it to be usable outside of an OSGi environment.  So, my OSGi
dependencies, like pax-swissbox-extender, are scoped as compile time
dependencies but are optional.  Meanwhile, the servlet dependency is
provided, as is the pax-web-ex-whiteboard is provided.  The only
non-optional compile-scoped dependencies I have are on slf4j and Google
Collections, because those are needed at runtime regardless of whether the
runtime is an OSGi environment or not.

One thing I'm still struggling with is how to build a shippable
application.  Like I said, right now I'm just working on a library/bundle,
but I've also got an app that I want have run in an OSGi environment.  So
the thing I'm trying to come to grips with is how to create a shippable
tar.gz or zip file that contains everything someone would need to run,
including shell scripts and what not.  Probably pax-construct will help with
that, I just need to figure out how.  But for now I'll take it one thing at
a time...

Thanks,
Rich
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general

Reply via email to