pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Brind <bri...@brindy.org.uk>
Subject Re: When are you going to move packages to org.apache.pivot?
Date Fri, 05 Jun 2009 13:18:38 GMT
I'm afraid I'm in favour of the full reverse domain name convention.  When
in Rome and all that.  If I was doing .NET (which I don't and hopefully will
never have to) then I would adopt their conventions.

I also believe org.apache.pivot is stronger and lends more credibility to
the project than 'pivot' alone, especially considering that I've known Pivot
while it has existed on at least two other hosting solutions (dev.java.netand
code.google.com).  By adopting the namespace we're putting a flag in the
ground and saying "This is it people! We're Apache and we're comitted to
being Apache moving forward.".  Developers will have no fear of trying it
out - especially post incubation.  Once they see the package name it'll give
them a lot of confidence, without org.apache it will make them cautious.

As for the 'replacement' classes, take pivot.collections - to be honest, I
don't see what the classes in that package have to do with an RIA.  Given
that they are designed to compete with Java's collections classes then
really they should be in their own project, e.g. Apache Commons?   This
would give them even more credibility as a replacement for the platform
collections instead of being burried in an RIA project.

Also, I'm afraid to say that if we want to compete with the platform classes
we need much stronger impirical evidence that our classes are effective and
effecient - unit tests are the way to do that, I feel.

What I'm trying to say in the last two paragraphs really is that in actual
fact the namespace of the 'replacement' classes is probably irrelevant to
their adoption.  Proven use and impirical evidence is what will encourage


2009/6/5 Greg Brown <gkbrown@mac.com>

> java and javax are reserved namespaces for platform classes, so I
>> don't see their relevance here.
> The relevance is that Pivot's classes are meant to replace many of these
> platform classes, and should therefore be given equal billing.
>  Regarding "outdated"... not using the reversed fully qualified domain
>> name was the way old projects named their packages. That is the
>> outdated variety. Even junit, which is has been around since the early
>> days has converted to org.junit.
> I'm suggesting that the TLD prefix is outdated. I'd much prefer "junit.*"
> to "org.junit.*", for example. How likely is a project to use classes from
> "org.junit" and "com.junit" at the same time (if the latter even existed)?
> IMO, not very. I'm assuming that's why Microsoft dropped the convention when
> they came up with the C# coding standards.
>  I don't see pivot.* being any less official than org.apache.pivot.*.
>> You have the full might of Apache there, and there's no need to have
>> to type in those package names anymore with current IDEs.
> I understand that this is a minor distinction, but Sun's naming guidelines
> make any classes not developed by Sun for the java(x).* package seem like
> second-class citizens. It's hard enough as it is to convince developers to
> use Pivot instead of the "official" UI toolkits provided by Sun. Why make it
> any more difficult than it needs to be?
> OTOH, it is worth asking the question of whether or not the "pivot.*"
> naming convention might actually make a developer *less* likely to use
> Pivot. For better or worse, TLD naming is an established convention, and
> going against the grain may provide some developers with another reason
> *not* to use Pivot.
> What do others think?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message