List Archive: gentoo-java
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
-----BEGIN PGP SIGNED MESSAGE-----
Alistair Bush yazmış:
> Ok, things to note and it would be interesting to see whether other
> dev's agree with me:
> 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).
> 2) create the jar within src_compile, not src install.
> 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 :)
> Have this inherit from java-pkg-simple.eclass
> 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.
> inherit java-pkg-2 [java-pkg-simple java-mvn-src]
> With the eclasses i'm trying to make them as similar to the layout (and
> relationships) of java-pkg-2 and java-ant-2
> Martin von Gagern wrote:
>> I propose two new eclasses. One is for building java packages from their
>> *.java source files, without any additional build instructions. The
>> second builds on it and is intended for source bundles exported by the
>> source:jar goal of Maven2. Two parts of istack-commons can be bumped
>> using these, in order to address https://bugs.gentoo.org/188015 .
>> I would like to commit all of these to java-experimental if there are no
>> objectsion. If you leave the Subject in place, I will catch replies to
>> this list. Otherwise please Cc me personally, as I don't read every mail
>> to the list.
>> On IRC selckin1 said: "simple eclass to build simple java packages has
>> been proposed many times. my main question would be why doesn't it exist
>> allready, this been suggested many times going back years, must be a
>> reason." Any input on this would be useful as well.
> My only concern with "simple eclasses" is it could compile, bundle and
> tests, or even more concerning be used to bypass
> a "better" build system that includes unit tests, etc, etc.
ejunit can be helpful there. But ant suits better imo. We can have a
more generic build.xml (possibly included with one of our own tools or
created in the eclass itself) and an option for the ebuilds to use their
own build.xml files as well (As already done in tree) Having an option
to override the default build.xml will help to overcome packages which
doesn't fit to generic. But still we should see if there are more
generaliations than exceptions.
>> Martin von Gagern (aka MvG)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----