1 |
Alistair Bush wrote: |
2 |
> java-pkg-simple.eclass: |
3 |
> |
4 |
> 1) inherit java-utils-2 (this is required) instead of java-pkg-2. Add |
5 |
> checks to ensure java-pkg-2 is inheritted (so ebuild does it). |
6 |
|
7 |
I derived my eclass from java-pkg-2 instead of java-utils-2 because |
8 |
conceptually I'm building a java package, so that seemed the right |
9 |
eclass, and because technically I'd like to leverage the magic around |
10 |
JAVA_PKG_IUSE and JAVA_PKG_E_DEPEND without copying the corresponding |
11 |
sections from java-pkg-2.eclass. |
12 |
|
13 |
I now see that if the ebuild also inherits from java-pkg-2, then I would |
14 |
have to copy nothing. It would have to inherit in the right order, |
15 |
htough. If every ebuild using java-pkg-simple.eclass also must inherit |
16 |
java-pkg-2, what is the reason against making that dependency explicit |
17 |
in the eclass? Is that what you mean by making the relationship similar |
18 |
to java-pkg-2 and java-ant-2, as you wrote down there for *.ebuilds? |
19 |
|
20 |
> 2) create the jar within src_compile, not src install. |
21 |
|
22 |
I had that in a previous version, and changed it so that ebuilds cann |
23 |
add resources to the target directory before it gets packaged. As an |
24 |
alternative, ebuilds could create the target directory and add resources |
25 |
before calling java-pkg-simple_src_compile in the first place. Would |
26 |
mean one mkdir more in the ebuild, and no check by the eclass that the |
27 |
target directory didn't exist in the archive, which should hold in all |
28 |
sane cases anyway. I could also place the target dir in ${T} to be sure. |
29 |
|
30 |
> 3) I would like to see var's like JAVA_SRC_DIR(S) so that |
31 |
> java-pkg_dosrc and javadoc could be generated and installed. See what |
32 |
> you can do :) |
33 |
|
34 |
In most cases ${S} would suffice for this. At least javadoc should take |
35 |
a file list just like javac does (in fact the very same list), so that |
36 |
should be easy. For dosrc you need to indeed catch the root of the |
37 |
source tree. |
38 |
|
39 |
On the other hand, I like your idea about JAVA_SRC_DIR as an argument to |
40 |
find, as it imposes no additional requirements on simple ebuilds but |
41 |
adds flexibility for a bit more complex cases. I'll see that I integrate |
42 |
that with dosrc as well. |
43 |
|
44 |
> java-mvn-src.eclass: |
45 |
> Have this inherit from java-pkg-simple.eclass |
46 |
|
47 |
I thought I did. Yes, it says "inherit java-pkg-simple" in the ebuild. |
48 |
|
49 |
> Im also concerned about how you are attempting to download a single |
50 |
> file from multiple locations. Im told it is valid, but would rather set |
51 |
> it up as a thirdpartymirror. |
52 |
|
53 |
Technically this would give the same result, but conceptually we are not |
54 |
talking about mirrors here. We have several separate repositories, and |
55 |
the artifact might be located in any one of them, but usually not in |
56 |
all, in contrast to a mirror. I also definitely want to give ebuilds the |
57 |
option to specify the repository. Instead of adding to thirdpartymirror, |
58 |
I guess I'd rather require ebuilds to specify the repository. The way it |
59 |
is now allows for laziness of ebuild writers and for inclusion of |
60 |
content into central repositories at a later point in time. |
61 |
|
62 |
> *.ebuilds: |
63 |
> inherit java-pkg-2 [java-pkg-simple java-mvn-src] |
64 |
|
65 |
What do you wish to denote with the brackets? I guess I'll have to |
66 |
inherit java-pkg-2 java-mvn-src |
67 |
if I indeed drop the inherit java-pkg-2 from java-pkg-simple.eclass. |
68 |
Or were you referring to ebuilds in general, not only my two istack ones? |
69 |
|
70 |
> With the eclasses i'm trying to make them as similar to the layout (and |
71 |
> relationships) of java-pkg-2 and java-ant-2 |
72 |
|
73 |
Is this the reason why java-pkg-simple shouldn't itself inherit java-pkg-2? |
74 |
|
75 |
> My only concern with "simple eclasses" is it could compile, bundle and |
76 |
> install tests, |
77 |
|
78 |
You can't take all work from ebuild writers. They either have to remove |
79 |
test code first, choose JAVA_SRC_DIR correctly (once I've introduced |
80 |
it), choose S correctly (i.e. in src/main for common maven-like layout) |
81 |
to eclude tests, or perhaps this eclass simply isn't for them. |
82 |
|
83 |
> or even more concerning be used to bypass |
84 |
> a "better" build system that includes unit tests, etc, etc. |
85 |
|
86 |
Depending on circumstances, that might not even be wrong. If the |
87 |
"better" build system is inherently tricky to handle, a simple eclass |
88 |
might be used to get an important package into portage quickly, while |
89 |
more elaborate ebuilds are still being developed. |
90 |
|
91 |
I might add some QA tests, e.g. to have java-pkg-simple complain if it |
92 |
finds a build.xml or pom.xml, or if there sources.lst seems to contain |
93 |
tests (e.g. a subdirectory called test or tests). |
94 |
|
95 |
I'll get back to my eclasses, send you the next iteration soon I guess. |
96 |
|
97 |
Greetings, |
98 |
Martin |