1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Alistair Bush yazmış: |
5 |
> Ok, things to note and it would be interesting to see whether other |
6 |
> dev's agree with me: |
7 |
> |
8 |
> java-pkg-simple.eclass: |
9 |
> |
10 |
> 1) inherit java-utils-2 (this is required) instead of java-pkg-2. Add |
11 |
> checks to ensure java-pkg-2 is inheritted (so ebuild does it). |
12 |
> 2) create the jar within src_compile, not src install. |
13 |
> 3) I would like to see var's like JAVA_SRC_DIR(S) so that |
14 |
> java-pkg_dosrc and javadoc could be generated and installed. See what |
15 |
> you can do :) |
16 |
> |
17 |
> java-mvn-src.eclass: |
18 |
> Have this inherit from java-pkg-simple.eclass |
19 |
> Im also concerned about how you are attempting to download a single |
20 |
> file from multiple locations. Im told it is valid, but would rather set |
21 |
> it up as a thirdpartymirror. |
22 |
> |
23 |
> *.ebuilds: |
24 |
> inherit java-pkg-2 [java-pkg-simple java-mvn-src] |
25 |
> |
26 |
> With the eclasses i'm trying to make them as similar to the layout (and |
27 |
> relationships) of java-pkg-2 and java-ant-2 |
28 |
> |
29 |
> Martin von Gagern wrote: |
30 |
>> Hi! |
31 |
>> |
32 |
>> I propose two new eclasses. One is for building java packages from their |
33 |
>> *.java source files, without any additional build instructions. The |
34 |
>> second builds on it and is intended for source bundles exported by the |
35 |
>> source:jar goal of Maven2. Two parts of istack-commons can be bumped |
36 |
>> using these, in order to address https://bugs.gentoo.org/188015 . |
37 |
>> |
38 |
>> I would like to commit all of these to java-experimental if there are no |
39 |
>> objectsion. If you leave the Subject in place, I will catch replies to |
40 |
>> this list. Otherwise please Cc me personally, as I don't read every mail |
41 |
>> to the list. |
42 |
>> |
43 |
>> On IRC selckin1 said: "simple eclass to build simple java packages has |
44 |
>> been proposed many times. my main question would be why doesn't it exist |
45 |
>> allready, this been suggested many times going back years, must be a |
46 |
>> reason." Any input on this would be useful as well. |
47 |
> |
48 |
> My only concern with "simple eclasses" is it could compile, bundle and |
49 |
> install |
50 |
> tests, or even more concerning be used to bypass |
51 |
> a "better" build system that includes unit tests, etc, etc. |
52 |
ejunit can be helpful there. But ant suits better imo. We can have a |
53 |
more generic build.xml (possibly included with one of our own tools or |
54 |
created in the eclass itself) and an option for the ebuilds to use their |
55 |
own build.xml files as well (As already done in tree) Having an option |
56 |
to override the default build.xml will help to overcome packages which |
57 |
doesn't fit to generic. But still we should see if there are more |
58 |
generaliations than exceptions. |
59 |
> |
60 |
>> Greetings, |
61 |
>> Martin von Gagern (aka MvG) |
62 |
>> |
63 |
> |
64 |
> |
65 |
> |
66 |
|
67 |
- -- |
68 |
Sincerely, |
69 |
Serkan KABA |
70 |
Gentoo/Java |
71 |
-----BEGIN PGP SIGNATURE----- |
72 |
Version: GnuPG v2.0.9 (GNU/Linux) |
73 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org |
74 |
|
75 |
iEYEARECAAYFAkler+4ACgkQRh6X64ivZaJ0cgCcCJKF8kxr+xpLM/jvQ1gT08zE |
76 |
II0An0kyaMNulk1lUmwzGzSQpcySxbVk |
77 |
=BR4r |
78 |
-----END PGP SIGNATURE----- |