by 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...
In theory, there shouldn't be an interface change on a library on a minorQuote:> 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?)
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
done.
No, I agree about that. $DOCSDIR is good by me.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.
Agree.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.
*nod*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.
VARIABLES:
remove ${JAVAPREFIX}
${JAVALIBDIR} = ${PREFIX}/lib/java
${JAVAPORTNAME} = %portname%-%majorversion%
${PORTNAME} = %portname%-%fullversion% (as usual)
LIBRARIES:
1. preferably in .JAR format: ${JAVALIBDIR}/${JAVAPORTNAME}.jar
2. or in a subdirectory: ${JAVALIBDIR}/${JAVAPORTNAME}/
no symlinks
DOCS, including Javadoc generated:
${DOCSDIR}/${JAVAPORTNAME}
EXAMPLES:
${EXAMPLESDIR}/java/${JAVAPORTNAME}
Ernst is The Man. He can probably answer all of those questions.Quote:> 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.
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
proposal.
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.
Cheers,
--
with "unsubscribe freebsd-java" in the body of the message