You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Niels B Nielsen <ni...@jpmorgan.com> on 2009/10/28 11:34:12 UTC
OSGI compilation
Hi,
One thing is that OSGI specifies requirements/offers in the Manifest, which makes a controlled deployment environment. I like that.
So com.example.public.* and com.example.private.* are cleanly separated at runtime.
Now, at compile time I have to use example.jar with my vanilla compiler, which clearly cannot honour the privacy of com.example.private.*.
I realise that "...the maven-bundle-plugin doesn't compile classes - it analyzes classes compiled by Maven to add OSGi metadata..."
Because that is the limitation of the underlying BND tool.
But, just coming into this discussion, so forgive my ignorance, is there no motion to push the OSGI restrictions into compilation phase?
I cannot seem to browse any clear solutions but could find some pax stuff and tycho stuff, which is only partially ready. How else do people cope with this?
(The real underlying reason is of course, that deferring problems to deploytime is not good enough. We have most of this working in eclipse-locked-in builds, but really, pragmatically our problems begin at compile level, not system level).
Regards,
/Niels
This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.
Re: OSGI compilation
Posted by David Savage <da...@paremus.com>.
Hi Niels,
Yep this is exactly the purpose of Sigil [1] :)
In fact both PDE and Sigil do what you want in terms of package
visibility in the IDE environment. In terms of headless builds the
eclipse compiler has this functionality but the standard sun javac
compiler does not. It has been considered to wrap the eclipse compiler
so it's available in the sigil build process. Also when the sigil
project was accepted here at felix there was also some discussion
about doing something within apache in this area. But to be honest
I've not had any bandwidth to follow it up.
Obviously welcome any feedback or requirements in this area...
Regards,
Dave
[1] http://felix.apache.org/site/apache-felix-sigil.html
On Wed, Oct 28, 2009 at 10:34 AM, Niels B Nielsen
<ni...@jpmorgan.com> wrote:
> Hi,
>
> One thing is that OSGI specifies requirements/offers in the Manifest, which makes a controlled deployment environment. I like that.
> So com.example.public.* and com.example.private.* are cleanly separated at runtime.
>
> Now, at compile time I have to use example.jar with my vanilla compiler, which clearly cannot honour the privacy of com.example.private.*.
> I realise that "...the maven-bundle-plugin doesn't compile classes - it analyzes classes compiled by Maven to add OSGi metadata..."
> Because that is the limitation of the underlying BND tool.
>
> But, just coming into this discussion, so forgive my ignorance, is there no motion to push the OSGI restrictions into compilation phase?
>
> I cannot seem to browse any clear solutions but could find some pax stuff and tycho stuff, which is only partially ready. How else do people cope with this?
>
> (The real underlying reason is of course, that deferring problems to deploytime is not good enough. We have most of this working in eclipse-locked-in builds, but really, pragmatically our problems begin at compile level, not system level).
>
> Regards,
> /Niels
>
>
> This email is confidential and subject to important disclaimers and
> conditions including on offers for the purchase or sale of
> securities, accuracy and completeness of information, viruses,
> confidentiality, legal privilege, and legal entity disclaimers,
> available at http://www.jpmorgan.com/pages/disclosures/email.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org