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
1 Serkan Kaba wrote:
2 > Alistair Bush yazm1_:
3 >> Ok, things to note and it would be interesting to see whether other
4 >> dev's agree with me:
5 >
6 >> java-pkg-simple.eclass:
7 >
8 >> 1) inherit java-utils-2 (this is required) instead of java-pkg-2. Add
9 >> checks to ensure java-pkg-2 is inheritted (so ebuild does it).
10 >> 2) create the jar within src_compile, not src install.
11 >> 3) I would like to see var's like JAVA_SRC_DIR(S) so that
12 >> java-pkg_dosrc and javadoc could be generated and installed. See what
13 >> you can do :)
14 >
15 >> java-mvn-src.eclass:
16 >> Have this inherit from java-pkg-simple.eclass
17 >> Im also concerned about how you are attempting to download a single
18 >> file from multiple locations. Im told it is valid, but would rather set
19 >> it up as a thirdpartymirror.
20 >
21 >> *.ebuilds:
22 >> inherit java-pkg-2 [java-pkg-simple java-mvn-src]
23 >
24 >> With the eclasses i'm trying to make them as similar to the layout (and
25 >> relationships) of java-pkg-2 and java-ant-2
26 >
27 >> Martin von Gagern wrote:
28 >>> Hi!
29 >>>
30 >>> I propose two new eclasses. One is for building java packages from their
31 >>> *.java source files, without any additional build instructions. The
32 >>> second builds on it and is intended for source bundles exported by the
33 >>> source:jar goal of Maven2. Two parts of istack-commons can be bumped
34 >>> using these, in order to address https://bugs.gentoo.org/188015 .
35 >>>
36 >>> I would like to commit all of these to java-experimental if there are no
37 >>> objectsion. If you leave the Subject in place, I will catch replies to
38 >>> this list. Otherwise please Cc me personally, as I don't read every mail
39 >>> to the list.
40 >>>
41 >>> On IRC selckin1 said: "simple eclass to build simple java packages has
42 >>> been proposed many times. my main question would be why doesn't it exist
43 >>> allready, this been suggested many times going back years, must be a
44 >>> reason." Any input on this would be useful as well.
45 >> My only concern with "simple eclasses" is it could compile, bundle and
46 >> install
47 >> tests, or even more concerning be used to bypass
48 >> a "better" build system that includes unit tests, etc, etc.
49 > ejunit can be helpful there. But ant suits better imo. We can have a
50 > more generic build.xml (possibly included with one of our own tools or
51 > created in the eclass itself) and an option for the ebuilds to use their
52 > own build.xml files as well (As already done in tree) Having an option
53 > to override the default build.xml will help to overcome packages which
54 > doesn't fit to generic. But still we should see if there are more
55 > generaliations than exceptions.
56
57 I think you misunderstand where im coming from.
58
59 ejunit is going to run the unit tests. my problem isn't running them,
60 it is then being compiled within src_compile and ending up within the
61 resulting jar file in the first place.
62
63 java-pkg-simple_src_compile just runs `find * -name \*.java >
64 sources.lst` to find all the *.java files. even in they are with
65 directories src/test, test or JAVA_FILES_DO_NOT_COMPILE directory.
66
67 Why I like the JAVA_SRC_DIR ( or whatever ) variable is then at least we
68 could go and do something like
69
70 find ${JAVA_SRC_DIR} -name \*.java > source.lst
71
72 as long as we don't quote JAVA_SRC_DIR I believe it should work.
73
74 The eclass/default build.xml is also another option that has been thrown
75 around for a while either.
76
77 >>> Greetings,
78 >>> Martin von Gagern (aka MvG)
79 >>>
80 >
81 >
82 >