Port/package guidelines (WAS: Please review: new Java Project docs)

Port/package guidelines (WAS: Please review: new Java Project docs)

Post by Dylan Carls » Fri, 23 Aug 2002 17:45:41

As a prelude to continuing this conversation, I believe we probably should
start figuring out how to use Ant in all the Java ports to resolve
dependencies, build jars, do versioning and so on.   I would like Ernst to
comment on this, since he does the majority of the Java-related ports
(including Ant).  

It's definitely a more sane way of building and packaging Java (particularly
generating javadocs from code that has it) ... but I also think it would be
an improved way of doing version checking and upgrades.  Take a lot of the
work out of the Makefile and into the build.xml's.

My $.02...


> I would have thought the latest minor version of a library
> libname.majorver.minorver linked to libname.majorver Thats assuming
> library interfaces don't change between minor versions. (how safe is
> that?)

In theory, there shouldn't be an interface change on a library on a minor
release, but... anyway it's probably safe to do it that way for now.   I
think long-term we need to pursue something more evolved with a tool like
Ant.  That way we won't have to deal with filenames, we deal with internal
version numbers of JARs and classes.

FYI, the standard bsd.port.mk/java.mk files don't deal with major/minor
versioning.  All you get is ${PORTVERSION}.

Most developers I know have a canned development directory tree somewhere (not
in ${PREFIX).    I don't think the target audience for a java library port is
a developer... it's probably just to resolve a dependency for an application.

By that reasoning think it's probably a good idea to write wrapper scripts for
applications to set the CLASSPATH as needed, where it has not already been

Quote:> Ok, the SDK API docs must remain a separate port. I was concerned
> about the API documentation produced by javadoc for other ports
> (libraries and applications) ending up somewhere other than $DOCSDIR.

No, I agree about that.  $DOCSDIR is good by me.

Quote:> Great, for consistency ${PREFIX}/lib/java has my vote. Interesting to
> note the likes of perl and php libraries aren't located under
> ${PREFIX}/share as architecture-independent files though.


Quote:> > 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.

> I'd support this.


OK, so I want some next steps on revising the proposal, final comments and
whatever.  To to be clear where we're currently at... I have just tried to
phrase this a little differently than we discussed but basically keeping the
final results the same.

        remove ${JAVAPREFIX}
        ${JAVALIBDIR} = ${PREFIX}/lib/java
        ${JAVAPORTNAME} = %portname%-%majorversion%
        ${PORTNAME} = %portname%-%fullversion% (as usual)

        1.  preferably in .JAR format: ${JAVALIBDIR}/${JAVAPORTNAME}.jar
        2.  or in a subdirectory: ${JAVALIBDIR}/${JAVAPORTNAME}/
        no symlinks

DOCS, including Javadoc generated:



> Would also like to here form those with more porting experience. I've
> just started trying to port a couple of java apps and have found it
> tough going trying to nut out what goes where and how to handle common
> libraries.

Ernst is The Man.   He can probably answer all of those questions.

Being that he has his name on most of the ports at present (correct me if I'm
wrong about this), I think he's got the the most weight on this final

What has been discussed here is reasonable I think, unless Ernst has some
rationale for things we've overlooked or just plain don't understand.

Folks, let me know what your final thoughts are on the above and maybe we can
get something codified.


with "unsubscribe freebsd-java" in the body of the message


1. Port/package guidelines (WAS: Please review: new Java Project docs)

Dylan, you are right. We should move to Ant. This has been proposed and
discussed before, but never actually taken to the next level, i.e. a working
example. Currently a very small number of ports seems to use Ant:


for the other two. These ports, however, don't even serve as a good example,
because they only use the buildfile that comes with the library being

Initial suggestion:

o An Ant-based port sets USE_ANT=YES which is interpreted by

Now that's a lot, isn't it? ;-) Questions that arise immediately are:

o Should the port come with a build.xml file or should it set some
  properties that will allow us to _generate_ a build.xml file for
o If the port comes with a build.xml file, then should it have some
  default targets?
o How do we install any JAR files, source code, Javadoc API documentation,
  etc in a standard manner?

/me hopes this will ignite the discussion and shine some light on
this subject which remains a bit vague and distorted in his head


with "unsubscribe freebsd-java" in the body of the message

2. 3Com 3CCFEM556B: Any hope for a driver soon?

3. Port/package guidelines (WAS: Please review: new Java Project

4. Uptime 460 days for

5. Please review: new Java Project docs

6. HP Deskjet 520 Printing Problem

7. New ports: java/jdkXX-doc

8. xfig and XF2.1 (bug in XF2.1)

9. java/43981: java/jdk1?-doc ports should dynamically generate plist file

10. Port/package guidelines (Ant)

11. ports/42449: New port: jakarta-log4j, a logging library for java

12. What happened to blackdown.org (Java-Linux porting project?)

13. Java, Java, Java, Java, Java, Java .....