On Thursday 08 February 2007 10:38 pm, Jose San Leandro wrote:
> Hi all,
>
> A friend of mine and myself are willing to develop some tools to help
> ebuild development.
>
> We have some constraints, but we are thinking on something like:
> 1) A tool to ease writing ebuilds. It would take some parameters, i.e.:
> 1.1) Where are the sources?
> 1.2) Decompression algorithm?
> 1.3) Compile the sources?
> 1.4) Install man page(s)?
> 1.5) Install documentation?
> 1.6) Bind actions to USE flags?
> It would probably be interesting to define a set of pre-defined categories:
> standard GNU Autotools projects, perl/CPAN modules, python, ...
I see no reason why a good template and/or eclass can't handle this
>
> 2) A tool to deal with the unstandarized way to compile and install Java
> projects. The idea is to write a tool to try to find out:
> 2.1) Where are located the "main" .java sources.
> 2.2) Where are located the unit tests.
> 2.3) Where are the jar files generated (in case of Ant-based builds) when
> the project is built.
> 2.4) Where to get the dependencies.
> And once this information is available, fill the blanks of a pre-defined
> Maven2 pom.xml descriptor, and use it to drive the ebuild. This way it
> would allow compilation flags even if the original build mechanism didn't.
> We probably will ask for this specific issue to gentoo-java mailing list.
> We don't think a fully-automated tool is feasible to cope with all kind of
> projects, but we hope it could be of use for Java developers who don't use
> Gentoo but find interesting to get an ebuild with little effort.
I apologies as this will be critical.
Firstly I would be very interested in how you would handle to dependencies of
a package within this build system. Maven is natorious for wanting to
download its dependencies (including plugins all its plugins) from a remote
repository. Something that the java team (and me personally) have been
struggling with for sometime.
Secondly the java-*-2 eclasses are now very advanced wrt everything ant.
They abstract a large portion of the functionality away from the ebuild
(without lossing the flexability)
So here an anottated vim template that I currently use and that will hopefully
( bug #164953 ) make it into the tree.
# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
JAVA_PKG_IUSE="doc source" #this appends the appropriate deps to
#DEPEND(RDEPEND) for
source
inherit java-pkg-2 java-ant-2
DESCRIPTION=""
HOMEPAGE=""
SRC_URI="${P}.zip"
LICENSE=""
SLOT="0"
KEYWORDS="~amd64"
IUSE=""
COMMON_DEP=""
RDEPEND=">=virtual/jre-1.4 #this is used by eclasses to determine the target
class version
${COMMON_DEP}"
DEPEND=">=virtual/jdk-1.4 #and this determines the source target
app-arch/unzip
${COMMON_DEP}"
EANT_BUILD_TARGET=""
EANT_DOC_TARGET=""
src_install() {
java-pkg_dojar "${PN}.jar"
use doc && java-pkg_dojavadoc build/javadoc
use source && java-pkg_dosrc src
}
I find this ebuild template usually provides everything a java ebuild
requires.
I would suggest you read the dev notes on the gentoo-java project page as well
as reading the wiki.
>
> However, we are just in the definition stage. We haven't decided anything
> yet, and would like to know your suggestions, even if they aren't
> encouraging :).
>
> Thank you very much.
> Jose.
Please don't let me discourage you. I would be very interested in your
solutions for using maven and I believe the when 2.0.5 is released some form
of pom re-writing could be possible (similar to what happens with build.xml
files at the moment), but I dont believe there is a need to mavenify ant
builds. I believe it would be over complicated and have huge problems
handling where the src and libraries within a package reside. When it comes
to ant (at least) I believe the present solution is far more adaptable and
productive.
Alistair
--
gentoo-dev@gentoo.org mailing list
