Gentoo Archives: gentoo-java

From: Martin von Gagern <Martin.vGagern@×××.net>
To: Alistair Bush <ali_bush@g.o>
Cc: gentoo-java@l.g.o
Subject: Re: [gentoo-java] java-pkg-simple and java-mvn-src eclasses
Date: Sat, 03 Jan 2009 09:28:49
Message-Id: 495F2FC2.2040907@gmx.net
In Reply to: Re: [gentoo-java] java-pkg-simple and java-mvn-src eclasses by Alistair Bush
Alistair Bush wrote:
> java-pkg-simple.eclass: > > 1) inherit java-utils-2 (this is required) instead of java-pkg-2. Add > checks to ensure java-pkg-2 is inheritted (so ebuild does it).
I derived my eclass from java-pkg-2 instead of java-utils-2 because conceptually I'm building a java package, so that seemed the right eclass, and because technically I'd like to leverage the magic around JAVA_PKG_IUSE and JAVA_PKG_E_DEPEND without copying the corresponding sections from java-pkg-2.eclass. I now see that if the ebuild also inherits from java-pkg-2, then I would have to copy nothing. It would have to inherit in the right order, htough. If every ebuild using java-pkg-simple.eclass also must inherit java-pkg-2, what is the reason against making that dependency explicit in the eclass? Is that what you mean by making the relationship similar to java-pkg-2 and java-ant-2, as you wrote down there for *.ebuilds?
> 2) create the jar within src_compile, not src install.
I had that in a previous version, and changed it so that ebuilds cann add resources to the target directory before it gets packaged. As an alternative, ebuilds could create the target directory and add resources before calling java-pkg-simple_src_compile in the first place. Would mean one mkdir more in the ebuild, and no check by the eclass that the target directory didn't exist in the archive, which should hold in all sane cases anyway. I could also place the target dir in ${T} to be sure.
> 3) I would like to see var's like JAVA_SRC_DIR(S) so that > java-pkg_dosrc and javadoc could be generated and installed. See what > you can do :)
In most cases ${S} would suffice for this. At least javadoc should take a file list just like javac does (in fact the very same list), so that should be easy. For dosrc you need to indeed catch the root of the source tree. On the other hand, I like your idea about JAVA_SRC_DIR as an argument to find, as it imposes no additional requirements on simple ebuilds but adds flexibility for a bit more complex cases. I'll see that I integrate that with dosrc as well.
> java-mvn-src.eclass: > Have this inherit from java-pkg-simple.eclass
I thought I did. Yes, it says "inherit java-pkg-simple" in the ebuild.
> Im also concerned about how you are attempting to download a single > file from multiple locations. Im told it is valid, but would rather set > it up as a thirdpartymirror.
Technically this would give the same result, but conceptually we are not talking about mirrors here. We have several separate repositories, and the artifact might be located in any one of them, but usually not in all, in contrast to a mirror. I also definitely want to give ebuilds the option to specify the repository. Instead of adding to thirdpartymirror, I guess I'd rather require ebuilds to specify the repository. The way it is now allows for laziness of ebuild writers and for inclusion of content into central repositories at a later point in time.
> *.ebuilds: > inherit java-pkg-2 [java-pkg-simple java-mvn-src]
What do you wish to denote with the brackets? I guess I'll have to inherit java-pkg-2 java-mvn-src if I indeed drop the inherit java-pkg-2 from java-pkg-simple.eclass. Or were you referring to ebuilds in general, not only my two istack ones?
> With the eclasses i'm trying to make them as similar to the layout (and > relationships) of java-pkg-2 and java-ant-2
Is this the reason why java-pkg-simple shouldn't itself inherit java-pkg-2?
> My only concern with "simple eclasses" is it could compile, bundle and > install tests,
You can't take all work from ebuild writers. They either have to remove test code first, choose JAVA_SRC_DIR correctly (once I've introduced it), choose S correctly (i.e. in src/main for common maven-like layout) to eclude tests, or perhaps this eclass simply isn't for them.
> or even more concerning be used to bypass > a "better" build system that includes unit tests, etc, etc.
Depending on circumstances, that might not even be wrong. If the "better" build system is inherently tricky to handle, a simple eclass might be used to get an important package into portage quickly, while more elaborate ebuilds are still being developed. I might add some QA tests, e.g. to have java-pkg-simple complain if it finds a build.xml or pom.xml, or if there sources.lst seems to contain tests (e.g. a subdirectory called test or tests). I'll get back to my eclasses, send you the next iteration soon I guess. Greetings, Martin

Attachments

File name MIME type
signature.asc application/pgp-signature