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 |
> |