Re: [gentoo-java] java-pkg-simple and java-mvn-src eclasses

[Martin von Gagern <Martin.vGagern@gmx.net>]

[-- Attachment #1: Type: text/plain, Size: 4600 bytes --]

Alistair Bush wrote:
> java-pkg-simple.eclass:
> 
> 	1) inherit java-utils-2 (this is required) instead of java-pkg-2.  Add
> checks to ensure java-pkg-2 is inheritted (so ebuild does it).

I derived my eclass from java-pkg-2 instead of java-utils-2 because
conceptually I'm building a java package, so that seemed the right
eclass, and because technically I'd like to leverage the magic around
JAVA_PKG_IUSE and JAVA_PKG_E_DEPEND without copying the corresponding
sections from java-pkg-2.eclass.

I now see that if the ebuild also inherits from java-pkg-2, then I would
have to copy nothing. It would have to inherit in the right order,
htough. If every ebuild using java-pkg-simple.eclass also must inherit
java-pkg-2, what is the reason against making that dependency explicit
in the eclass? Is that what you mean by making the relationship similar
to java-pkg-2 and java-ant-2, as you wrote down there for *.ebuilds?

> 	2) create the jar within src_compile, not src install.

I had that in a previous version, and changed it so that ebuilds cann
add resources to the target directory before it gets packaged. As an
alternative, ebuilds could create the target directory and add resources
before calling java-pkg-simple_src_compile in the first place. Would
mean one mkdir more in the ebuild, and no check by the eclass that the
target directory didn't exist in the archive, which should hold in all
sane cases anyway. I could also place the target dir in ${T} to be sure.

> 	3) I would like to see var's like JAVA_SRC_DIR(S) so that
> java-pkg_dosrc and javadoc could be generated and installed.  See what
> you can do :)

In most cases ${S} would suffice for this. At least javadoc should take
a file list just like javac does (in fact the very same list), so that
should be easy. For dosrc you need to indeed catch the root of the
source tree.

On the other hand, I like your idea about JAVA_SRC_DIR as an argument to
find, as it imposes no additional requirements on simple ebuilds but
adds flexibility for a bit more complex cases. I'll see that I integrate
that with dosrc as well.

> java-mvn-src.eclass:
> 	Have this inherit from java-pkg-simple.eclass

I thought I did. Yes, it says "inherit java-pkg-simple" in the ebuild.

> 	Im also concerned about how you are attempting to download a single
> file from multiple locations. Im told it is valid, but would rather set
> it up as a thirdpartymirror.

Technically this would give the same result, but conceptually we are not
talking about mirrors here. We have several separate repositories, and
the artifact might be located in any one of them, but usually not in
all, in contrast to a mirror. I also definitely want to give ebuilds the
option to specify the repository. Instead of adding to thirdpartymirror,
I guess I'd rather require ebuilds to specify the repository. The way it
is now allows for laziness of ebuild writers and for inclusion of
content into central repositories at a later point in time.

> *.ebuilds:
> 	inherit java-pkg-2 [java-pkg-simple java-mvn-src]

What do you wish to denote with the brackets? I guess I'll have to
inherit java-pkg-2 java-mvn-src
if I indeed drop the inherit java-pkg-2 from java-pkg-simple.eclass.
Or were you referring to ebuilds in general, not only my two istack ones?

> With the eclasses i'm trying to make them as similar to the layout (and
> relationships) of java-pkg-2 and java-ant-2

Is this the reason why java-pkg-simple shouldn't itself inherit java-pkg-2?

> My only concern with "simple eclasses" is it could compile, bundle and
> install tests,

You can't take all work from ebuild writers. They either have to remove
test code first, choose JAVA_SRC_DIR correctly (once I've introduced
it), choose S correctly (i.e. in src/main for common maven-like layout)
to eclude tests, or perhaps this eclass simply isn't for them.

> or even more concerning be used to bypass
> a "better" build system that includes unit tests, etc, etc.

Depending on circumstances, that might not even be wrong. If the
"better" build system is inherently tricky to handle, a simple eclass
might be used to get an important package into portage quickly, while
more elaborate ebuilds are still being developed.

I might add some QA tests, e.g. to have java-pkg-simple complain if it
finds a build.xml or pom.xml, or if there sources.lst seems to contain
tests (e.g. a subdirectory called test or tests).

I'll get back to my eclasses, send you the next iteration soon I guess.

Greetings,
 Martin


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]