Eivind Tagseth wrote: > * 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] >> 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 fear for anything coming from apache never becoming mature enough, that an official release will not depend on some "unmature" other apache package <g> > 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? OK. You're not secured from stupid builds. But Maven is there to solve that scenario. Cocoon however was friendly, it allows the generation of a local.build.properties file taking precedence over build.properties. But this is surely not standard. Maybe an eclass for the property files of for XML build files (Ant and Maven) could help. >> 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. I know what you mean, but I fear the result :) You will not be able to change how Maven works. But if we propose a system wide repository and a useflag for Maven, we could create symlinks from our already emerged versions. But this should happen *soon*. And any of the available Java ebuilds should obey it. And - we will have to use the slot mechanism extensivly ... :( Additionally be aware, the core system is already extracted from Maven in an own project named "mavem-wagon". Applications will appear using the same technology. We already have such a thing with Avalon-Merlin, that has a Maven-compatible repository, but they decided not to share it with Maven for some reason (had to read Stephen's args again). And, since Merlin is just an application framework, there will be applications build with it ... Next problem is eclipse with the automated plugin download. Would you like to patch that one too? And since eclipse uses now an OSCI layer for this funtionality, I can imagine more apps using this technic. What about with apps using Java WebStart? > 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? Well, I don't do Enterprise Application development all the time. And I want my *system* using the current JDK by default. My development environment is a separated beast. [snip] > 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. OK. Point taken. But what about something like Cocoon now? In consequence my ebuild should depend on all those core packages. In src_unpack I would have to replace the jars against symlinks and check the system against the optional packages, right? [snip] > 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 only the latter seems successfull. >> 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?). Well, since they are not in a local Maven repo ;-) Regards, J�rg -- [EMAIL PROTECTED] mailing list
