You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Jeremy Hughes <hu...@apache.org> on 2010/03/11 14:36:53 UTC
Runtime dependencies for our released artifacts
Thanks Guillaume for creating the uber bundle for application. I can
see it is a merge of api, management, runtime and utils which is also,
really the minimum set you could use in a runtime. It happens to be a
transitively closed set w.r.t dependencies which is nice for
consumers.
The blueprint uber bundle isn't transitively closed - it needs asm,
cglib, osgi compendium, slf4j, Which brings me on to how we're going
to point users to the dependencies they need in order to get started
and in particular how this looks on our download page. We could:
1) link to the official download URL for each of the dependencies as
well as link to the uber jar in the Aries dist dir (but users have to
download them all individually),
2) release a zip separate to the uber bundle containing all the
dependencies and link to that on our downloads page, as well as a link
to the uber jar in the Aries dist dir,
3) #2 but include the uber jar in that zip as well,
4) release sample with all the dependencies to run the sample, link to
that and the uber jar which are both stored in Aries dist dir
Also include a zip of the mini-bundles.
#2 & #4 mean we would be releasing a zip containing jars not developed
at Apache, so we need do of course need to adhere to the third party
licensing policy [1]
I favour #4.
What do you all think?
[1] http://www.apache.org/legal/3party.html
Thanks,
Jeremy
Re: Runtime dependencies for our released artifacts
Posted by David Jencks <da...@yahoo.com>.
On Mar 11, 2010, at 2:27 PM, Jeremy Hughes wrote:
> On 11 March 2010 18:10, David Jencks <da...@yahoo.com> wrote:
>>
>> On Mar 11, 2010, at 7:48 AM, Jeremy Hughes wrote:
>>
>>>> <snip>
>>
>>
>>>> Three points i'd like to stress:
>>>> * we need source distributions for everything we release because
>>>> this *is* the official release.
>>>
>>> +1 absolutely. I've just pulled in the Felix 'release' profile into
>>> the Aries parent pom. As a consequence LICENSE and NOTICE files need
>>> to be in SVN at every level. So, while adding them in at every
>>> 'releaseable' level seems like a manageability issue, I think their
>>> presence makes sure we remember that they are there and need to
>>> maintained accurately.
>>>
>>
>> Please undo this,
>
> In fact this never made it into SVN ... and neither did any of the
> later talk of -project.zip.
>
>> I got the build to work so it produced a good set of
>> source bundles so you can build each subproject from the source
>> bundle.
>> This is what apache policy requires and its really simple. What
>> felix does
>> is antiquated and IMHO really bad practice. Please don't copy
>> their build
>> stuff.
>
> If you're objecting to the -project.zip form then that's fine. I've
> been thinking about it a bit more and I actually think if someone is
> that desperate to build the source they'll anonymous svn checkout if
> they don't have an id. So I'm fine with the way it is now.
I haven't looked at what was proposed in detail.... but be sure you
are running
mvn clean install -Papache-release
to see what it generates; just mvn clean install won't produce the
artifacts needed for a release.
thanks
david jencks
>
> Cheers,
> Jeremy
>
>>
>> thanks
>> david jencks
>>
>>
>>
>>
Re: Runtime dependencies for our released artifacts
Posted by Jeremy Hughes <hu...@apache.org>.
On 11 March 2010 18:10, David Jencks <da...@yahoo.com> wrote:
>
> On Mar 11, 2010, at 7:48 AM, Jeremy Hughes wrote:
>
>>> <snip>
>
>
>>> Three points i'd like to stress:
>>> * we need source distributions for everything we release because
>>> this *is* the official release.
>>
>> +1 absolutely. I've just pulled in the Felix 'release' profile into
>> the Aries parent pom. As a consequence LICENSE and NOTICE files need
>> to be in SVN at every level. So, while adding them in at every
>> 'releaseable' level seems like a manageability issue, I think their
>> presence makes sure we remember that they are there and need to
>> maintained accurately.
>>
>
> Please undo this,
In fact this never made it into SVN ... and neither did any of the
later talk of -project.zip.
> I got the build to work so it produced a good set of
> source bundles so you can build each subproject from the source bundle.
> This is what apache policy requires and its really simple. What felix does
> is antiquated and IMHO really bad practice. Please don't copy their build
> stuff.
If you're objecting to the -project.zip form then that's fine. I've
been thinking about it a bit more and I actually think if someone is
that desperate to build the source they'll anonymous svn checkout if
they don't have an id. So I'm fine with the way it is now.
Cheers,
Jeremy
>
> thanks
> david jencks
>
>
>
>
Re: Runtime dependencies for our released artifacts
Posted by David Jencks <da...@yahoo.com>.
On Mar 11, 2010, at 7:48 AM, Jeremy Hughes wrote:
>> <snip>
>> Three points i'd like to stress:
>> * we need source distributions for everything we release because
>> this *is* the official release.
>
> +1 absolutely. I've just pulled in the Felix 'release' profile into
> the Aries parent pom. As a consequence LICENSE and NOTICE files need
> to be in SVN at every level. So, while adding them in at every
> 'releaseable' level seems like a manageability issue, I think their
> presence makes sure we remember that they are there and need to
> maintained accurately.
>
Please undo this, I got the build to work so it produced a good set
of source bundles so you can build each subproject from the source
bundle. This is what apache policy requires and its really simple.
What felix does is antiquated and IMHO really bad practice. Please
don't copy their build stuff.
thanks
david jencks
Re: Runtime dependencies for our released artifacts
Posted by The Dweller <ba...@gmail.com>.
Re losing anything, Off the top of my head, I don't know, but Valentin
mentioned that cglib handled multiple interface proxying where the asm
alternative didn't..
If we only want a single implementation to lighten the test/support load,
that's fine =)
However, I'd still like it to be abstracted out / tidied up so it can be
made use of by BeanProcessors & NamespaceHandlers (while also being used for
both Interceptors and ServiceReferences). I guess it may also be beneficial
to look a little deeper to find out what other differences there are in the
capabilities of the two (ignoring jdk proxy here for a mo).
Ozzy.
On 7 April 2010 20:45, Jeremy Hughes <hu...@apache.org> wrote:
> On 7 April 2010 20:16, The Dweller <ba...@gmail.com> wrote:
> > We built our interceptors based over asm (and over cglib).. I wouldn't
> > consider the asm implementation as a lib currently, it has no external
> api,
> > and it is only used for interceptors.
> >
> > The suggestion isn't so much to keep cglib as being used, as to abstract
> all
> > our usage of cglib/asm/jdkproxy into a single place, so that its
> > implementation is irrelevant. Then yes, it could be considered as our own
> > proxying lib. At which point, it matters little if the implementation is
> > handled via cglib, asm, or jdk proxy, each of which brings their own set
> of
> > advantages/disadvantages to the table.
> >
> > Is there something bad about having the proxying able to run on a variety
> of
> > libraries?
>
> I know this sounds nice but it means extra to test and support and
> really I don't think the user is going care which is being used
> underneath so long as it works as advertised. If we were to just ASM
> and the code we have in Aries on top of that do we lose anything
> (other than other dependency options to achieve the same)?
>
> >
> > Ozzy.
> >
> >
> >
> >
> > On 7 April 2010 19:59, Guillaume Nodet <gn...@gmail.com> wrote:
> >
> >> I must be missing something. I thought we built our own lib on top of
> >> asm for the interceptors stuff. My point is that this lib looks kinda
> >> like cglib, being built on top of asm. So why don't we use it instead
> >> of cglib everywhere so that we can get rid of cglib?
> >>
> >> On Wednesday, April 7, 2010, Joe Bohn <jo...@gmail.com> wrote:
> >> >
> >> > So, if I understand you correctly then, your point is that we should
> not
> >> be looking to remove cglib completely but just keep it optional. It has
> been
> >> included in blueprint for a while (for service reference proxies) and we
> >> have found it useful for other things like interceptors. We should keep
> it
> >> optional and consolidate it (along with asm) to a common bundle.
> >> >
> >> > Thanks,
> >> > Joe
> >> >
> >> >
> >> > The Dweller wrote:
> >> >
> >> > From memory, cglib was always an optional dependency for blueprint.
> >> >
> >> >
> >> > Originally used only for the proxying in service references, if cglib
> >> wasn't
> >> > available, then that proxying would fall back to jdk proxy if
> possible.
> >> > (Although, only cglib provided 'class proxying' support)
> >> >
> >> > Later, it was also used to provide interceptors, again written to
> allow
> >> it
> >> > to be optional, if it wasn't available, interceptor support would
> >> disable.
> >> >
> >> > Later still, we added the code to allow interceptors to utilise asm,
> (or
> >> > cglib).
> >> >
> >> > We also have a jira open to common up our proxying code to a single
> >> place,
> >> > to allow both interceptors and service reference proxying to share the
> >> code,
> >> > and ideally provide an api to allow namespace handlers, bean
> processors
> >> > implementations etc, to make use of the function. If the proxying code
> >> were
> >> > to move out to its own bundle, then the cglib/asm/etc dependencies for
> >> > proxying would be isolated to just there.
> >> >
> >> > Ozzy.
> >> >
> >> > On 6 April 2010 20:51, Joe Bohn <jo...@gmail.com> wrote:
> >> >
> >> >
> >> > In discussion below regarding cglib .... was the intent to completely
> >> > remove the use of cglib or just make it optional?
> >> >
> >> > From what I can tell it seems that cglib is already optional (perhaps
> due
> >> > to changes after this discussion). But we still use it if available
> in
> >> > Blueprint AbstractServiceReference and the Blueprint Interceptor
> logic.
> >> If
> >> > we completely remove it from the Blueprint Interceptor logic we would
> >> always
> >> > assume ASM. If we completely remove it from AbstractServiceReference
> we
> >> > would always use the JdkProxy and would likewise need to remove the
> >> > AbstractServiceReferenceTest which seems to be cglib specific.
> >> >
> >> > I have some local changes that I can check in to completely remove
> cglib
> >> if
> >> > that is really the intent.
> >> >
> >> > Joe
> >> >
> >> >
> >> >
> >> > Jeremy Hughes wrote:
> >> >
> >> >
> >> > On 11 March 2010 15:48, Jeremy Hughes <hu...@apache.org> wrote:
> >> >
> >> >
> >> > On 11 March 2010 14:59, Guillaume Nodet <gn...@gmail.com> wrote:
> >> >
> >> >
> >> > On Thu, Mar 11, 2010 at 14:36, Jeremy Hughes <hu...@apache.org>
> >> > wrote:
> >> >
> >> >
> >> > <snip/>
> >> >
> >> >
> >> > Beyong the core JRE and osgi packages, we have:
> >> >
> >> > * cglib : we should get rid of that one
> >> >
> >> >
> >> > +1 there's a few JIRAs around this but not one to get rid.
> >> >
> >> >
> >> > <snip/>
> >> >
> >> >
> >> > We should really get rid of cglib asap. cglib itself uses asm and we
> >> >
> >> > have our own layer on top of asm.
> >> > I don't think we should have a mandatory import on
> >> > org.osgi.service.cm, so either find a way to make it optional or
> >> > exclude it ?
> >> >
> >> >
> >> > ok
> >> >
> >> >
> >> > <snip/>
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Joe
> >> >
> >>
> >> --
> >> Cheers,
> >> Guillaume Nodet
> >> ------------------------
> >> Blog: http://gnodet.blogspot.com/
> >> ------------------------
> >> Open Source SOA
> >> http://fusesource.com
> >>
> >
>
Re: Runtime dependencies for our released artifacts
Posted by Jeremy Hughes <hu...@apache.org>.
On 7 April 2010 20:16, The Dweller <ba...@gmail.com> wrote:
> We built our interceptors based over asm (and over cglib).. I wouldn't
> consider the asm implementation as a lib currently, it has no external api,
> and it is only used for interceptors.
>
> The suggestion isn't so much to keep cglib as being used, as to abstract all
> our usage of cglib/asm/jdkproxy into a single place, so that its
> implementation is irrelevant. Then yes, it could be considered as our own
> proxying lib. At which point, it matters little if the implementation is
> handled via cglib, asm, or jdk proxy, each of which brings their own set of
> advantages/disadvantages to the table.
>
> Is there something bad about having the proxying able to run on a variety of
> libraries?
I know this sounds nice but it means extra to test and support and
really I don't think the user is going care which is being used
underneath so long as it works as advertised. If we were to just ASM
and the code we have in Aries on top of that do we lose anything
(other than other dependency options to achieve the same)?
>
> Ozzy.
>
>
>
>
> On 7 April 2010 19:59, Guillaume Nodet <gn...@gmail.com> wrote:
>
>> I must be missing something. I thought we built our own lib on top of
>> asm for the interceptors stuff. My point is that this lib looks kinda
>> like cglib, being built on top of asm. So why don't we use it instead
>> of cglib everywhere so that we can get rid of cglib?
>>
>> On Wednesday, April 7, 2010, Joe Bohn <jo...@gmail.com> wrote:
>> >
>> > So, if I understand you correctly then, your point is that we should not
>> be looking to remove cglib completely but just keep it optional. It has been
>> included in blueprint for a while (for service reference proxies) and we
>> have found it useful for other things like interceptors. We should keep it
>> optional and consolidate it (along with asm) to a common bundle.
>> >
>> > Thanks,
>> > Joe
>> >
>> >
>> > The Dweller wrote:
>> >
>> > From memory, cglib was always an optional dependency for blueprint.
>> >
>> >
>> > Originally used only for the proxying in service references, if cglib
>> wasn't
>> > available, then that proxying would fall back to jdk proxy if possible.
>> > (Although, only cglib provided 'class proxying' support)
>> >
>> > Later, it was also used to provide interceptors, again written to allow
>> it
>> > to be optional, if it wasn't available, interceptor support would
>> disable.
>> >
>> > Later still, we added the code to allow interceptors to utilise asm, (or
>> > cglib).
>> >
>> > We also have a jira open to common up our proxying code to a single
>> place,
>> > to allow both interceptors and service reference proxying to share the
>> code,
>> > and ideally provide an api to allow namespace handlers, bean processors
>> > implementations etc, to make use of the function. If the proxying code
>> were
>> > to move out to its own bundle, then the cglib/asm/etc dependencies for
>> > proxying would be isolated to just there.
>> >
>> > Ozzy.
>> >
>> > On 6 April 2010 20:51, Joe Bohn <jo...@gmail.com> wrote:
>> >
>> >
>> > In discussion below regarding cglib .... was the intent to completely
>> > remove the use of cglib or just make it optional?
>> >
>> > From what I can tell it seems that cglib is already optional (perhaps due
>> > to changes after this discussion). But we still use it if available in
>> > Blueprint AbstractServiceReference and the Blueprint Interceptor logic.
>> If
>> > we completely remove it from the Blueprint Interceptor logic we would
>> always
>> > assume ASM. If we completely remove it from AbstractServiceReference we
>> > would always use the JdkProxy and would likewise need to remove the
>> > AbstractServiceReferenceTest which seems to be cglib specific.
>> >
>> > I have some local changes that I can check in to completely remove cglib
>> if
>> > that is really the intent.
>> >
>> > Joe
>> >
>> >
>> >
>> > Jeremy Hughes wrote:
>> >
>> >
>> > On 11 March 2010 15:48, Jeremy Hughes <hu...@apache.org> wrote:
>> >
>> >
>> > On 11 March 2010 14:59, Guillaume Nodet <gn...@gmail.com> wrote:
>> >
>> >
>> > On Thu, Mar 11, 2010 at 14:36, Jeremy Hughes <hu...@apache.org>
>> > wrote:
>> >
>> >
>> > <snip/>
>> >
>> >
>> > Beyong the core JRE and osgi packages, we have:
>> >
>> > * cglib : we should get rid of that one
>> >
>> >
>> > +1 there's a few JIRAs around this but not one to get rid.
>> >
>> >
>> > <snip/>
>> >
>> >
>> > We should really get rid of cglib asap. cglib itself uses asm and we
>> >
>> > have our own layer on top of asm.
>> > I don't think we should have a mandatory import on
>> > org.osgi.service.cm, so either find a way to make it optional or
>> > exclude it ?
>> >
>> >
>> > ok
>> >
>> >
>> > <snip/>
>> >
>> >
>> >
>> >
>> >
>> >
>> > --
>> > Joe
>> >
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
Re: Runtime dependencies for our released artifacts
Posted by The Dweller <ba...@gmail.com>.
We built our interceptors based over asm (and over cglib).. I wouldn't
consider the asm implementation as a lib currently, it has no external api,
and it is only used for interceptors.
The suggestion isn't so much to keep cglib as being used, as to abstract all
our usage of cglib/asm/jdkproxy into a single place, so that its
implementation is irrelevant. Then yes, it could be considered as our own
proxying lib. At which point, it matters little if the implementation is
handled via cglib, asm, or jdk proxy, each of which brings their own set of
advantages/disadvantages to the table.
Is there something bad about having the proxying able to run on a variety of
libraries?
Ozzy.
On 7 April 2010 19:59, Guillaume Nodet <gn...@gmail.com> wrote:
> I must be missing something. I thought we built our own lib on top of
> asm for the interceptors stuff. My point is that this lib looks kinda
> like cglib, being built on top of asm. So why don't we use it instead
> of cglib everywhere so that we can get rid of cglib?
>
> On Wednesday, April 7, 2010, Joe Bohn <jo...@gmail.com> wrote:
> >
> > So, if I understand you correctly then, your point is that we should not
> be looking to remove cglib completely but just keep it optional. It has been
> included in blueprint for a while (for service reference proxies) and we
> have found it useful for other things like interceptors. We should keep it
> optional and consolidate it (along with asm) to a common bundle.
> >
> > Thanks,
> > Joe
> >
> >
> > The Dweller wrote:
> >
> > From memory, cglib was always an optional dependency for blueprint.
> >
> >
> > Originally used only for the proxying in service references, if cglib
> wasn't
> > available, then that proxying would fall back to jdk proxy if possible.
> > (Although, only cglib provided 'class proxying' support)
> >
> > Later, it was also used to provide interceptors, again written to allow
> it
> > to be optional, if it wasn't available, interceptor support would
> disable.
> >
> > Later still, we added the code to allow interceptors to utilise asm, (or
> > cglib).
> >
> > We also have a jira open to common up our proxying code to a single
> place,
> > to allow both interceptors and service reference proxying to share the
> code,
> > and ideally provide an api to allow namespace handlers, bean processors
> > implementations etc, to make use of the function. If the proxying code
> were
> > to move out to its own bundle, then the cglib/asm/etc dependencies for
> > proxying would be isolated to just there.
> >
> > Ozzy.
> >
> > On 6 April 2010 20:51, Joe Bohn <jo...@gmail.com> wrote:
> >
> >
> > In discussion below regarding cglib .... was the intent to completely
> > remove the use of cglib or just make it optional?
> >
> > From what I can tell it seems that cglib is already optional (perhaps due
> > to changes after this discussion). But we still use it if available in
> > Blueprint AbstractServiceReference and the Blueprint Interceptor logic.
> If
> > we completely remove it from the Blueprint Interceptor logic we would
> always
> > assume ASM. If we completely remove it from AbstractServiceReference we
> > would always use the JdkProxy and would likewise need to remove the
> > AbstractServiceReferenceTest which seems to be cglib specific.
> >
> > I have some local changes that I can check in to completely remove cglib
> if
> > that is really the intent.
> >
> > Joe
> >
> >
> >
> > Jeremy Hughes wrote:
> >
> >
> > On 11 March 2010 15:48, Jeremy Hughes <hu...@apache.org> wrote:
> >
> >
> > On 11 March 2010 14:59, Guillaume Nodet <gn...@gmail.com> wrote:
> >
> >
> > On Thu, Mar 11, 2010 at 14:36, Jeremy Hughes <hu...@apache.org>
> > wrote:
> >
> >
> > <snip/>
> >
> >
> > Beyong the core JRE and osgi packages, we have:
> >
> > * cglib : we should get rid of that one
> >
> >
> > +1 there's a few JIRAs around this but not one to get rid.
> >
> >
> > <snip/>
> >
> >
> > We should really get rid of cglib asap. cglib itself uses asm and we
> >
> > have our own layer on top of asm.
> > I don't think we should have a mandatory import on
> > org.osgi.service.cm, so either find a way to make it optional or
> > exclude it ?
> >
> >
> > ok
> >
> >
> > <snip/>
> >
> >
> >
> >
> >
> >
> > --
> > Joe
> >
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: Runtime dependencies for our released artifacts
Posted by Guillaume Nodet <gn...@gmail.com>.
I must be missing something. I thought we built our own lib on top of
asm for the interceptors stuff. My point is that this lib looks kinda
like cglib, being built on top of asm. So why don't we use it instead
of cglib everywhere so that we can get rid of cglib?
On Wednesday, April 7, 2010, Joe Bohn <jo...@gmail.com> wrote:
>
> So, if I understand you correctly then, your point is that we should not be looking to remove cglib completely but just keep it optional. It has been included in blueprint for a while (for service reference proxies) and we have found it useful for other things like interceptors. We should keep it optional and consolidate it (along with asm) to a common bundle.
>
> Thanks,
> Joe
>
>
> The Dweller wrote:
>
> From memory, cglib was always an optional dependency for blueprint.
>
>
> Originally used only for the proxying in service references, if cglib wasn't
> available, then that proxying would fall back to jdk proxy if possible.
> (Although, only cglib provided 'class proxying' support)
>
> Later, it was also used to provide interceptors, again written to allow it
> to be optional, if it wasn't available, interceptor support would disable.
>
> Later still, we added the code to allow interceptors to utilise asm, (or
> cglib).
>
> We also have a jira open to common up our proxying code to a single place,
> to allow both interceptors and service reference proxying to share the code,
> and ideally provide an api to allow namespace handlers, bean processors
> implementations etc, to make use of the function. If the proxying code were
> to move out to its own bundle, then the cglib/asm/etc dependencies for
> proxying would be isolated to just there.
>
> Ozzy.
>
> On 6 April 2010 20:51, Joe Bohn <jo...@gmail.com> wrote:
>
>
> In discussion below regarding cglib .... was the intent to completely
> remove the use of cglib or just make it optional?
>
> From what I can tell it seems that cglib is already optional (perhaps due
> to changes after this discussion). But we still use it if available in
> Blueprint AbstractServiceReference and the Blueprint Interceptor logic. If
> we completely remove it from the Blueprint Interceptor logic we would always
> assume ASM. If we completely remove it from AbstractServiceReference we
> would always use the JdkProxy and would likewise need to remove the
> AbstractServiceReferenceTest which seems to be cglib specific.
>
> I have some local changes that I can check in to completely remove cglib if
> that is really the intent.
>
> Joe
>
>
>
> Jeremy Hughes wrote:
>
>
> On 11 March 2010 15:48, Jeremy Hughes <hu...@apache.org> wrote:
>
>
> On 11 March 2010 14:59, Guillaume Nodet <gn...@gmail.com> wrote:
>
>
> On Thu, Mar 11, 2010 at 14:36, Jeremy Hughes <hu...@apache.org>
> wrote:
>
>
> <snip/>
>
>
> Beyong the core JRE and osgi packages, we have:
>
> * cglib : we should get rid of that one
>
>
> +1 there's a few JIRAs around this but not one to get rid.
>
>
> <snip/>
>
>
> We should really get rid of cglib asap. cglib itself uses asm and we
>
> have our own layer on top of asm.
> I don't think we should have a mandatory import on
> org.osgi.service.cm, so either find a way to make it optional or
> exclude it ?
>
>
> ok
>
>
> <snip/>
>
>
>
>
>
>
> --
> Joe
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Runtime dependencies for our released artifacts
Posted by Joe Bohn <jo...@gmail.com>.
So, if I understand you correctly then, your point is that we should not
be looking to remove cglib completely but just keep it optional. It has
been included in blueprint for a while (for service reference proxies)
and we have found it useful for other things like interceptors. We
should keep it optional and consolidate it (along with asm) to a common
bundle.
Thanks,
Joe
The Dweller wrote:
>>>From memory, cglib was always an optional dependency for blueprint.
>
> Originally used only for the proxying in service references, if cglib wasn't
> available, then that proxying would fall back to jdk proxy if possible.
> (Although, only cglib provided 'class proxying' support)
>
> Later, it was also used to provide interceptors, again written to allow it
> to be optional, if it wasn't available, interceptor support would disable.
>
> Later still, we added the code to allow interceptors to utilise asm, (or
> cglib).
>
> We also have a jira open to common up our proxying code to a single place,
> to allow both interceptors and service reference proxying to share the code,
> and ideally provide an api to allow namespace handlers, bean processors
> implementations etc, to make use of the function. If the proxying code were
> to move out to its own bundle, then the cglib/asm/etc dependencies for
> proxying would be isolated to just there.
>
> Ozzy.
>
> On 6 April 2010 20:51, Joe Bohn <jo...@gmail.com> wrote:
>
>> In discussion below regarding cglib .... was the intent to completely
>> remove the use of cglib or just make it optional?
>>
>> From what I can tell it seems that cglib is already optional (perhaps due
>> to changes after this discussion). But we still use it if available in
>> Blueprint AbstractServiceReference and the Blueprint Interceptor logic. If
>> we completely remove it from the Blueprint Interceptor logic we would always
>> assume ASM. If we completely remove it from AbstractServiceReference we
>> would always use the JdkProxy and would likewise need to remove the
>> AbstractServiceReferenceTest which seems to be cglib specific.
>>
>> I have some local changes that I can check in to completely remove cglib if
>> that is really the intent.
>>
>> Joe
>>
>>
>>
>> Jeremy Hughes wrote:
>>
>>> On 11 March 2010 15:48, Jeremy Hughes <hu...@apache.org> wrote:
>>>
>>>> On 11 March 2010 14:59, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>
>>>>> On Thu, Mar 11, 2010 at 14:36, Jeremy Hughes <hu...@apache.org>
>>>>> wrote:
>>>>>
>> <snip/>
>>
>>
>> Beyong the core JRE and osgi packages, we have:
>>>>> * cglib : we should get rid of that one
>>>>>
>>>> +1 there's a few JIRAs around this but not one to get rid.
>>>>
>> <snip/>
>>
>>
>> We should really get rid of cglib asap. cglib itself uses asm and we
>>>>> have our own layer on top of asm.
>>>>> I don't think we should have a mandatory import on
>>>>> org.osgi.service.cm, so either find a way to make it optional or
>>>>> exclude it ?
>>>>>
>>>> ok
>>>>
>> <snip/>
>>
>
--
Joe
Re: Runtime dependencies for our released artifacts
Posted by The Dweller <ba...@gmail.com>.
>From memory, cglib was always an optional dependency for blueprint.
Originally used only for the proxying in service references, if cglib wasn't
available, then that proxying would fall back to jdk proxy if possible.
(Although, only cglib provided 'class proxying' support)
Later, it was also used to provide interceptors, again written to allow it
to be optional, if it wasn't available, interceptor support would disable.
Later still, we added the code to allow interceptors to utilise asm, (or
cglib).
We also have a jira open to common up our proxying code to a single place,
to allow both interceptors and service reference proxying to share the code,
and ideally provide an api to allow namespace handlers, bean processors
implementations etc, to make use of the function. If the proxying code were
to move out to its own bundle, then the cglib/asm/etc dependencies for
proxying would be isolated to just there.
Ozzy.
On 6 April 2010 20:51, Joe Bohn <jo...@gmail.com> wrote:
>
> In discussion below regarding cglib .... was the intent to completely
> remove the use of cglib or just make it optional?
>
> From what I can tell it seems that cglib is already optional (perhaps due
> to changes after this discussion). But we still use it if available in
> Blueprint AbstractServiceReference and the Blueprint Interceptor logic. If
> we completely remove it from the Blueprint Interceptor logic we would always
> assume ASM. If we completely remove it from AbstractServiceReference we
> would always use the JdkProxy and would likewise need to remove the
> AbstractServiceReferenceTest which seems to be cglib specific.
>
> I have some local changes that I can check in to completely remove cglib if
> that is really the intent.
>
> Joe
>
>
>
> Jeremy Hughes wrote:
>
>> On 11 March 2010 15:48, Jeremy Hughes <hu...@apache.org> wrote:
>>
>>> On 11 March 2010 14:59, Guillaume Nodet <gn...@gmail.com> wrote:
>>>
>>>> On Thu, Mar 11, 2010 at 14:36, Jeremy Hughes <hu...@apache.org>
>>>> wrote:
>>>>
>>>
> <snip/>
>
>
> Beyong the core JRE and osgi packages, we have:
>>>> * cglib : we should get rid of that one
>>>>
>>> +1 there's a few JIRAs around this but not one to get rid.
>>>
>>
> <snip/>
>
>
> We should really get rid of cglib asap. cglib itself uses asm and we
>>>> have our own layer on top of asm.
>>>> I don't think we should have a mandatory import on
>>>> org.osgi.service.cm, so either find a way to make it optional or
>>>> exclude it ?
>>>>
>>> ok
>>>
>>
> <snip/>
>
Re: Runtime dependencies for our released artifacts
Posted by Joe Bohn <jo...@gmail.com>.
In discussion below regarding cglib .... was the intent to completely
remove the use of cglib or just make it optional?
From what I can tell it seems that cglib is already optional (perhaps
due to changes after this discussion). But we still use it if available
in Blueprint AbstractServiceReference and the Blueprint Interceptor
logic. If we completely remove it from the Blueprint Interceptor logic
we would always assume ASM. If we completely remove it from
AbstractServiceReference we would always use the JdkProxy and would
likewise need to remove the AbstractServiceReferenceTest which seems to
be cglib specific.
I have some local changes that I can check in to completely remove cglib
if that is really the intent.
Joe
Jeremy Hughes wrote:
> On 11 March 2010 15:48, Jeremy Hughes <hu...@apache.org> wrote:
>> On 11 March 2010 14:59, Guillaume Nodet <gn...@gmail.com> wrote:
>>> On Thu, Mar 11, 2010 at 14:36, Jeremy Hughes <hu...@apache.org> wrote:
<snip/>
>>> Beyong the core JRE and osgi packages, we have:
>>> * cglib : we should get rid of that one
>> +1 there's a few JIRAs around this but not one to get rid.
<snip/>
>>> We should really get rid of cglib asap. cglib itself uses asm and we
>>> have our own layer on top of asm.
>>> I don't think we should have a mandatory import on
>>> org.osgi.service.cm, so either find a way to make it optional or
>>> exclude it ?
>> ok
<snip/>
Re: Runtime dependencies for our released artifacts
Posted by Jeremy Hughes <hu...@apache.org>.
On 11 March 2010 15:48, Jeremy Hughes <hu...@apache.org> wrote:
> On 11 March 2010 14:59, Guillaume Nodet <gn...@gmail.com> wrote:
>> On Thu, Mar 11, 2010 at 14:36, Jeremy Hughes <hu...@apache.org> wrote:
>>> Thanks Guillaume for creating the uber bundle for application. I can
>>> see it is a merge of api, management, runtime and utils which is also,
>>> really the minimum set you could use in a runtime. It happens to be a
>>> transitively closed set w.r.t dependencies which is nice for
>>> consumers.
>>
>> Yeah, I would love to add the other optional bits, but I'm stuck
>> because those really should be optional and blueprint has no way to
>> handle that (see the other discussion on the dev list about this exact
>> problem).
>>
>>>
>>> The blueprint uber bundle isn't transitively closed - it needs asm,
>>> cglib, osgi compendium, slf4j,
>>>
>>
>> Import-Package: javax.xml.parsers,javax.xml.transform,javax.xml.transf
>> orm.dom,javax.xml.transform.stream,javax.xml.validation,net.sf.cglib.
>> proxy;resolution:=optional;version="[2.1,3)",org.objectweb.asm;resolu
>> tion:=optional;version="[3.1,4)",org.objectweb.asm.commons;resolution
>> :=optional;version="[3.1,4)",org.osgi.framework;version="[1.5,2)",org
>> .osgi.framework.launch;version="[1.0,2)",org.osgi.service.cm;version=
>> "[1.2.0,2.0.0)",org.osgi.service.event;resolution:=optional;version="
>> [1.2,2)",org.osgi.service.framework;resolution:=optional;version="[1.
>> 0,2)",org.osgi.util.tracker;version="[1.4,2)",org.slf4j;version="[1.5
>> ,2)",org.w3c.dom,org.xml.sax
>>
>> Beyong the core JRE and osgi packages, we have:
>> * cglib : we should get rid of that one
>
> +1 there's a few JIRAs around this but not one to get rid.
>
>> * asm : we should embed it
>
> isn't this where cglib got into trouble. Adding this in just doesn't
> feel very modular!
>
>> * org.osgi.framework.launch : no idea where this one come from, i
>> can't find any reference in the whole project
>
> cool lets remove it
>
>> * org.osgi.service.cm : we should try to make it optional, but we'll
>> have the same problem as for applications
>> * org.osgi.service.event;resolution:=optional : it's optional and ok
>> * org.osgi.service.framework;resolution:=optional : that's for
>> composite bundles, given it's optional it's ok
>> * org.osgi.util.tracker : we may want to embed it
>> * org.slf4j : we discussed that and decided not to use a wrapper, so
>> we could either import / export it or leave it as a mandatory import
>>
>> We should really get rid of cglib asap. cglib itself uses asm and we
>> have our own layer on top of asm.
>> I don't think we should have a mandatory import on
>> org.osgi.service.cm, so either find a way to make it optional or
>> exclude it ?
>
> ok
>
>>
>>> Which brings me on to how we're going
>>> to point users to the dependencies they need in order to get started
>>> and in particular how this looks on our download page. We could:
>>> 1) link to the official download URL for each of the dependencies as
>>> well as link to the uber jar in the Aries dist dir (but users have to
>>> download them all individually),
>>> 2) release a zip separate to the uber bundle containing all the
>>> dependencies and link to that on our downloads page, as well as a link
>>> to the uber jar in the Aries dist dir,
>>> 3) #2 but include the uber jar in that zip as well,
>>> 4) release sample with all the dependencies to run the sample, link to
>>> that and the uber jar which are both stored in Aries dist dir
>>>
>>> Also include a zip of the mini-bundles.
>>>
>>> #2 & #4 mean we would be releasing a zip containing jars not developed
>>> at Apache, so we need do of course need to adhere to the third party
>>> licensing policy [1]
>>>
>>> I favour #4.
>>>
>>> What do you all think?
>>
>> Three points i'd like to stress:
>> * we need source distributions for everything we release because
>> this *is* the official release.
>
> +1 absolutely. I've just pulled in the Felix 'release' profile into
> the Aries parent pom. As a consequence LICENSE and NOTICE files need
> to be in SVN at every level. So, while adding them in at every
> 'releaseable' level seems like a manageability issue, I think their
> presence makes sure we remember that they are there and need to
> maintained accurately.
Having said that, David did some work a few weeks back to have the
LICENSE and NOTICE files from the top level module put into the built
artifacts. Perhaps it would be best to provide a -project.zip only for
top-level modules rather than all the sub-modules and that is what the
draft download wiki page reflects at the moment.
>
>> * all the maven modules binary jars will all be available from the
>> maven repos. Which one we advertise is a different story though.
>
> all the files that get installed into a local repo will end up going
> to the remove repo at this rate. If there really is something that we
> don't want to publish (and I'm not so convinced about testbundlea,
> testbundleb and a few others), the we need to decide what to exclude.
> At the moment we're heading towards publishing everything under a top
> level module that we're releasing. In order for the -project.zip trick
> to work (i.e. unzip the -project.zip and you can run mvn, without
> having to do an svn checkout) then I think we'll need to release the
> testsupport module.
>
> What we release to a maven repo and what we link to from a (new) Aries
> download page on our web site aren't necessarily the same thing. Zoe
> has started a page:
>
> http://cwiki.apache.org/confluence/display/ARIES/Release%20proposal
I should mention that it doesn't have the uber jar as a download
option at the moment.
>
>> * any zip we create as a binary distribution should be part of the
>> build and not manually generated.
>
> +1 ... automation is our friend.
>
>>
>>>
>>> [1] http://www.apache.org/legal/3party.html
>>>
>>> Thanks,
>>> Jeremy
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
Re: Runtime dependencies for our released artifacts
Posted by Jeremy Hughes <hu...@apache.org>.
On 11 March 2010 16:02, Guillaume Nodet <gn...@gmail.com> wrote:
> On Thu, Mar 11, 2010 at 16:48, Jeremy Hughes <hu...@apache.org> wrote:
>> On 11 March 2010 14:59, Guillaume Nodet <gn...@gmail.com> wrote:
>>> On Thu, Mar 11, 2010 at 14:36, Jeremy Hughes <hu...@apache.org> wrote:
>>>> Thanks Guillaume for creating the uber bundle for application. I can
>>>> see it is a merge of api, management, runtime and utils which is also,
>>>> really the minimum set you could use in a runtime. It happens to be a
>>>> transitively closed set w.r.t dependencies which is nice for
>>>> consumers.
>>>
>>> Yeah, I would love to add the other optional bits, but I'm stuck
>>> because those really should be optional and blueprint has no way to
>>> handle that (see the other discussion on the dev list about this exact
>>> problem).
>>>
>>>>
>>>> The blueprint uber bundle isn't transitively closed - it needs asm,
>>>> cglib, osgi compendium, slf4j,
>>>>
>>>
>>> Import-Package: javax.xml.parsers,javax.xml.transform,javax.xml.transf
>>> orm.dom,javax.xml.transform.stream,javax.xml.validation,net.sf.cglib.
>>> proxy;resolution:=optional;version="[2.1,3)",org.objectweb.asm;resolu
>>> tion:=optional;version="[3.1,4)",org.objectweb.asm.commons;resolution
>>> :=optional;version="[3.1,4)",org.osgi.framework;version="[1.5,2)",org
>>> .osgi.framework.launch;version="[1.0,2)",org.osgi.service.cm;version=
>>> "[1.2.0,2.0.0)",org.osgi.service.event;resolution:=optional;version="
>>> [1.2,2)",org.osgi.service.framework;resolution:=optional;version="[1.
>>> 0,2)",org.osgi.util.tracker;version="[1.4,2)",org.slf4j;version="[1.5
>>> ,2)",org.w3c.dom,org.xml.sax
>>>
>>> Beyong the core JRE and osgi packages, we have:
>>> * cglib : we should get rid of that one
>>
>> +1 there's a few JIRAs around this but not one to get rid.
>>
>>> * asm : we should embed it
>>
>> isn't this where cglib got into trouble. Adding this in just doesn't
>> feel very modular!
>>
>>> * org.osgi.framework.launch : no idea where this one come from, i
>>> can't find any reference in the whole project
>>
>> cool lets remove it
>>
>>> * org.osgi.service.cm : we should try to make it optional, but we'll
>>> have the same problem as for applications
>>> * org.osgi.service.event;resolution:=optional : it's optional and ok
>>> * org.osgi.service.framework;resolution:=optional : that's for
>>> composite bundles, given it's optional it's ok
>>> * org.osgi.util.tracker : we may want to embed it
>>> * org.slf4j : we discussed that and decided not to use a wrapper, so
>>> we could either import / export it or leave it as a mandatory import
>>>
>>> We should really get rid of cglib asap. cglib itself uses asm and we
>>> have our own layer on top of asm.
>>> I don't think we should have a mandatory import on
>>> org.osgi.service.cm, so either find a way to make it optional or
>>> exclude it ?
>>
>> ok
>>
>>>
>>>> Which brings me on to how we're going
>>>> to point users to the dependencies they need in order to get started
>>>> and in particular how this looks on our download page. We could:
>>>> 1) link to the official download URL for each of the dependencies as
>>>> well as link to the uber jar in the Aries dist dir (but users have to
>>>> download them all individually),
>>>> 2) release a zip separate to the uber bundle containing all the
>>>> dependencies and link to that on our downloads page, as well as a link
>>>> to the uber jar in the Aries dist dir,
>>>> 3) #2 but include the uber jar in that zip as well,
>>>> 4) release sample with all the dependencies to run the sample, link to
>>>> that and the uber jar which are both stored in Aries dist dir
>>>>
>>>> Also include a zip of the mini-bundles.
>>>>
>>>> #2 & #4 mean we would be releasing a zip containing jars not developed
>>>> at Apache, so we need do of course need to adhere to the third party
>>>> licensing policy [1]
>>>>
>>>> I favour #4.
>>>>
>>>> What do you all think?
>>>
>>> Three points i'd like to stress:
>>> * we need source distributions for everything we release because
>>> this *is* the official release.
>>
>> +1 absolutely. I've just pulled in the Felix 'release' profile into
>> the Aries parent pom. As a consequence LICENSE and NOTICE files need
>> to be in SVN at every level. So, while adding them in at every
>> 'releaseable' level seems like a manageability issue, I think their
>> presence makes sure we remember that they are there and need to
>> maintained accurately.
>
> I'm not personally very fond of this scheme because it usually does
> not make sense to have a source *distribution* (i.e. something that
> can be build, not the source jar generated by maven) for each module.
Yeah, this makes sense. If it were me I'd want to be able to unzip the
-project.zip, make changes and build it. I think we should have one
-project.zip for each top level module though, not every sub module.
> People interested in the source distribution want to be able to
> change things. And we would still miss the parents and such.
> If we release everything in one go, we should have a single source
> distribution. If we release subsprojects separatly, each subproject
> should have its own source distribution imho.
>
+1
>>
>>> * all the maven modules binary jars will all be available from the
>>> maven repos. Which one we advertise is a different story though.
>>
>> all the files that get installed into a local repo will end up going
>> to the remove repo at this rate. If there really is something that we
>> don't want to publish (and I'm not so convinced about testbundlea,
>> testbundleb and a few others), the we need to decide what to exclude.
>> At the moment we're heading towards publishing everything under a top
>> level module that we're releasing. In order for the -project.zip trick
>> to work (i.e. unzip the -project.zip and you can run mvn, without
>> having to do an svn checkout) then I think we'll need to release the
>> testsupport module.
>>
>> What we release to a maven repo and what we link to from a (new) Aries
>> download page on our web site aren't necessarily the same thing. Zoe
>> has started a page:
>>
>> http://cwiki.apache.org/confluence/display/ARIES/Release%20proposal
>>
>>> * any zip we create as a binary distribution should be part of the
>>> build and not manually generated.
>>
>> +1 ... automation is our friend.
>>
>>>
>>>>
>>>> [1] http://www.apache.org/legal/3party.html
>>>>
>>>> Thanks,
>>>> Jeremy
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: Runtime dependencies for our released artifacts
Posted by Guillaume Nodet <gn...@gmail.com>.
On Thu, Mar 11, 2010 at 16:48, Jeremy Hughes <hu...@apache.org> wrote:
> On 11 March 2010 14:59, Guillaume Nodet <gn...@gmail.com> wrote:
>> On Thu, Mar 11, 2010 at 14:36, Jeremy Hughes <hu...@apache.org> wrote:
>>> Thanks Guillaume for creating the uber bundle for application. I can
>>> see it is a merge of api, management, runtime and utils which is also,
>>> really the minimum set you could use in a runtime. It happens to be a
>>> transitively closed set w.r.t dependencies which is nice for
>>> consumers.
>>
>> Yeah, I would love to add the other optional bits, but I'm stuck
>> because those really should be optional and blueprint has no way to
>> handle that (see the other discussion on the dev list about this exact
>> problem).
>>
>>>
>>> The blueprint uber bundle isn't transitively closed - it needs asm,
>>> cglib, osgi compendium, slf4j,
>>>
>>
>> Import-Package: javax.xml.parsers,javax.xml.transform,javax.xml.transf
>> orm.dom,javax.xml.transform.stream,javax.xml.validation,net.sf.cglib.
>> proxy;resolution:=optional;version="[2.1,3)",org.objectweb.asm;resolu
>> tion:=optional;version="[3.1,4)",org.objectweb.asm.commons;resolution
>> :=optional;version="[3.1,4)",org.osgi.framework;version="[1.5,2)",org
>> .osgi.framework.launch;version="[1.0,2)",org.osgi.service.cm;version=
>> "[1.2.0,2.0.0)",org.osgi.service.event;resolution:=optional;version="
>> [1.2,2)",org.osgi.service.framework;resolution:=optional;version="[1.
>> 0,2)",org.osgi.util.tracker;version="[1.4,2)",org.slf4j;version="[1.5
>> ,2)",org.w3c.dom,org.xml.sax
>>
>> Beyong the core JRE and osgi packages, we have:
>> * cglib : we should get rid of that one
>
> +1 there's a few JIRAs around this but not one to get rid.
>
>> * asm : we should embed it
>
> isn't this where cglib got into trouble. Adding this in just doesn't
> feel very modular!
>
>> * org.osgi.framework.launch : no idea where this one come from, i
>> can't find any reference in the whole project
>
> cool lets remove it
>
>> * org.osgi.service.cm : we should try to make it optional, but we'll
>> have the same problem as for applications
>> * org.osgi.service.event;resolution:=optional : it's optional and ok
>> * org.osgi.service.framework;resolution:=optional : that's for
>> composite bundles, given it's optional it's ok
>> * org.osgi.util.tracker : we may want to embed it
>> * org.slf4j : we discussed that and decided not to use a wrapper, so
>> we could either import / export it or leave it as a mandatory import
>>
>> We should really get rid of cglib asap. cglib itself uses asm and we
>> have our own layer on top of asm.
>> I don't think we should have a mandatory import on
>> org.osgi.service.cm, so either find a way to make it optional or
>> exclude it ?
>
> ok
>
>>
>>> Which brings me on to how we're going
>>> to point users to the dependencies they need in order to get started
>>> and in particular how this looks on our download page. We could:
>>> 1) link to the official download URL for each of the dependencies as
>>> well as link to the uber jar in the Aries dist dir (but users have to
>>> download them all individually),
>>> 2) release a zip separate to the uber bundle containing all the
>>> dependencies and link to that on our downloads page, as well as a link
>>> to the uber jar in the Aries dist dir,
>>> 3) #2 but include the uber jar in that zip as well,
>>> 4) release sample with all the dependencies to run the sample, link to
>>> that and the uber jar which are both stored in Aries dist dir
>>>
>>> Also include a zip of the mini-bundles.
>>>
>>> #2 & #4 mean we would be releasing a zip containing jars not developed
>>> at Apache, so we need do of course need to adhere to the third party
>>> licensing policy [1]
>>>
>>> I favour #4.
>>>
>>> What do you all think?
>>
>> Three points i'd like to stress:
>> * we need source distributions for everything we release because
>> this *is* the official release.
>
> +1 absolutely. I've just pulled in the Felix 'release' profile into
> the Aries parent pom. As a consequence LICENSE and NOTICE files need
> to be in SVN at every level. So, while adding them in at every
> 'releaseable' level seems like a manageability issue, I think their
> presence makes sure we remember that they are there and need to
> maintained accurately.
I'm not personally very fond of this scheme because it usually does
not make sense to have a source *distribution* (i.e. something that
can be build, not the source jar generated by maven) for each module.
People interested in the source distribution want to be able to
change things. And we would still miss the parents and such.
If we release everything in one go, we should have a single source
distribution. If we release subsprojects separatly, each subproject
should have its own source distribution imho.
>
>> * all the maven modules binary jars will all be available from the
>> maven repos. Which one we advertise is a different story though.
>
> all the files that get installed into a local repo will end up going
> to the remove repo at this rate. If there really is something that we
> don't want to publish (and I'm not so convinced about testbundlea,
> testbundleb and a few others), the we need to decide what to exclude.
> At the moment we're heading towards publishing everything under a top
> level module that we're releasing. In order for the -project.zip trick
> to work (i.e. unzip the -project.zip and you can run mvn, without
> having to do an svn checkout) then I think we'll need to release the
> testsupport module.
>
> What we release to a maven repo and what we link to from a (new) Aries
> download page on our web site aren't necessarily the same thing. Zoe
> has started a page:
>
> http://cwiki.apache.org/confluence/display/ARIES/Release%20proposal
>
>> * any zip we create as a binary distribution should be part of the
>> build and not manually generated.
>
> +1 ... automation is our friend.
>
>>
>>>
>>> [1] http://www.apache.org/legal/3party.html
>>>
>>> Thanks,
>>> Jeremy
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Runtime dependencies for our released artifacts
Posted by Alasdair Nottingham <no...@apache.org>.
Sorry I meant embed.
Alasdair
On 12 March 2010 09:04, Guillaume Nodet <gn...@gmail.com> wrote:
> Sorry, I'm not sure to understand. When you say "pulls in", do you
> mean embed or require ?
>
> On Fri, Mar 12, 2010 at 09:57, Alasdair Nottingham <no...@apache.org> wrote:
>> I haven't really been following the chain here about the blueprint
>> uber bundle, but I would like to vote that the blueprint-bundle stay
>> as is, it is the minimum set you need for a compliant implementation.
>> If we have a bundle that pulls in dependencies I think we need a new
>> module for it.
>>
>> Thoughts?
>> Alasdair
>>
>> On 11 March 2010 19:46, Guillaume Nodet <gn...@gmail.com> wrote:
>>> On Thu, Mar 11, 2010 at 19:54, Lin Sun <li...@gmail.com> wrote:
>>>> I think the framework launch may be used by the blueprint extender to
>>>> detect blueprint bundles in child frameworks or the
>>>> AriesBundleTracker, when we detect the framework provides
>>>> CompositeBundleFactory service (which is based on old RFC 138). And
>>>> framework launch packages are provided by the osgi core 4.2 jar. I
>>>> think it is ok if we put it as optional.
>>>
>>> I don't think that's the case. The CompositeBundleFactory and
>>> everything related to composites are in the
>>> org.osgi.service.framework package.
>>> We need to try, but I think it's safe to remove that one.
>>>
>>>>>> * org.osgi.framework.launch : no idea where this one come from, i
>>>>>> can't find any reference in the whole project
>>>>>
>>>>> cool lets remove it
>>>>
>>>>>> * org.osgi.util.tracker : we may want to embed it
>>>>
>>>> This is provided by the osgi companion 4.2 jar.
>>>
>>> Yeah but we're trying to minimize the dependencies. Given it's only a
>>> few classes and not a service we depend on, embedding those would
>>> remove the additional dependency. The problem with the companion jar
>>> is that it is a big jar with optional imports. If you don't deploy
>>> the servlet api for example, the compendium will still resolve, but
>>> later you might run into problems if you want to deploy servlets.
>>> You'd have to refresh your compendium, leading to a restart of all
>>> blueprint applications.
>>> Might be a bit overkill ...
>>>
>>>
>>>> Lin
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>
>>
>>
>> --
>> Alasdair Nottingham
>> not@apache.org
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Alasdair Nottingham
not@apache.org
Re: Runtime dependencies for our released artifacts
Posted by Guillaume Nodet <gn...@gmail.com>.
Sorry, I'm not sure to understand. When you say "pulls in", do you
mean embed or require ?
On Fri, Mar 12, 2010 at 09:57, Alasdair Nottingham <no...@apache.org> wrote:
> I haven't really been following the chain here about the blueprint
> uber bundle, but I would like to vote that the blueprint-bundle stay
> as is, it is the minimum set you need for a compliant implementation.
> If we have a bundle that pulls in dependencies I think we need a new
> module for it.
>
> Thoughts?
> Alasdair
>
> On 11 March 2010 19:46, Guillaume Nodet <gn...@gmail.com> wrote:
>> On Thu, Mar 11, 2010 at 19:54, Lin Sun <li...@gmail.com> wrote:
>>> I think the framework launch may be used by the blueprint extender to
>>> detect blueprint bundles in child frameworks or the
>>> AriesBundleTracker, when we detect the framework provides
>>> CompositeBundleFactory service (which is based on old RFC 138). And
>>> framework launch packages are provided by the osgi core 4.2 jar. I
>>> think it is ok if we put it as optional.
>>
>> I don't think that's the case. The CompositeBundleFactory and
>> everything related to composites are in the
>> org.osgi.service.framework package.
>> We need to try, but I think it's safe to remove that one.
>>
>>>>> * org.osgi.framework.launch : no idea where this one come from, i
>>>>> can't find any reference in the whole project
>>>>
>>>> cool lets remove it
>>>
>>>>> * org.osgi.util.tracker : we may want to embed it
>>>
>>> This is provided by the osgi companion 4.2 jar.
>>
>> Yeah but we're trying to minimize the dependencies. Given it's only a
>> few classes and not a service we depend on, embedding those would
>> remove the additional dependency. The problem with the companion jar
>> is that it is a big jar with optional imports. If you don't deploy
>> the servlet api for example, the compendium will still resolve, but
>> later you might run into problems if you want to deploy servlets.
>> You'd have to refresh your compendium, leading to a restart of all
>> blueprint applications.
>> Might be a bit overkill ...
>>
>>
>>> Lin
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Runtime dependencies for our released artifacts
Posted by Alasdair Nottingham <no...@apache.org>.
I haven't really been following the chain here about the blueprint
uber bundle, but I would like to vote that the blueprint-bundle stay
as is, it is the minimum set you need for a compliant implementation.
If we have a bundle that pulls in dependencies I think we need a new
module for it.
Thoughts?
Alasdair
On 11 March 2010 19:46, Guillaume Nodet <gn...@gmail.com> wrote:
> On Thu, Mar 11, 2010 at 19:54, Lin Sun <li...@gmail.com> wrote:
>> I think the framework launch may be used by the blueprint extender to
>> detect blueprint bundles in child frameworks or the
>> AriesBundleTracker, when we detect the framework provides
>> CompositeBundleFactory service (which is based on old RFC 138). And
>> framework launch packages are provided by the osgi core 4.2 jar. I
>> think it is ok if we put it as optional.
>
> I don't think that's the case. The CompositeBundleFactory and
> everything related to composites are in the
> org.osgi.service.framework package.
> We need to try, but I think it's safe to remove that one.
>
>>>> * org.osgi.framework.launch : no idea where this one come from, i
>>>> can't find any reference in the whole project
>>>
>>> cool lets remove it
>>
>>>> * org.osgi.util.tracker : we may want to embed it
>>
>> This is provided by the osgi companion 4.2 jar.
>
> Yeah but we're trying to minimize the dependencies. Given it's only a
> few classes and not a service we depend on, embedding those would
> remove the additional dependency. The problem with the companion jar
> is that it is a big jar with optional imports. If you don't deploy
> the servlet api for example, the compendium will still resolve, but
> later you might run into problems if you want to deploy servlets.
> You'd have to refresh your compendium, leading to a restart of all
> blueprint applications.
> Might be a bit overkill ...
>
>
>> Lin
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Alasdair Nottingham
not@apache.org
Re: Runtime dependencies for our released artifacts
Posted by Alasdair Nottingham <no...@apache.org>.
If the dependency is in the util bundle then provided that blueprint
imports the AriesBundleTrackerCustomizer from util then blueprint
shouldn't need to depend on org.osgi.framework.launch.
I have a feeling though that the blueprint bundle includes the util
content, so that may be why it gets dragged in.
Alasdair
On 12 March 2010 14:57, Lin Sun <li...@gmail.com> wrote:
> I think the import package of org.osgi.framework.launch came from the
> AriesBundleTrackerCustomizer in util package, as the blueprint
> extender uses it optionally, when detecting the existence of composite
> bundle factory service.
>
> So it should be optional transitive dependency for blueprint, while it
> is currently marked as required, which is incorrect.
>
> Does this sound right?
>
> Lin
>
>
> On Thu, Mar 11, 2010 at 2:46 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>> On Thu, Mar 11, 2010 at 19:54, Lin Sun <li...@gmail.com> wrote:
>>> I think the framework launch may be used by the blueprint extender to
>>> detect blueprint bundles in child frameworks or the
>>> AriesBundleTracker, when we detect the framework provides
>>> CompositeBundleFactory service (which is based on old RFC 138). And
>>> framework launch packages are provided by the osgi core 4.2 jar. I
>>> think it is ok if we put it as optional.
>>
>> I don't think that's the case. The CompositeBundleFactory and
>> everything related to composites are in the
>> org.osgi.service.framework package.
>> We need to try, but I think it's safe to remove that one.
>>
>>>>> * org.osgi.framework.launch : no idea where this one come from, i
>>>>> can't find any reference in the whole project
>>>>
>>>> cool lets remove it
>>>
>>>>> * org.osgi.util.tracker : we may want to embed it
>>>
>>> This is provided by the osgi companion 4.2 jar.
>>
>> Yeah but we're trying to minimize the dependencies. Given it's only a
>> few classes and not a service we depend on, embedding those would
>> remove the additional dependency. The problem with the companion jar
>> is that it is a big jar with optional imports. If you don't deploy
>> the servlet api for example, the compendium will still resolve, but
>> later you might run into problems if you want to deploy servlets.
>> You'd have to refresh your compendium, leading to a restart of all
>> blueprint applications.
>> Might be a bit overkill ...
>>
>>
>>> Lin
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
--
Alasdair Nottingham
not@apache.org
Re: Runtime dependencies for our released artifacts
Posted by Lin Sun <li...@gmail.com>.
I think the import package of org.osgi.framework.launch came from the
AriesBundleTrackerCustomizer in util package, as the blueprint
extender uses it optionally, when detecting the existence of composite
bundle factory service.
So it should be optional transitive dependency for blueprint, while it
is currently marked as required, which is incorrect.
Does this sound right?
Lin
On Thu, Mar 11, 2010 at 2:46 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> On Thu, Mar 11, 2010 at 19:54, Lin Sun <li...@gmail.com> wrote:
>> I think the framework launch may be used by the blueprint extender to
>> detect blueprint bundles in child frameworks or the
>> AriesBundleTracker, when we detect the framework provides
>> CompositeBundleFactory service (which is based on old RFC 138). And
>> framework launch packages are provided by the osgi core 4.2 jar. I
>> think it is ok if we put it as optional.
>
> I don't think that's the case. The CompositeBundleFactory and
> everything related to composites are in the
> org.osgi.service.framework package.
> We need to try, but I think it's safe to remove that one.
>
>>>> * org.osgi.framework.launch : no idea where this one come from, i
>>>> can't find any reference in the whole project
>>>
>>> cool lets remove it
>>
>>>> * org.osgi.util.tracker : we may want to embed it
>>
>> This is provided by the osgi companion 4.2 jar.
>
> Yeah but we're trying to minimize the dependencies. Given it's only a
> few classes and not a service we depend on, embedding those would
> remove the additional dependency. The problem with the companion jar
> is that it is a big jar with optional imports. If you don't deploy
> the servlet api for example, the compendium will still resolve, but
> later you might run into problems if you want to deploy servlets.
> You'd have to refresh your compendium, leading to a restart of all
> blueprint applications.
> Might be a bit overkill ...
>
>
>> Lin
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: Runtime dependencies for our released artifacts
Posted by Valentin Mahrwald <vm...@googlemail.com>.
We only use org.osgi.service.framework.CompositeBundleFactory in
blueprint where "use" is we determine whether the class is available.
So having that package is still necessary but it is fully optional.
As for org.osgi.framework.launch we do not need it. I think we
previously might have needed in some places it because
CompositeBundle.getCompositeFramework() returns an
org.osgi.framework.launch.Framework. However, all this code is now
isolated in org.apache.aries.utils.
Valentin
On 11 Mar 2010, at 19:46, Guillaume Nodet wrote:
> On Thu, Mar 11, 2010 at 19:54, Lin Sun <li...@gmail.com> wrote:
>> I think the framework launch may be used by the blueprint extender to
>> detect blueprint bundles in child frameworks or the
>> AriesBundleTracker, when we detect the framework provides
>> CompositeBundleFactory service (which is based on old RFC 138). And
>> framework launch packages are provided by the osgi core 4.2 jar. I
>> think it is ok if we put it as optional.
>
> I don't think that's the case. The CompositeBundleFactory and
> everything related to composites are in the
> org.osgi.service.framework package.
> We need to try, but I think it's safe to remove that one.
>
>>>> * org.osgi.framework.launch : no idea where this one come from, i
>>>> can't find any reference in the whole project
>>>
>>> cool lets remove it
>>
>>>> * org.osgi.util.tracker : we may want to embed it
>>
>> This is provided by the osgi companion 4.2 jar.
>
> Yeah but we're trying to minimize the dependencies. Given it's only a
> few classes and not a service we depend on, embedding those would
> remove the additional dependency. The problem with the companion jar
> is that it is a big jar with optional imports. If you don't deploy
> the servlet api for example, the compendium will still resolve, but
> later you might run into problems if you want to deploy servlets.
> You'd have to refresh your compendium, leading to a restart of all
> blueprint applications.
> Might be a bit overkill ...
>
>
>> Lin
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
Re: Runtime dependencies for our released artifacts
Posted by Guillaume Nodet <gn...@gmail.com>.
On Thu, Mar 11, 2010 at 19:54, Lin Sun <li...@gmail.com> wrote:
> I think the framework launch may be used by the blueprint extender to
> detect blueprint bundles in child frameworks or the
> AriesBundleTracker, when we detect the framework provides
> CompositeBundleFactory service (which is based on old RFC 138). And
> framework launch packages are provided by the osgi core 4.2 jar. I
> think it is ok if we put it as optional.
I don't think that's the case. The CompositeBundleFactory and
everything related to composites are in the
org.osgi.service.framework package.
We need to try, but I think it's safe to remove that one.
>>> * org.osgi.framework.launch : no idea where this one come from, i
>>> can't find any reference in the whole project
>>
>> cool lets remove it
>
>>> * org.osgi.util.tracker : we may want to embed it
>
> This is provided by the osgi companion 4.2 jar.
Yeah but we're trying to minimize the dependencies. Given it's only a
few classes and not a service we depend on, embedding those would
remove the additional dependency. The problem with the companion jar
is that it is a big jar with optional imports. If you don't deploy
the servlet api for example, the compendium will still resolve, but
later you might run into problems if you want to deploy servlets.
You'd have to refresh your compendium, leading to a restart of all
blueprint applications.
Might be a bit overkill ...
> Lin
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Runtime dependencies for our released artifacts
Posted by Lin Sun <li...@gmail.com>.
I think the framework launch may be used by the blueprint extender to
detect blueprint bundles in child frameworks or the
AriesBundleTracker, when we detect the framework provides
CompositeBundleFactory service (which is based on old RFC 138). And
framework launch packages are provided by the osgi core 4.2 jar. I
think it is ok if we put it as optional.
>> * org.osgi.framework.launch : no idea where this one come from, i
>> can't find any reference in the whole project
>
> cool lets remove it
>> * org.osgi.util.tracker : we may want to embed it
This is provided by the osgi companion 4.2 jar.
Lin
Re: Runtime dependencies for our released artifacts
Posted by Jeremy Hughes <hu...@apache.org>.
On 11 March 2010 14:59, Guillaume Nodet <gn...@gmail.com> wrote:
> On Thu, Mar 11, 2010 at 14:36, Jeremy Hughes <hu...@apache.org> wrote:
>> Thanks Guillaume for creating the uber bundle for application. I can
>> see it is a merge of api, management, runtime and utils which is also,
>> really the minimum set you could use in a runtime. It happens to be a
>> transitively closed set w.r.t dependencies which is nice for
>> consumers.
>
> Yeah, I would love to add the other optional bits, but I'm stuck
> because those really should be optional and blueprint has no way to
> handle that (see the other discussion on the dev list about this exact
> problem).
>
>>
>> The blueprint uber bundle isn't transitively closed - it needs asm,
>> cglib, osgi compendium, slf4j,
>>
>
> Import-Package: javax.xml.parsers,javax.xml.transform,javax.xml.transf
> orm.dom,javax.xml.transform.stream,javax.xml.validation,net.sf.cglib.
> proxy;resolution:=optional;version="[2.1,3)",org.objectweb.asm;resolu
> tion:=optional;version="[3.1,4)",org.objectweb.asm.commons;resolution
> :=optional;version="[3.1,4)",org.osgi.framework;version="[1.5,2)",org
> .osgi.framework.launch;version="[1.0,2)",org.osgi.service.cm;version=
> "[1.2.0,2.0.0)",org.osgi.service.event;resolution:=optional;version="
> [1.2,2)",org.osgi.service.framework;resolution:=optional;version="[1.
> 0,2)",org.osgi.util.tracker;version="[1.4,2)",org.slf4j;version="[1.5
> ,2)",org.w3c.dom,org.xml.sax
>
> Beyong the core JRE and osgi packages, we have:
> * cglib : we should get rid of that one
+1 there's a few JIRAs around this but not one to get rid.
> * asm : we should embed it
isn't this where cglib got into trouble. Adding this in just doesn't
feel very modular!
> * org.osgi.framework.launch : no idea where this one come from, i
> can't find any reference in the whole project
cool lets remove it
> * org.osgi.service.cm : we should try to make it optional, but we'll
> have the same problem as for applications
> * org.osgi.service.event;resolution:=optional : it's optional and ok
> * org.osgi.service.framework;resolution:=optional : that's for
> composite bundles, given it's optional it's ok
> * org.osgi.util.tracker : we may want to embed it
> * org.slf4j : we discussed that and decided not to use a wrapper, so
> we could either import / export it or leave it as a mandatory import
>
> We should really get rid of cglib asap. cglib itself uses asm and we
> have our own layer on top of asm.
> I don't think we should have a mandatory import on
> org.osgi.service.cm, so either find a way to make it optional or
> exclude it ?
ok
>
>> Which brings me on to how we're going
>> to point users to the dependencies they need in order to get started
>> and in particular how this looks on our download page. We could:
>> 1) link to the official download URL for each of the dependencies as
>> well as link to the uber jar in the Aries dist dir (but users have to
>> download them all individually),
>> 2) release a zip separate to the uber bundle containing all the
>> dependencies and link to that on our downloads page, as well as a link
>> to the uber jar in the Aries dist dir,
>> 3) #2 but include the uber jar in that zip as well,
>> 4) release sample with all the dependencies to run the sample, link to
>> that and the uber jar which are both stored in Aries dist dir
>>
>> Also include a zip of the mini-bundles.
>>
>> #2 & #4 mean we would be releasing a zip containing jars not developed
>> at Apache, so we need do of course need to adhere to the third party
>> licensing policy [1]
>>
>> I favour #4.
>>
>> What do you all think?
>
> Three points i'd like to stress:
> * we need source distributions for everything we release because
> this *is* the official release.
+1 absolutely. I've just pulled in the Felix 'release' profile into
the Aries parent pom. As a consequence LICENSE and NOTICE files need
to be in SVN at every level. So, while adding them in at every
'releaseable' level seems like a manageability issue, I think their
presence makes sure we remember that they are there and need to
maintained accurately.
> * all the maven modules binary jars will all be available from the
> maven repos. Which one we advertise is a different story though.
all the files that get installed into a local repo will end up going
to the remove repo at this rate. If there really is something that we
don't want to publish (and I'm not so convinced about testbundlea,
testbundleb and a few others), the we need to decide what to exclude.
At the moment we're heading towards publishing everything under a top
level module that we're releasing. In order for the -project.zip trick
to work (i.e. unzip the -project.zip and you can run mvn, without
having to do an svn checkout) then I think we'll need to release the
testsupport module.
What we release to a maven repo and what we link to from a (new) Aries
download page on our web site aren't necessarily the same thing. Zoe
has started a page:
http://cwiki.apache.org/confluence/display/ARIES/Release%20proposal
> * any zip we create as a binary distribution should be part of the
> build and not manually generated.
+1 ... automation is our friend.
>
>>
>> [1] http://www.apache.org/legal/3party.html
>>
>> Thanks,
>> Jeremy
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: Runtime dependencies for our released artifacts
Posted by Guillaume Nodet <gn...@gmail.com>.
On Thu, Mar 11, 2010 at 14:36, Jeremy Hughes <hu...@apache.org> wrote:
> Thanks Guillaume for creating the uber bundle for application. I can
> see it is a merge of api, management, runtime and utils which is also,
> really the minimum set you could use in a runtime. It happens to be a
> transitively closed set w.r.t dependencies which is nice for
> consumers.
Yeah, I would love to add the other optional bits, but I'm stuck
because those really should be optional and blueprint has no way to
handle that (see the other discussion on the dev list about this exact
problem).
>
> The blueprint uber bundle isn't transitively closed - it needs asm,
> cglib, osgi compendium, slf4j,
>
Import-Package: javax.xml.parsers,javax.xml.transform,javax.xml.transf
orm.dom,javax.xml.transform.stream,javax.xml.validation,net.sf.cglib.
proxy;resolution:=optional;version="[2.1,3)",org.objectweb.asm;resolu
tion:=optional;version="[3.1,4)",org.objectweb.asm.commons;resolution
:=optional;version="[3.1,4)",org.osgi.framework;version="[1.5,2)",org
.osgi.framework.launch;version="[1.0,2)",org.osgi.service.cm;version=
"[1.2.0,2.0.0)",org.osgi.service.event;resolution:=optional;version="
[1.2,2)",org.osgi.service.framework;resolution:=optional;version="[1.
0,2)",org.osgi.util.tracker;version="[1.4,2)",org.slf4j;version="[1.5
,2)",org.w3c.dom,org.xml.sax
Beyong the core JRE and osgi packages, we have:
* cglib : we should get rid of that one
* asm : we should embed it
* org.osgi.framework.launch : no idea where this one come from, i
can't find any reference in the whole project
* org.osgi.service.cm : we should try to make it optional, but we'll
have the same problem as for applications
* org.osgi.service.event;resolution:=optional : it's optional and ok
* org.osgi.service.framework;resolution:=optional : that's for
composite bundles, given it's optional it's ok
* org.osgi.util.tracker : we may want to embed it
* org.slf4j : we discussed that and decided not to use a wrapper, so
we could either import / export it or leave it as a mandatory import
We should really get rid of cglib asap. cglib itself uses asm and we
have our own layer on top of asm.
I don't think we should have a mandatory import on
org.osgi.service.cm, so either find a way to make it optional or
exclude it ?
> Which brings me on to how we're going
> to point users to the dependencies they need in order to get started
> and in particular how this looks on our download page. We could:
> 1) link to the official download URL for each of the dependencies as
> well as link to the uber jar in the Aries dist dir (but users have to
> download them all individually),
> 2) release a zip separate to the uber bundle containing all the
> dependencies and link to that on our downloads page, as well as a link
> to the uber jar in the Aries dist dir,
> 3) #2 but include the uber jar in that zip as well,
> 4) release sample with all the dependencies to run the sample, link to
> that and the uber jar which are both stored in Aries dist dir
>
> Also include a zip of the mini-bundles.
>
> #2 & #4 mean we would be releasing a zip containing jars not developed
> at Apache, so we need do of course need to adhere to the third party
> licensing policy [1]
>
> I favour #4.
>
> What do you all think?
Three points i'd like to stress:
* we need source distributions for everything we release because
this *is* the official release.
* all the maven modules binary jars will all be available from the
maven repos. Which one we advertise is a different story though.
* any zip we create as a binary distribution should be part of the
build and not manually generated.
>
> [1] http://www.apache.org/legal/3party.html
>
> Thanks,
> Jeremy
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com