Gentoo Archives: gentoo-dev

From: Alistair Bush <alistair.bush@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Suggestion
Date: Thu, 08 Feb 2007 10:47:33
Message-Id: 200702082340.55517.alistair.bush@gmail.com
In Reply to: [gentoo-dev] Suggestion by Jose San Leandro
1 On Thursday 08 February 2007 10:38 pm, Jose San Leandro wrote:
2 > Hi all,
3 >
4 > A friend of mine and myself are willing to develop some tools to help
5 > ebuild development.
6 >
7 > We have some constraints, but we are thinking on something like:
8 > 1) A tool to ease writing ebuilds. It would take some parameters, i.e.:
9 > 1.1) Where are the sources?
10 > 1.2) Decompression algorithm?
11 > 1.3) Compile the sources?
12 > 1.4) Install man page(s)?
13 > 1.5) Install documentation?
14 > 1.6) Bind actions to USE flags?
15 > It would probably be interesting to define a set of pre-defined categories:
16 > standard GNU Autotools projects, perl/CPAN modules, python, ...
17
18 I see no reason why a good template and/or eclass can't handle this
19 >
20 > 2) A tool to deal with the unstandarized way to compile and install Java
21 > projects. The idea is to write a tool to try to find out:
22 > 2.1) Where are located the "main" .java sources.
23 > 2.2) Where are located the unit tests.
24 > 2.3) Where are the jar files generated (in case of Ant-based builds) when
25 > the project is built.
26 > 2.4) Where to get the dependencies.
27 > And once this information is available, fill the blanks of a pre-defined
28 > Maven2 pom.xml descriptor, and use it to drive the ebuild. This way it
29 > would allow compilation flags even if the original build mechanism didn't.
30 > We probably will ask for this specific issue to gentoo-java mailing list.
31 > We don't think a fully-automated tool is feasible to cope with all kind of
32 > projects, but we hope it could be of use for Java developers who don't use
33 > Gentoo but find interesting to get an ebuild with little effort.
34
35 I apologies as this will be critical.
36
37 Firstly I would be very interested in how you would handle to dependencies of
38 a package within this build system. Maven is natorious for wanting to
39 download its dependencies (including plugins all its plugins) from a remote
40 repository. Something that the java team (and me personally) have been
41 struggling with for sometime.
42
43 Secondly the java-*-2 eclasses are now very advanced wrt everything ant.
44 They abstract a large portion of the functionality away from the ebuild
45 (without lossing the flexability)
46
47 So here an anottated vim template that I currently use and that will hopefully
48 ( bug #164953 ) make it into the tree.
49
50
51 # Copyright 1999-2007 Gentoo Foundation
52 # Distributed under the terms of the GNU General Public License v2
53 # $Header: $
54
55 JAVA_PKG_IUSE="doc source" #this appends the appropriate deps to
56 #DEPEND(RDEPEND) for source
57
58 inherit java-pkg-2 java-ant-2
59
60 DESCRIPTION=""
61 HOMEPAGE=""
62 SRC_URI="${P}.zip"
63
64 LICENSE=""
65 SLOT="0"
66 KEYWORDS="~amd64"
67
68 IUSE=""
69
70 COMMON_DEP=""
71
72 RDEPEND=">=virtual/jre-1.4 #this is used by eclasses to determine the target
73 class version
74 ${COMMON_DEP}"
75 DEPEND=">=virtual/jdk-1.4 #and this determines the source target
76 app-arch/unzip
77 ${COMMON_DEP}"
78
79 EANT_BUILD_TARGET=""
80 EANT_DOC_TARGET=""
81
82 src_install() {
83 java-pkg_dojar "${PN}.jar"
84 use doc && java-pkg_dojavadoc build/javadoc
85 use source && java-pkg_dosrc src
86 }
87
88 I find this ebuild template usually provides everything a java ebuild
89 requires.
90
91 I would suggest you read the dev notes on the gentoo-java project page as well
92 as reading the wiki.
93
94 >
95 > However, we are just in the definition stage. We haven't decided anything
96 > yet, and would like to know your suggestions, even if they aren't
97 > encouraging :).
98 >
99 > Thank you very much.
100 > Jose.
101
102 Please don't let me discourage you. I would be very interested in your
103 solutions for using maven and I believe the when 2.0.5 is released some form
104 of pom re-writing could be possible (similar to what happens with build.xml
105 files at the moment), but I dont believe there is a need to mavenify ant
106 builds. I believe it would be over complicated and have huge problems
107 handling where the src and libraries within a package reside. When it comes
108 to ant (at least) I believe the present solution is far more adaptable and
109 productive.
110
111
112 Alistair
113 --
114 gentoo-dev@g.o mailing list