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 |