Date: Mon, 19 Aug 2002 05:06:44 -0400 From: Dylan Carlson <absinthe@pobox.com> To: Calvin Varney <calvin@varney.org> Cc: freebsd-java@FreeBSD.ORG Subject: Re: Please review: new Java Project docs Message-ID: <200208190506.44212.absinthe@pobox.com> In-Reply-To: <863ctbrcng.fsf@ubana.varney2.org> References: <200208170958.14422.absinthe@pobox.com> <863ctbrcng.fsf@ubana.varney2.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 18 August 2002 07:05pm, Calvin Varney wrote:
> Although you haven't asked for feedback on the documentation section
> I'd like to comment on "4.4. Proposal for Porting Java Applications
> and Tools"
This is great, thank you.
>
> 1. If JAVALIBNAME is defined as ${PORTNAME}-${PORTVERSION} a symlink
> for ${PORTNAME} would be useful for managing dependencies.
I think that should be up to the user to decide which version they want to use
(if they have more than one installed). Either way, that still doesn't mean
anything if $CLASSPATH isn't set correctly.
I don't think we should make any assumptions about which versions should be
symlinked.
>
> 2. Why should Javadocs be treated differently from ordinary
> documentation and placed anywhere other than ${DOCSDIR}? Javadocs
> are just another form of documentation and should be excluded when
> installing ports with NOPORTDOCS.
My opinion on this for what it's worth:
The API docs should be bundled with the rest of the JDK/SDK. I like it when
the JDK is one tree of binaries and docs.
Everything else should be in $DOCSDIR, though.
Agree with you on NOPORTDOCS. However the API docs, like the SDK source code,
have to be manually fetched. Until we have distributables, they probably
should remain as separate ports (jdk13-doc, etc). I'm not sure our license
covers API doc redistribution anyway, so that may never happen.
>
> 3. Regarding placing all library JAR files are in
> ${JAVAPREFIX}/classes/${JAVALIBNAME}/
>
> a. Everything java involves classes. As this is a directory for
> just library classes would "lib" or "import" be a more
> appropriate directory name?
Not sure how this is relevant.
I wouldn't be opposed to changing ${JAVAPREFIX} to ${PREFIX}/lib/java.
Perl, PHP, Python, Ruby all do it this way, basically.
They like us do not want to mix up C libs with Java libs. Segregating that
stuff is a good idea.
>
> b. Placing each library jar under its own ${JAVALIBNAME} directory
> will create many subdirectories with just one jar file (or few
> if different versions are installed). I'd suggest just placing
> them in ${JAVAPREFIX}/classes (or lib or import...). If a
> library includes more than one class file and isn't packaged
> within a jar a ${JAVALIBNAME} subdirectory could be appropriate
> or they could be jared during installation.
Agree with your first sentence. Second is sketchy (see above).
Agree with third, and I'd like to suggest that the proposal gets amended to
require that libraries with multiple classes get built into a JAR file at
install time. That's a good idea, because we can do a lot more with
versioning if all the classes are wrapped up in a JAR. I'm not sure that any
of the Makefiles do JAR version checking but if not we should probably work
in that direction.
Ernst?
>
> c. Is there a need for ${JAVAPREFIX} at all? Why not install
> libraries in ${PREFIX}/share/javalib or
> ${PREFIX}/share/javaimport.
I think it is. It's cleaner to know where all of your java libraries are,
instead of having them mixed up with all the C libraries. Perl operates on
this same basis. I don't want to look at a directory and try to figure out
what is a set of c libs, and what is Java. ${JAVAPREFIX} solves that.
>
> I'm not sure of the intentions behind the additional java in the
> ${PREFIX}/share/java/classes hierarchy. I don't think
> ${PREFIX}/share/java is the right place for docs or examples and
> applications should reside in ${PREFIX}/share or ${PREFIX}. Are
> any other ports installed under a subdirectory denoting their
> implementation language?
Perl: /usr/local/lib/perl5/%interpreter-version%/
PHP: /usr/local/lib/php/
Python: /usr/local/lib/python%ver%/
Ruby: /usr/local/lib/ruby/%interpreter-version%/
...etc...
>
> 4. Is there a need to break away from the existing standard of placing
> examples in ${EXAMPLESDIR} (default:
> ${PREFIX}/share/examples/${PORTNAME})?
Nope, no need. I basically agree with you. Some other languages actually do
it this way: ${PREFIX}/share/exmaples/%lang%/${PORTNAME}
I would suggest:
${PREFIX}/share/examples/java-${JAVAAPIVERSION}/${PORTNAME}
e.g., /usr/local/share/examples/java13/jakarta-oro/
...
I'd like a few of the committers here (Ernst, Greg primarily) to weigh in on
these ideas before I amend the existing proposal. Most of your comments are
agreeable, though, thank you -- if only a few tweaks are (in my opinion)
necessary to mimic how other languages handle their ports.
Cheers,
--
Dylan Carlson [absinthe@pobox.com]
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-java" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200208190506.44212.absinthe>