Re: Maven and Fedora
Just to clarify the building from source situation, the real requirement is that if we were in a concrete bunker somewhere with no connection to the outside world, and all we had was an installed fedora box + all the source rpms for fedora, we should be able to rebuild the entire OS. Note that this doesn't require building everything from source all in one go. That's impossible since there are cyclic dependencies, e.g. gcc is used to build itself. It *does* require that we can completely turn off all maven's attempts at remote access and preferably turn them into nice error messages. Now I'm not sure how this translates into the building one level from source vs building all levels from source terminology, I would phrase it as we need to build all levels from source, but we can build them one level at a time. This strict offline bootstrapping requirement is necessary for producing consistent OS builds. This does make it clear that a self contained binary repository will work, as long as the self contained binary repository is part of every fedora install. The only issue there is one of JPP vs maven conventions for jar locations. --Rafael Carl Trieloff wrote: Jason van Zyl wrote: On 13 Dec 06, at 10:26 AM 13 Dec 06, Carl Trieloff wrote: I don't see that there is a consistent view yet on this. It would be nice to get to a conclusion on whether the Maven community would like to work with the downstream distros teams so that we can provide a consistent and good experience. Is there any more information that is needed to get to a view point, and if so how can I help? If the distros works with us to provide something that is familiar to our current users, to which our documentation, practices, and current body of user knowledge apply then I don't think anyone would be opposed here. So that means: - Using an installation layout that is consistent with our current setup This seems reasonable - we do need to work with jpackage so there might be some items that come from that. If there are maybe we can see if we can do it in a consistent way that can work for mainline also. - Using the Maven repository as the source for satisfying dependencies for development work That was my assumption and if we can get all the items we needed merged in a way maven is happy with upstream there would be no reason to do anything else - Maven running with a standard JDK and not being compiled with GJC or anything weird like that. With Java being GPL now that shouldn't be a problem There is a timeline issue with this. If we complete the Maven work before JDK (GPL) is available then we might need to prove we can build with GCJ, or build with mainline of the GPL version which will be ahead 1.6. Don't really know if worth debating now as GPL JDK is also a moving target and we should eval once we get closer to completing the other items that need to be done. A couple questions that weren't really answered were: - How far into the graph do you need to build from sources - All the way, or we can limit some modules and add them incrementally, or maybe if the user needs them the we can download them when mvn is run much like anaconda. - Would a self-contained Maven repository with the binary dependencies work and then build Maven itself from source or do you want to walk back down the entire graph? - All dependencies that are shipped in the distro or used to build the distro need to be able to be built from source. Suggestion: Would a good starting point be to maybe be to create a branch where some guys can work, and then we work item by item with the maven community. once we get an issue out the way, and agreed by maven team we merge the branch and start the next item? Carl. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and Fedora
Jason van Zyl wrote: On 14 Dec 06, at 10:30 AM 14 Dec 06, Rafael Schloming wrote: Just to clarify the building from source situation, the real requirement is that if we were in a concrete bunker somewhere with no connection to the outside world, and all we had was an installed fedora box + all the source rpms for fedora, we should be able to rebuild the entire OS. Sure, but for Maven usage a JDK + a tarball of Maven in all practical instances is enough for someone to get work done. I'm not sure what this has to do with my post. I'm just trying to explain fedora's bootstrapping requirements. Besides, even if a JDK + a tarball is enough to run maven itself, this doesn't really solve the problem maven users face when trying to distribute their software on fedora or any other OS for that matter. IMHO the key problem to solve is how to make maven builds produce software that is integrated with the target OS. Once we've done this then integrating maven with the target OS should be trivial since maven can build itself. This issue is really broader than just maven. It seems the defacto java packaging standard is to simply distribute a huge archive that includes every dependency, quite reminiscent of windows DLL hell. This may well be the only option available for windows, but for OSes like fedora where things like automatic dependency management, upgrades, and security fixes are the norm, this practice just doesn't scale. --Rafael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and Fedora
Jason van Zyl wrote: On 6 Dec 06, at 3:02 PM 6 Dec 06, Carl Trieloff wrote: John Casey wrote: Let's start with: What are the requirements? Regards, John yes that is good - I would not see the patches set as something to commit as is but a prototype to see if it could be done. we now think it can - and would do it in a way that works for maven. The key parts are: - boot strap via build from source Not by default, this is Java and we are happy to use binary JARs. If you want to attempt to do this knock yourself. I don't see any benefit in complicating our bootstrap to accommodate this. - OS boot strap-able, with no network, this is more than just mvn -o - meet fedora package guidelines Can break those our one by one, unless Deepak or Rafi fill them first. I just don't see the value in this for Maven users. Carl what value do you see as a real benefit to Maven users who work on Redhat? There are three distinct use cases for maven playing nice with distros. 1. For a standard distro install without devel tools there may be packages that maven creates in distro format (RPM, dep, etc). Note that the maven RPM would not be used by end users at all in this scenario. 2. For a development distro install, i.e. installing devel packages there's a use case for maven packaged in distro format since distro users like to have the same install experience for all their software, i.e. they'd rather do yum install maven than download and install manually. 3. For scenario (1) and (2) distro builders need to be able to get maven in distro format so that they can bootstrap their distro. Strictly speaking if you don't want to allow (2) in order to control the maven experience for end users we could package a special form of maven that is only available to distro builders to satisfy scenario (1). I think this will actually end up creating *more* flavors of maven than if we work together to make maven play nice with distros in general. In the latter case you can shape what an OS level maven install looks like. If you refuse to work with distros then they will inevitably be forced to figure out on their own how to get maven to build packages for them. --Rafael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and Fedora
Jason van Zyl wrote: I don't remember a specific instance, but I'm sure there are some who would like them. Either way, we need to consider Fedora as a consumer of Maven and that they know what their users want, which apparently is Maven bundled with Fedora. I doubt they have asked but I would be pleasantly surprised if the impetus was actually Maven users and not simply a desire to package Maven up on Redhat. There are multiple projects that we develop on that use maven and need to go into distros. FWIW this makes use maven users that would really like to see maven work well with distros. We also agree that usability is the key objective. That's exactly why we want to work out a solution and not distribute a modified version of maven just to satisfy our bootstrapping requirements. --Rafael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and Fedora
John Casey wrote: 2: Ensure that projects can build against a single version of a dependency, rather than multiple. This bothers me the most. If my project's pom.xml says I depend on foo version 1.1.3, it better be built and installed with foo version 1.1.3, not foo version 1.2 or foo version 1.1.5 of foo version 2.0. If I wanted to say any 1.x version, I would have used a version range in my pom. If redhat or rpm or whatever cannot install multiple versions of a resource, that seems like a deficiency in those and I don't think maven should go out of it's way to work around that. Maven's dependency management is definitely one of it's strong point. That type of change bypasses all of that. This is a sticking point for me, too, actually. It might be okay to drop the versions off of a build during the distro-building process, because you've got other systems managing compatibility of versions in the larger context...but if a user gets to do that sort of thing, it's going to be a major support problem for us, and it's counter to a lot of what we're trying to do with Maven in the first place. In the first case, it's more like an alternative version-conflict resolution step...in the second, it's hijacking Maven's notion of artifact identity and build reproducibility. I think you touch on a key point here. Building in the context of putting together a distribution is very different from an end user downloading and building something for themselves. A distribution is trying to provide a consistent set of well integrated packages. In this context you want to avoid multiple versions of a package if you can because 99% of users don't care and in fact will be confused if they have to choose between two versions of the same thing. Not to mention security patches become nearly impossible if you need to keep around any old version of a package. There are cases where installing multiple versions makes sense and RPM can do that if you want, but for these reasons most distros try to avoid it and it's not uncommon for them to build against a slightly different version of dependencies than upstream developers use in order to eliminate multiple package versions. Of course all this is in stark contrast with an end user downloading a source tarball directly and building it himself. In this scenario the user may want to duplicate as closely as possible the build conditions that the upstream developers use themselves and so he would want precisely the same version that upstream is using. So I see two distinct use cases for building software: 1. Precisely reproducing upstream builds. Maven is already an excellent tool for this. 2. Building software to integrate with a pre-existing environment. This is what fedora or any other distro needs, and right now it's not so easy with maven. --Rafael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and Fedora
John Casey wrote: All of this makes sense, until you consider that the user might start using the Fedora-provided version of Maven for his own software builds. Then you have a possibility of letting him produce a very messy build that doesn't use artifact versions. If the possibility is there, it will be [ab]used. Isn't this just a matter of choosing the right defaults? If by default you use artifact versions then people won't get a messy build unless they specifically ask for it, and at that point they should expect the possibility of some surprises. Distros certainly expect to take on the burden of integration testing as soon as the depart from upstream build procedures. --Rafael -john On 12/6/06, Rafael Schloming [EMAIL PROTECTED] wrote: John Casey wrote: 2: Ensure that projects can build against a single version of a dependency, rather than multiple. This bothers me the most. If my project's pom.xml says I depend on foo version 1.1.3, it better be built and installed with foo version 1.1.3, not foo version 1.2 or foo version 1.1.5 of foo version 2.0. If I wanted to say any 1.x version, I would have used a version range in my pom. If redhat or rpm or whatever cannot install multiple versions of a resource, that seems like a deficiency in those and I don't think maven should go out of it's way to work around that. Maven's dependency management is definitely one of it's strong point. That type of change bypasses all of that. This is a sticking point for me, too, actually. It might be okay to drop the versions off of a build during the distro-building process, because you've got other systems managing compatibility of versions in the larger context...but if a user gets to do that sort of thing, it's going to be a major support problem for us, and it's counter to a lot of what we're trying to do with Maven in the first place. In the first case, it's more like an alternative version-conflict resolution step...in the second, it's hijacking Maven's notion of artifact identity and build reproducibility. I think you touch on a key point here. Building in the context of putting together a distribution is very different from an end user downloading and building something for themselves. A distribution is trying to provide a consistent set of well integrated packages. In this context you want to avoid multiple versions of a package if you can because 99% of users don't care and in fact will be confused if they have to choose between two versions of the same thing. Not to mention security patches become nearly impossible if you need to keep around any old version of a package. There are cases where installing multiple versions makes sense and RPM can do that if you want, but for these reasons most distros try to avoid it and it's not uncommon for them to build against a slightly different version of dependencies than upstream developers use in order to eliminate multiple package versions. Of course all this is in stark contrast with an end user downloading a source tarball directly and building it himself. In this scenario the user may want to duplicate as closely as possible the build conditions that the upstream developers use themselves and so he would want precisely the same version that upstream is using. So I see two distinct use cases for building software: 1. Precisely reproducing upstream builds. Maven is already an excellent tool for this. 2. Building software to integrate with a pre-existing environment. This is what fedora or any other distro needs, and right now it's not so easy with maven. --Rafael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and Fedora
Rafael Schloming wrote: John Casey wrote: All of this makes sense, until you consider that the user might start using the Fedora-provided version of Maven for his own software builds. Then you have a possibility of letting him produce a very messy build that doesn't use artifact versions. If the possibility is there, it will be [ab]used. Isn't this just a matter of choosing the right defaults? If by default you use artifact versions then people won't get a messy build unless they specifically ask for it, and at that point they should expect the possibility of some surprises. Distros certainly expect to take on the burden of integration testing as soon as the depart from upstream build procedures. --Rafael Also with Java being GPLed, more and more distros will be using it for core distro-related stuff, and they'll be trying to address the same maven issues that we're trying to address now. Isn't now the best time to work this out so that maven will be ready when distros start seriously leaning on Java? --Rafael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
