* J�rg Schaible <[EMAIL PROTECTED]> [2004-01-31 08:50:38 +0100]: > Eivind Tagseth wrote: > 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.
Yes, that would be very nice. > You will not be able to change how Maven works. I really don't. I merely want to widen the search path that maven uses to download the dependencies. In addition to the http downloader, I'd like to add a check-the-local-gentoo-system downloader. Or use your symlinks to create a virtual maven repository. I don't want to force all packages into this system, but currently, if we wanted the possibility to choose the locally installed foo-package, then we'd have no standard mechanism for doing it! I think there is a definate need for such a mechanism, it may not be worthwhile for all packages, but it will be for some. > 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. I'm sorry, but I haven't used eclipse that much. But if the plugin downloader for eclipse looks like the one for mozilla, then yes, I'd prefer if an ebuild was altso available. I would never run eclipse as root, so any downloaded plugin would only be available for me personally, would it? > What about with apps using Java WebStart? Please, I'm not as fanatic as you think I am ;) I just see portage as a very nice package system, and I see the advantages of using it, also for java packages. And I see that for java packages, ebuilds are too hard to make properly, and I'd like us to have the functionality in place for easier ebuilds and easier use of already installed ebuilds. I'm not saying that all binary java ebuilds are evil, I'm not saying that all maven based packages should be patched and have special ebuilds for all of their dependencies. I'm just saying that we currently have no established system for doing this, even if we wanted to, and I think that sucks. > > 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? If you cannot download the source for cocoon without any external jar files included, then yes, that would be nice. If the current fop ebuild is newer than the one included with cocoon, then this would be nice. If cocoon depends on a given CVS snapshot of fop, then of course, we would have to keep using the included one. But I'm not that concerned about cocoon specifically (although I don't like having cocoon transforming a fo file differently than the system installed fop), I'm more interested in making sure that there are established portage style mechanisms for getting as much out of portage that we can on a general basis. Eivind -- [EMAIL PROTECTED] mailing list
