Gentoo Archives: gentoo-java

From: Alistair Bush <ali_bush@g.o>
To: gentoo-java@l.g.o
Subject: Re: [gentoo-java] java-pkg-simple and java-mvn-src eclasses
Date: Sat, 03 Jan 2009 06:18:57
Message-Id: 495F0333.3090009@gentoo.org
In Reply to: Re: [gentoo-java] java-pkg-simple and java-mvn-src eclasses by Serkan Kaba
Serkan Kaba wrote:
> Alistair Bush yazm1_: >> Ok, things to note and it would be interesting to see whether other >> dev's agree with me: > >> 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). >> 2) create the jar within src_compile, not src install. >> 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 :) > >> java-mvn-src.eclass: >> Have this inherit from java-pkg-simple.eclass >> 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. > >> *.ebuilds: >> inherit java-pkg-2 [java-pkg-simple java-mvn-src] > >> With the eclasses i'm trying to make them as similar to the layout (and >> relationships) of java-pkg-2 and java-ant-2 > >> Martin von Gagern wrote: >>> Hi! >>> >>> I propose two new eclasses. One is for building java packages from their >>> *.java source files, without any additional build instructions. The >>> second builds on it and is intended for source bundles exported by the >>> source:jar goal of Maven2. Two parts of istack-commons can be bumped >>> using these, in order to address https://bugs.gentoo.org/188015 . >>> >>> I would like to commit all of these to java-experimental if there are no >>> objectsion. If you leave the Subject in place, I will catch replies to >>> this list. Otherwise please Cc me personally, as I don't read every mail >>> to the list. >>> >>> On IRC selckin1 said: "simple eclass to build simple java packages has >>> been proposed many times. my main question would be why doesn't it exist >>> allready, this been suggested many times going back years, must be a >>> reason." Any input on this would be useful as well. >> My only concern with "simple eclasses" is it could compile, bundle and >> install >> tests, or even more concerning be used to bypass >> a "better" build system that includes unit tests, etc, etc. > ejunit can be helpful there. But ant suits better imo. We can have a > more generic build.xml (possibly included with one of our own tools or > created in the eclass itself) and an option for the ebuilds to use their > own build.xml files as well (As already done in tree) Having an option > to override the default build.xml will help to overcome packages which > doesn't fit to generic. But still we should see if there are more > generaliations than exceptions.
I think you misunderstand where im coming from. ejunit is going to run the unit tests. my problem isn't running them, it is then being compiled within src_compile and ending up within the resulting jar file in the first place. java-pkg-simple_src_compile just runs `find * -name \*.java > sources.lst` to find all the *.java files. even in they are with directories src/test, test or JAVA_FILES_DO_NOT_COMPILE directory. Why I like the JAVA_SRC_DIR ( or whatever ) variable is then at least we could go and do something like find ${JAVA_SRC_DIR} -name \*.java > source.lst as long as we don't quote JAVA_SRC_DIR I believe it should work. The eclass/default build.xml is also another option that has been thrown around for a while either.
>>> Greetings, >>> Martin von Gagern (aka MvG) >>> > > >