Eivind Tagseth wrote: > * 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.
But you already have that. Maven uses a property for its remote repository. The value is a separated list with URLs. It is valid to have file:/var/cache/maven here! And if you put this property on command-line Maven would not even try to connect somewhere else. You just cannot change the layout of the repository itself. Therefore we could introduce at least the Maven repo very fast. Adjust the Maven ebuild to the new repo location, introduce that use flag and support it in the other Java ebuilds. > 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. Therefore I propose those symlinks. If a Java ebuild supports Maven with a use flag, all you need is a symlink of the jar the proposed local Maven repo. >> 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. Well, I do not know the Mozilla downloader, but for Eclipse you can point the internal Plugin-Management to a URL with an XML-file that defines the available releases of the Plugin, its location, license, etc. and you can download and install it using this mechanism. Since they build not (starting with 3.0M6) on an OSCI implementation, you can expect other apps coming very soon, using the same technology. I already saw announcements. > I would never run eclipse as root, so any > downloaded plugin would only be available for me personally, would it? Normally they download to a global repo. Don't know currently how they handle permissions. [snip] >> 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. No. The src package is about 15MB and contains anything including a private ant. The DLL paranoia swaps over to Java ... ;-) > 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. Yeah, this was my point. I could replace the jars from the Cocoon package with the ones already on the system. But the jars are still copied later on ... at least they are included in the web app. > 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. Me too, I just take the Cocoon ebuild as example, since I am currently familiar with it. But I seem to be more pragmatic :) Regards, J�rg -- [EMAIL PROTECTED] mailing list
