Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAKF+bso-_1o1+wi9fYtV5_hGTkbLXtv=nNAb8ypb5HXL2zJqPQ@mail.gmail.com>
References: 
 <CAA66TpqvBgdwH0T4B=KU2bSOXgL4DUt7BFriLFa5Z5R1H5_t3Q@mail.gmail.com>
 <CAKF+bspapjYsW=O0OBn5-D=cvpWo_KcPAxZ_aeM-E_k61jc0Uw@mail.gmail.com>
 <72F8A073-38D3-4A1E-8076-FC69BC169DB2@apache.org>
 <CAKF+bso-_1o1+wi9fYtV5_hGTkbLXtv=nNAb8ypb5HXL2zJqPQ@mail.gmail.com>
From: Guillaume Nodet <gnodet@apache.org>
Date: Fri, 13 Nov 2015 20:19:03 +0100
Message-ID: 
 <CAA66Tpr_xV_=1QAR1bBZiohey5Wi9cL8yEJagQC6Xq=7iHAPAw@mail.gmail.com>
Subject: Re: [DISCUSS] OSGi support for Artemis
To: dev@activemq.apache.org
Content-Type: multipart/alternative; boundary=001a11c3c6beeae7b5052470ef85

--001a11c3c6beeae7b5052470ef85
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

An uber-jar is obviously a simpler solution, but it's really not the best
one.  I'd rather spend time on a clean solution.
After the split package problem, the next steps would be enhance the
service discovery mechanism to ensure it can work in OSGi, provide a
ConfigAdmin support, a karaf feature, etc...
I'm willing to contribute to solve that and I'll propose some PR, I just
need some indication on how you want to proceed, especially with the split
packages.

The ActiveMQDefaultConfiguration is used by both client and servers, so I
suppose artemis-commons would be a good place for it.  We just need a
specific package for it.  What about
org.apache.activemq.artemis.api.config.common ?

The jms related classes in org.apache.activemq.artemis.uri could be moved
to org.apache.activemq.artemis.uri.jms.

Thoughts ?

Guillaume


2015-11-13 16:33 GMT+01:00 Clebert Suconic <clebert.suconic@gmail.com>:

> ahhh... same package on different JARs... ok.. I missed that.
>
> Yeah.. that needs to be fixed.
>
> On Fri, Nov 13, 2015 at 10:29 AM, Daniel Kulp <dkulp@apache.org> wrote:
> >
> > I=E2=80=99d much much rather see the split packages resolved than have =
an uber
> jar.
> >
> > Can the packages be moved into a =E2=80=9Ccommon=E2=80=9D jar or someth=
ing that can be
> referenced by both?
> >
> >
> > Dan
> >
> >
> >
> >> On Nov 13, 2015, at 10:27 AM, Clebert Suconic <
> clebert.suconic@gmail.com> wrote:
> >>
> >> https://issues.apache.org/jira/browse/ARTEMIS-93
> >>
> >> OSGI still an open task. Fancy contributing? (as the British would say=
)
> >>
> >> The first thing thing I know we will need is an uber JAR. I think we
> >> talked about this during the last Apache Con with some folks.. and I
> >> also remember talking to some other folks.. that the first thing we
> >> will need is an Uber Jar...
> >>
> >>
> >> ActiveMQ has it being done here:
> >>
> >> https://github.com/apache/activemq/tree/master/activemq-osgi
> >>
> >>
> >> Maybe that's an easy transfer?
> >>
> >>
> >> And that would take care of your issue of multiple split jars.. (We
> >> need the split jars as the clients don't want to have server
> >> objects... and other things that are best to be kept separate... you
> >> don't need the resource adapter on the client for instance).
> >>
> >>
> >>
> >> On Fri, Nov 13, 2015 at 9:21 AM, Guillaume Nodet <gnodet@apache.org>
> wrote:
> >>> I was looking at supporting OSGi deployment for Artemis.
> >>>
> >>> The first big problem I hit is the existence of split packages.  Spli=
t
> >>> packages are java packages shared across multiple jars (which become
> >>> bundles in OSGi).
> >>> Examples of those are org.apache.activemq.artemis.uri (shared between
> >>> artemis-jms-client and artemis-core-client) or
> >>> org.apache.activemq.artemis.api.config (shared between
> artemis-core-client
> >>> and artemis-commons).
> >>> The reason they are problematic is that in OSGi, each bundle has its
> own
> >>> class loader, importing classes from other packages based on
> packages.  The
> >>> same package can not be imported from 2 different bundles.
> >>>
> >>> So the question is: would it be possible to get rid of those split
> packages
> >>> ? It can be done either by moving the classes from a jar to another
> one,
> >>> keeping the same package name, or by renaming one of the split packag=
e
> so
> >>> that there's no duplicate package names across jars.
> >>>
> >>> Thoughts ?
> >>> Guillaume Nodet
> >>
> >>
> >>
> >> --
> >> Clebert Suconic
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com
> >
>
>
>
> --
> Clebert Suconic
>

--001a11c3c6beeae7b5052470ef85--