On Mon, Jun 14, 2004 at 08:29:20PM +0200, Jörg Schaible wrote:
> Karl Trygve Kalleberg wrote:
>
> Hi Karl,
>
> here my 2c:
>
>
> 2.2) DIrectory names
>
> a) .jar pre-build files into /opt
>
> We should separate here between real apps (e.g.) Eclipse and libraries. IMHO
> is does not make sense to clutter /opt with every available Java library,
> that does not supply sources (e.g. glue). Can we introduce /opt/lib for
> those?
Yes, this was an omission from the draft. Of course we need a separate
lib dir:)
> b) Java web applications (WAR) and enterprise apps (EAR)
>
> What about them? We will need something like a webapp-config and eapp-config
> to install packages, that produce such an application into a proper
> environment.
This is something I think we should discuss with the webapps herd. In fact,
I think they're already working on a solution, but I've not had the time to
elicit the details yet.
>
> 3) Versioning
>
> Sadly we have in the Java-OSS world often incompatibilities even in the
> least minor number (e.g. commons-logging-1.0.x) or have to deal with
> snapshots (e.g. commons-configurations-20040404.131522) without any release
> and compatible version. I am not sure, how a package maintainer really has
> a chance to deal with those and try to ensure for the users
> "compatibility" :(
I agree. Especially the commons packages are really bad (how gave these people
inordinate amounts of psychopharmaca anyway?). In this case, I would suggest
we set SLOT="${PV}" and all packages depend on a particular SLOT.
(The "depend on a particular SLOT" is not all that easy with the current
dependency system; we may have to forfeit and depend directly on the package
version. In this case, _all_ Java libraries must have SLOT="${PV}".)
> 4.3) The maven eclass
>
> A lot of Java apps/libs build already with Maven (I know you like it :).
> Since it is possible to overload the properties used to build such an app
> with local "build.properties" files, we need an eclass, that creates them
> and inserts there jar-overwrites (i.e. for the local build jars instead of
> the ones from ibiblio) and is able to prepare the directory layout from 2.2
> (e.g. by setting maven.javadoc.dir=${maven.dest.dir}/doc/html/api). As
> alternative I proposed once a local maven repository stuffed with symlinks.
Fixing the build.properties file is how we've hacked around this sometimes
now. Alternative hacks have been pushing Maven to generate a build.xml file,
then patching this. However, I've been told that future versions of Maven may
not employ ant in this fashion. Whether the build.xml generator will disappear
is unclear.
> 5) I would not handle transient dependencies (at least for now). Also we
> will need an interims solution unless the most "common" packages are
> available. Looking at Cocoon, we would have to build about 30 ebuild before
> any package for Cocoon itself. While I've build Cocoon from the sources, I
> took the prebuild libs from the Cocoon package for the current ebuild.
> Otherwise we would not have Cocoon (or some other well-known package) in
> near future at all.
Yup. Cocoon is just another example of how horrible the situation is. However,
we should document, as comments in the ebuild, which (transient) packages we
have not currently packaged as ebuilds, so these can be solved in the future.
> 6) Lifecycle
>
> XXX: This is a general ebuild problem. Normally you should not remove any
> eclass, that still has dependencies to any other eclasses in the package
> tree. But this calculation should be part of the ebuild system.
You cannot remove eclasses at all! If you do, people with previous ebuilds
that depend on that eclass cannot uninstall their packages, as eclasses are
actually not installed at merge-time.
> Missing:
> Targeting a developer's environment. As dev I will often need more than one
> version of a library and also the source available.
Yeah, we should add a 'src' keyword, and install a src.zip in a predetermined
place, possibly just drop it in /usr/share/${PF}/
Multiple versions of a library are installable as long as they are SLOTted
differently. This is the de facto way for Gentoo to handle multiple package
(library) version that are parallelly installable.
If two libraries in the same SLOT are not interchangable, i.e., they do not
have the same interface, they should not be in the same SLOT in the first
place:)
Kind regards,
Karl T
pgpXzo6Hm3Bzf.pgp
Description: PGP signature
|
