* J�rg Schaible <[EMAIL PROTECTED]> [2004-01-28 23:43:17 +0100]:
> Eivind Tagseth wrote:
> > * J�rg Schaible <[EMAIL PROTECTED]> [2004-01-28
> > 01:57:49 +0100]:
[snip]
> > I think the Maven approach of downloading binaries into a repository is
> > all
> > wrong (not for other distributions maybe, but certainly for gentoo). If
> > I've gone through the trouble of creating an excellent ebuild file for
> > building commons-foo from scratch (maybe even with certain patches), then
> > I'd expect (and want) that result to be used when later emerging package
> > java-bar that depends on commons-foo. Anything else rather violates the
> > gentoo spirit of things.
>
> Well, this is not a Maven problem, just look at Cocoon. Its source ball
> comes with 14 jars declared as core libs. Three of them *are* snapshot
> releases. Not counting the endorsed and optional libs. They even deliver an
> own ant release to build Cocoon. The ebuild now just calls build.sh to
> build Cocoon using their internal Ant. Do you really expect that anyone is
> willing to create that much ebuilds for all these dependent jars, test any
> functionality exchanging all the snapshot packages with official releases
> (IMHO not feasable anyway) and create for every release a big patch for the
> build files, that it will use the already installed versions? *shrug*
Well, yes. Or rather, I'd like cocoon to mature a bit more, and be able
to use the latest official version of the different packages. If it
did, then there would already be ebuilds for the other packages, and the
only thing needing patching would be cocoon's build files. I've made
quite a few java ebuilds, and I _always_ end up patching the build files.
There always seem to be a reference to e.g. servlet.jar on some
developer's filesystem. This often looks like
servlet.jar=D:/Java/Tomcat/servlet.jar
or something like that. Changing these in the build files, or overriding
them in a build.properties files is tedious, boring and involves yucky
regexps. Maybe it would be possible to make a few functions in the java
eclass for doing this?
> Well, you would have to create a fork of Maven. Jason would never put
> something like that into Maven regardless of any patches sent on this
> topic.
A patch, not a fork. I'm certainly not interested in maintaining any maven
fork. If a clean patch can be made, then this shouldn't be much work.
> IMHO I cannot see your vision going to happen, sorry. I really understand
> your point and also the motivation, but take again a look at the Cocoon
> package: Building it here on my machine natively, I get a big fat warning,
> that my generated version will depend on JDK 1.4.x and will not run for JDK
> 1.3.x and earlier. As a developer, this is a show-stopper. If I have to
> build an app for WebLogic or Webshpere I *have* to use 1.3.x, since these
> apps are not certified by their vendors for newer JDKs and your on your own
> regarding support. The Gentoo version of Cocoon would be useless to me.
> While I can argue for Java applications to build anything from source, I
> cannot do so for a development environment. And this problem might increase
> with the upcoming JDK 1.5.
So you'd like cocoon to be compiled using jdk 1.3? I've had ebuilds requiring
jdk 1.3 in order to compile. If there was a java-config function to use
a given jdk for the current shell, we could even have a jdk1.3 use flag.
But if you _have_ to use jdk1.3, why haven't you set up jdk 1.3 as the
default system wide jdk?
> OTOH, what's so wrong with the prebuild Java package? It is Java's nature to
> have precompiled code already optimized for its processor - the VM. To
> change the processor, change the VM.
For me, the big advantage of gentoo is not to have binaries optimized for
my processor. I really don't think those effects are very noticeable
anyway. The big advantage is that everything compiled on my computer
will be compiled against this computers environment. This means that
if I use postgres as my main database, then all packages will be compiled
with support for postgres, no matter what the preferences were for the
person who wrote the ebuild itself.
This is no different in java packages, there are several packages that
optionally will include support for foo and bar, if you set it up in the
build files. If I had built fop with support for generating word files,
then I'd want cocoon to be able to produce word files as well.
> If the source-only-rule will be applied I believe, that you will
> not be able to create a community maintaining the necessary ebuilds and the
> Java packages in portage will always be so outdated, that no-one really
> cares about them. If you do not believe me, look into portage/dev-java,
> this is what currently already happens.
I'm not really talking about a source-only-rule here, rather a
source-only-goal. If a certain package (like cocoon) is impossible or really
hard to compile by hand with all it's dependencies, then be pragmatic.
But if there is a chance of having cocoon built the gentoo way, then
this option should be considered, encouraged and made easy. This means
having mechanisms available for making this easy to do.
This could mean a simple patch for maven, more utility functions for
patchind build files, etc.
> IMHO we need some guilde lines for Java ebuilds and ground is layed with
> java-pkg eclass. I would be happy, if any Java ebuild would obey some
> global USE flags for doc, java-source, maven and samples and installs
> itself smoothly into the file system:
No disagreement here. We need guide lines and we need better tools. And
we need better support for the slot system. And personally I think we should
try as hard as we can to try to use the already installed jar files whenever
we can (what's the point in creating an ebuild for commons-foo if none
of the packages using commons-foo are using it's result?).
Eivind
--
[EMAIL PROTECTED] mailing list
