Serkan Kaba wrote:
> Alistair Bush yazm1_:
>> Ok, things to note and it would be interesting to see whether other
>> dev's agree with me:
> 
>> 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).
>> 	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 :)
> 
>> java-mvn-src.eclass:
>> 	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.
> 
>> *.ebuilds:
>> 	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:
>>> Hi!
>>>
>>> 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
>> install
>> 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.

I think you misunderstand where im coming from.

ejunit is going to run the unit tests.  my problem isn't running them,
it is then being compiled within src_compile and ending up within the
resulting jar file in the first place.

java-pkg-simple_src_compile just runs `find * -name \*.java >
sources.lst` to find all the *.java files.  even in they are with
directories src/test, test or JAVA_FILES_DO_NOT_COMPILE directory.

Why I like the JAVA_SRC_DIR ( or whatever ) variable is then at least we
could go and do something like

find ${JAVA_SRC_DIR} -name \*.java > source.lst

as long as we don't quote JAVA_SRC_DIR I believe it should work.

The eclass/default build.xml is also another option that has been thrown
around for a while either.

>>> Greetings,
>>>  Martin von Gagern (aka MvG)
>>>
> 
> 
>