Re: A packaging scheme...
Okay, having said this won't be a debian requirement, I'm much
more comfortable discussing this at its merits, instead of arguing against
unnecessary incompatibility.
On Wed, Sep 29, 1999 at 12:00:13PM -0500, Ean R . Schuessler wrote:
> On Wed, Sep 29, 1999 at 01:08:22PM -0400, Seth M. Landsman wrote:
> > However, are programmers who write this software going to be
> > willing to do this? I can't see gnu going with gpl.gnu and lgpl.gnu as
> > their top level, nor can I see mozilla willing change to mpl.mozilla with
> > all of their software.
>
> That would defeat the purpose. The idea is functional divisions instead of
> organizational divisions. In fact, the license prefix could be dropped in
> favor of something like "lib". The thing is, even Sun doesn't follow their
> own policy when it comes to most of the libraries. There is almost nothing
> that is packaged under com.sun.* and the things that are you are advised
> not to use.
Yes and no. Sun has defined the API, which goes under java.* and
the extended api, which goes under javax.*. However, they do define
com.sun classes and net.jini classes, which do follow their definition.
I've found it very useful, very often, to be able to have several
packages in my classpath, all of which define the same classes, but have
different qualified names.
> What I am gunning at here is that it is stupid to divide the components of
> a common library by organization. Let's say that you are writing an XML
> program and are using classes from several different organizations. Having
> to deal with classes coming out of: com.ibm.xml.xena.*, com.jclark.xml.sax.*,
> etc., etc., etc. gets a little confusing. That isn't the way the AWT is, or
> java.sql.* or java.util.*. Why is it that only Sun should provide consolidated
> functionality? How much nicer would it be to have a lib.xml.* infrastructure
> that was as integrated as java.sql.* or any of the other Sun packages?
Hmm, so there is one true regex package? Who writes it? i.e.,
lib.regex.* is going to be real difficult, since there are around five
regex classes out there. How does this deal with that issue?
The problem is that the classpath mechanism, for good or bad,
really does require well qualified package names that won't clash. I do
not want to change my classpath depending on whose regex library I use.
I'd much rather talk about that library specifically.
> > The thing is, Sun created a policy which makes a good deal of
> > sense, which people decided to follow and support. It makes it real easy
> > to figure out where a piece of software came from and to ensure that there
> > won't be namespace conflicts. I fear that adding the license is
> > unnecessarily political and won't make sense to the vast majority of java
> > coders out there.
>
> Again, Sun created a sensible policy that they themselves do not follow for
> the bulk of their own code.
But lots of other people do. Sun does follow it outside of the
defined API. I think this particular argument is a fallacy of authority.
-Seth
--
"It is by will alone I set my mind in motion"
Reply to: