You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@abdera.apache.org by James M Snell <ja...@gmail.com> on 2007/08/20 20:57:30 UTC
Extensions module: one jar or many?
The extensions module is growing. This is a good thing :-). Currently,
a single extensions jar is built that contains all of the extensions.
This makes distribution and deployment easy but requires that folks ship
code that they are potentially not using. One possible solution is to
generate multiple extension jars (one per extension). I have no real
preference either way. What say y'all?
- James
Re: Extensions module: one jar or many?
Posted by Jim Alateras <ji...@comware.com.au>.
James M Snell wrote:
> The extensions module is growing. This is a good thing :-). Currently,
> a single extensions jar is built that contains all of the extensions.
> This makes distribution and deployment easy but requires that folks ship
> code that they are potentially not using. One possible solution is to
> generate multiple extension jars (one per extension). I have no real
> preference either way. What say y'all?
>
i prefer the latter.
cheers
</jima>
Re: Extensions module: one jar or many?
Posted by Brian Moseley <bc...@osafoundation.org>.
On 8/20/07, James M Snell <ja...@gmail.com> wrote:
> The extensions module is growing. This is a good thing :-). Currently,
> a single extensions jar is built that contains all of the extensions.
> This makes distribution and deployment easy but requires that folks ship
> code that they are potentially not using. One possible solution is to
> generate multiple extension jars (one per extension). I have no real
> preference either way. What say y'all?
i generally prefer smaller, more focused jars, especially when i'm
repackaging them in an application that my users have to download, so
i'm +1 to breaking the extensions up into separate jars.
Re: Extensions module: one jar or many?
Posted by Stephen Duncan <st...@gmail.com>.
Sounds reasonable.
-Stephen
On 8/20/07, James M Snell <ja...@gmail.com> wrote:
>
> Perhaps all extensions that have an associated Internet-Draft or RFC can
> be bundled into a single core extension module; the rest can go into
> individual jars (e.g. a geo jar, an opensearch jar, etc)
>
> - James
>
> Stephen Duncan wrote:
> > +1
> >
> > I think I'd prefer that any extensions with minimal (no non-Abdera?)
> > dependencies & for a open-standard (not vendor-specific) extension stay
> > together as a core extensions jar. Or perhaps if there's a logical
> > difference between things like bidi & thread vs. opensearch in terms of
> type
> > of extension or scope?
> >
> > -Stephen
> >
> > On 8/20/07, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> >> On 8/20/07, James M Snell <ja...@gmail.com> wrote:
> >>> The extensions module is growing. This is a good thing
> :-). Currently,
> >>> a single extensions jar is built that contains all of the extensions.
> >>> This makes distribution and deployment easy but requires that folks
> ship
> >>> code that they are potentially not using. One possible solution is to
> >>> generate multiple extension jars (one per extension). I have no real
> >>> preference either way. What say y'all?
> >> Alternatively we could split the difference, have a core set of
> >> extensions that go in a main jar, then split out others. Possible
> >> criteria for splitting something out might be that it's new and
> >> experimental, or that it depends on external code in a manner that's
> >> irritating to users (i.e. if I have to pull in a gigantic third party
> >> dependency just for having something around, I'd like it to be a
> >> separate jar, although I suppose this is largely my C background
> >> talking, and such things don't happen as much in Java land).
> >>
> >> -garrett
> >>
> >
> >
> >
>
--
Stephen Duncan Jr
www.stephenduncanjr.com
Re: Extensions module: one jar or many?
Posted by Jim Alateras <ji...@comware.com.au>.
James M Snell wrote:
> Perhaps all extensions that have an associated Internet-Draft or RFC can
> be bundled into a single core extension module; the rest can go into
> individual jars (e.g. a geo jar, an opensearch jar, etc)
>
+1
cheers
</jima>
Re: Extensions module: one jar or many?
Posted by James M Snell <ja...@gmail.com>.
Perhaps all extensions that have an associated Internet-Draft or RFC can
be bundled into a single core extension module; the rest can go into
individual jars (e.g. a geo jar, an opensearch jar, etc)
- James
Stephen Duncan wrote:
> +1
>
> I think I'd prefer that any extensions with minimal (no non-Abdera?)
> dependencies & for a open-standard (not vendor-specific) extension stay
> together as a core extensions jar. Or perhaps if there's a logical
> difference between things like bidi & thread vs. opensearch in terms of type
> of extension or scope?
>
> -Stephen
>
> On 8/20/07, Garrett Rooney <ro...@electricjellyfish.net> wrote:
>> On 8/20/07, James M Snell <ja...@gmail.com> wrote:
>>> The extensions module is growing. This is a good thing :-). Currently,
>>> a single extensions jar is built that contains all of the extensions.
>>> This makes distribution and deployment easy but requires that folks ship
>>> code that they are potentially not using. One possible solution is to
>>> generate multiple extension jars (one per extension). I have no real
>>> preference either way. What say y'all?
>> Alternatively we could split the difference, have a core set of
>> extensions that go in a main jar, then split out others. Possible
>> criteria for splitting something out might be that it's new and
>> experimental, or that it depends on external code in a manner that's
>> irritating to users (i.e. if I have to pull in a gigantic third party
>> dependency just for having something around, I'd like it to be a
>> separate jar, although I suppose this is largely my C background
>> talking, and such things don't happen as much in Java land).
>>
>> -garrett
>>
>
>
>
Re: Extensions module: one jar or many?
Posted by Stephen Duncan <st...@gmail.com>.
+1
I think I'd prefer that any extensions with minimal (no non-Abdera?)
dependencies & for a open-standard (not vendor-specific) extension stay
together as a core extensions jar. Or perhaps if there's a logical
difference between things like bidi & thread vs. opensearch in terms of type
of extension or scope?
-Stephen
On 8/20/07, Garrett Rooney <ro...@electricjellyfish.net> wrote:
>
> On 8/20/07, James M Snell <ja...@gmail.com> wrote:
> > The extensions module is growing. This is a good thing :-). Currently,
> > a single extensions jar is built that contains all of the extensions.
> > This makes distribution and deployment easy but requires that folks ship
> > code that they are potentially not using. One possible solution is to
> > generate multiple extension jars (one per extension). I have no real
> > preference either way. What say y'all?
>
> Alternatively we could split the difference, have a core set of
> extensions that go in a main jar, then split out others. Possible
> criteria for splitting something out might be that it's new and
> experimental, or that it depends on external code in a manner that's
> irritating to users (i.e. if I have to pull in a gigantic third party
> dependency just for having something around, I'd like it to be a
> separate jar, although I suppose this is largely my C background
> talking, and such things don't happen as much in Java land).
>
> -garrett
>
--
Stephen Duncan Jr
www.stephenduncanjr.com
Re: Extensions module: one jar or many?
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 8/20/07, James M Snell <ja...@gmail.com> wrote:
> The extensions module is growing. This is a good thing :-). Currently,
> a single extensions jar is built that contains all of the extensions.
> This makes distribution and deployment easy but requires that folks ship
> code that they are potentially not using. One possible solution is to
> generate multiple extension jars (one per extension). I have no real
> preference either way. What say y'all?
Alternatively we could split the difference, have a core set of
extensions that go in a main jar, then split out others. Possible
criteria for splitting something out might be that it's new and
experimental, or that it depends on external code in a manner that's
irritating to users (i.e. if I have to pull in a gigantic third party
dependency just for having something around, I'd like it to be a
separate jar, although I suppose this is largely my C background
talking, and such things don't happen as much in Java land).
-garrett