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