From: Alistair Bush <alistair.bush@gmail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Suggestion
Date: Thu, 8 Feb 2007 23:40:55 +1300 [thread overview]
Message-ID: <200702082340.55517.alistair.bush@gmail.com> (raw)
In-Reply-To: <200702081038.13483.jose.sanleandro@ventura24.es>
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
next prev parent reply other threads:[~2007-02-08 10:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-08 9:38 [gentoo-dev] Suggestion Jose San Leandro
2007-02-08 9:43 ` Ciaran McCreesh
2007-02-08 10:50 ` Christopher Covington
2007-02-08 13:26 ` Joshua Nichols
2007-02-14 10:40 ` [gentoo-dev] Suggestion Steve Long
2007-02-08 10:59 ` [gentoo-dev] Suggestion Jose San Leandro
2007-02-08 12:39 ` Chris Gianelloni
2007-02-08 14:42 ` Luis Francisco Araujo
2007-02-08 10:40 ` Alistair Bush [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-06-19 16:44 [gentoo-dev] suggestion Andy Molloy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200702082340.55517.alistair.bush@gmail.com \
--to=alistair.bush@gmail.com \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox