From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1LIzqU-0008PQ-T9 for garchives@archives.gentoo.org; Sat, 03 Jan 2009 06:18:57 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8EF06E049C; Sat, 3 Jan 2009 06:18:46 +0000 (UTC) Received: from mailfilter6.ihug.co.nz (mailfilter6.ihug.co.nz [203.109.136.6]) by pigeon.gentoo.org (Postfix) with ESMTP id AA518E049C for ; Sat, 3 Jan 2009 06:18:45 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMBAC2SXkl2XRV1/2dsb2JhbAAIylyFcoFp X-IronPort-AV: E=Sophos;i="4.36,321,1228042800"; d="scan'208";a="67284757" Received: from 118-93-21-117.dsl.dyn.ihug.co.nz (HELO [10.1.1.3]) ([118.93.21.117]) by smtp.mailfilter6.ihug.co.nz with ESMTP; 03 Jan 2009 19:18:37 +1300 Message-ID: <495F0333.3090009@gentoo.org> Date: Sat, 03 Jan 2009 19:18:27 +1300 From: Alistair Bush User-Agent: Thunderbird 2.0.0.19 (X11/20090102) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-java@lists.gentoo.org MIME-Version: 1.0 To: gentoo-java@lists.gentoo.org Subject: Re: [gentoo-java] java-pkg-simple and java-mvn-src eclasses References: <495E0DC5.7050208@gmx.net> <495EA94D.1020608@gentoo.org> <495EAFEE.20405@gentoo.org> In-Reply-To: <495EAFEE.20405@gentoo.org> X-Enigmail-Version: 0.95.7 OpenPGP: url= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 1f1de103-8065-460a-ba01-11f33694887e X-Archives-Hash: 34eb020d9d34e709aca41ef3641d450d 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) >>> > > >