incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niall Pemberton <>
Subject Re: [DISCUSS] Sanselan as a Commons library
Date Fri, 24 Apr 2009 20:16:28 GMT
On Sun, Apr 19, 2009 at 9:59 AM, Jeremias Maerki <> wrote:
> On 18.04.2009 22:03:53 Jochen Wiedmann wrote:
>> Hi, Craig,
>> I'm personally not sure that commons would be the best fit for
>> Sanselan. Despite the name, I'd consider the commons of xmlgraphics
>> (despite the name, this is not only about XML) a better place.
> I thought along similar lines but the problem is as follows: XML
> Graphics currently doesn't use Sanselan. It currently does not offer
> anything that we don't already have or need. If it had a 100% Java JPEG
> decoder or a JBIG2 codec, that would be different. Also, XML Graphics
> barely has enough energy to keep itself afloat. I don't think there's
> going to be large enthusiasm to integrate Sanselan as further subproject.
> That said, I'm personally not opposed to include Sanselan in XML
> Graphics but don't expect much help from any of the project members. I'm
> just being realistic.
>> Nevertheless, I'd vote in favour of Sanselan, if it comes to that.
>> On Fri, Apr 17, 2009 at 11:17 PM, Craig L Russell <> wrote:
>> > 1. It appears that dev@commons is the general mailing list for all commons
>> > projects. Would a small project like sanselan get lost in the traffic?
>> That's a problem that every part of Commons has. And another reason,
>> why you could possibly prefer the above place: No doubt, commons-dev
>> is relatively high volume. I am not sure, whether the shared mailing
>> list is the best solution, but I wouldn't like to have that discussion
>> in this context. As already said, it applies to every part and isn't
>> specific to Sanselan.
> Right. That's my problem with Commons as a whole. By some it is
> presented as an advantage, but I see it as the opposite. But this is how
> Commons currently works and I don't see that changing, so if Sanselan
> went down that road, it would have to live with it. I guess it's mainly
> Charles (the original author and single active committer) who has to be
> comfortable with this.

Commons manages to function with small groups of developers for each
component by the wider community providing oversight. Without this
many (most?) components would face a perpetual challenge in getting
the necessary 3 +1 votes to do anything (see
). Part of what makes this shared responsibility work IMO is that
there are no barriers between components and there is a single
community which operates on shared mailing lists. If we had 30+
mailing lists (for each component) then it may make following topics
for a particular component easier, but I'm sure we would loose on
community oversight.

Also by convention we prefix the subject of email messages with the
name of the component and its pretty straight forward to filter by
component if someone wants to.

>> > 2. Most commons components have a "functional" name instead of a "fun" name.
>> > Would Sanselan need to be renamed, e.g. Commons Image, or would it be ok to
>> > have the sub-project called Sanselan, or Commons Sanselan?
>> IMO, no. I am unaware of an existing example without the commons
>> prefix, but what gives.
> I guess it would automatically be Commons Sanselan, but it would
> probably still just be referred to as just Sanselan. I don't think
> that's so important.
>> > 3. Would any changes be required from the existing packaging of Sanselan?
>> > For example, packages are named org.apache.sanselan. Would these need to be
>> > renamed to org.apache.commons.sanselan (or less fun name as above)?
>> Definitely no. I am not even sure, whether there is *any* existing
>> part of commons with the org.apache.commons prefix. OTOH, I am quite
>> sure that there are lots of examples without.
> I agree, that shouldn't be necessary. Another package change doesn't
> feel right.

Its preferable IMO, but not a requirement.


> Jeremias Maerki

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message