Mike Bonnet was good enough to spend a couple of hours with me getting me up to speed on what he is doing with Mead. The short of it is that he has a middle grouind between mavne repository fetching and JPackage for building Maven based projects.
In order to take advantage of it, we have one of two choices.
1. Move Candlepin over to maven 2. Help him get Mead able to use buildr.
Note that this would produce a usable build without having to use all of the MySpec RPMS I built. We could selectively use them if we desire.
I like option 2, although I might not be able to see it through. In order to do this, we have to close the loop on buildr doing local repository builds. As I can see it this means modifying the -r localbuild option such that, once the localbuild script has modified the remote and local repository values, they can no longer be modified by the buildfile. I think I can make this happen, I'll let you know. It might take an additional patch to buildr.
We also need to hack the emma code inside of buildr to not try and download emma from a remote repository.
Once that is done, Mike needs to provide an extension to the command line interface to brew: something like brew-buildr, and then modify how that calls brew such that it knows to do a buildr -r localbuild type build. The localbuild file will be something that he controls as part of the mead/brew system, and that will manage the repos used to build candlepin.
On Thu, May 13, 2010 at 5:58 PM, Adam Young ayoung@redhat.com wrote:
Mike Bonnet was good enough to spend a couple of hours with me getting me up to speed on what he is doing with Mead. The short of it is that he has a middle grouind between mavne repository fetching and JPackage for building Maven based projects.
In order to take advantage of it, we have one of two choices.
- Move Candlepin over to maven
- Help him get Mead able to use buildr.
Note that this would produce a usable build without having to use all of the MySpec RPMS I built. We could selectively use them if we desire.
I like option 2, although I might not be able to see it through. In order to do this, we have to close the loop on buildr doing local repository builds. As I can see it this means modifying the -r localbuild option such that, once the localbuild script has modified the remote and local repository values, they can no longer be modified by the buildfile. I think I can make this happen, I'll let you know. It might take an additional patch to buildr.
I too like option 2 :) but I'm biased.
We also need to hack the emma code inside of buildr to not try and download emma from a remote repository.
Once that is done, Mike needs to provide an extension to the command line interface to brew: something like brew-buildr, and then modify how that calls brew such that it knows to do a buildr -r localbuild type build. The localbuild file will be something that he controls as part of the mead/brew system, and that will manage the repos used to build candlepin.
This is great for an officially supported release, but what about a community release? usually that has to occur from koji or something like that.
jesus
On 05/13/2010 10:41 PM, Jesus M. Rodriguez wrote:
On Thu, May 13, 2010 at 5:58 PM, Adam Youngayoung@redhat.com wrote:
Mike Bonnet was good enough to spend a couple of hours with me getting me up to speed on what he is doing with Mead. The short of it is that he has a middle grouind between mavne repository fetching and JPackage for building Maven based projects.
In order to take advantage of it, we have one of two choices.
- Move Candlepin over to maven
- Help him get Mead able to use buildr.
Note that this would produce a usable build without having to use all of the MySpec RPMS I built. We could selectively use them if we desire.
I like option 2, although I might not be able to see it through. In order to do this, we have to close the loop on buildr doing local repository builds. As I can see it this means modifying the -r localbuild option such that, once the localbuild script has modified the remote and local repository values, they can no longer be modified by the buildfile. I think I can make this happen, I'll let you know. It might take an additional patch to buildr.
I too like option 2 :) but I'm biased.
I am willing to go with option (2), but I look at this as somewhat of a rathole. If it starts to get nasty, I will be inclined to push to go to maven even though everyone will hate me for it.
We also need to hack the emma code inside of buildr to not try and download emma from a remote repository.
Once that is done, Mike needs to provide an extension to the command line interface to brew: something like brew-buildr, and then modify how that calls brew such that it knows to do a buildr -r localbuild type build. The localbuild file will be something that he controls as part of the mead/brew system, and that will manage the repos used to build candlepin.
This is great for an officially supported release, but what about a community release? usually that has to occur from koji or something like that.
good question. Are there plans for MEAD getting into the Fedora env?
-- bk
On 05/14/2010 08:30 AM, Bryan Kearney wrote:
On 05/13/2010 10:41 PM, Jesus M. Rodriguez wrote:
On Thu, May 13, 2010 at 5:58 PM, Adam Youngayoung@redhat.com wrote:
Mike Bonnet was good enough to spend a couple of hours with me getting me up to speed on what he is doing with Mead. The short of it is that he has a middle grouind between mavne repository fetching and JPackage for building Maven based projects.
In order to take advantage of it, we have one of two choices.
- Move Candlepin over to maven
- Help him get Mead able to use buildr.
Note that this would produce a usable build without having to use all of the MySpec RPMS I built. We could selectively use them if we desire.
I like option 2, although I might not be able to see it through. In order to do this, we have to close the loop on buildr doing local repository builds. As I can see it this means modifying the -r localbuild option such that, once the localbuild script has modified the remote and local repository values, they can no longer be modified by the buildfile. I think I can make this happen, I'll let you know. It might take an additional patch to buildr.
I too like option 2 :) but I'm biased.
I am willing to go with option (2), but I look at this as somewhat of a rathole. If it starts to get nasty, I will be inclined to push to go to maven even though everyone will hate me for it.
We discussed it, and the amount of work didn't seem too daunting. Mostly it was providing a different setup up, but the rest of the rules for a maven build still hold true for a buildr build.
We also need to hack the emma code inside of buildr to not try and download emma from a remote repository.
Once that is done, Mike needs to provide an extension to the command line interface to brew: something like brew-buildr, and then modify how that calls brew such that it knows to do a buildr -r localbuild type build. The localbuild file will be something that he controls as part of the mead/brew system, and that will manage the repos used to build candlepin.
This is great for an officially supported release, but what about a community release? usually that has to occur from koji or something like that.
good question. Are there plans for MEAD getting into the Fedora env?
This is a question above my paygrade, but my gut says that Mead is more a Red Hat solution for dealing with JBoss, and that the Fedora approach is going to continue to be JPackage based.
-- bk
candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
On 05/13/2010 10:41 PM, Jesus M. Rodriguez wrote:
On Thu, May 13, 2010 at 5:58 PM, Adam Youngayoung@redhat.com wrote:
Mike Bonnet was good enough to spend a couple of hours with me getting me up to speed on what he is doing with Mead. The short of it is that he has a middle grouind between mavne repository fetching and JPackage for building Maven based projects.
In order to take advantage of it, we have one of two choices.
- Move Candlepin over to maven
- Help him get Mead able to use buildr.
Note that this would produce a usable build without having to use all of the MySpec RPMS I built. We could selectively use them if we desire.
I like option 2, although I might not be able to see it through. In order to do this, we have to close the loop on buildr doing local repository builds. As I can see it this means modifying the -r localbuild option such that, once the localbuild script has modified the remote and local repository values, they can no longer be modified by the buildfile. I think I can make this happen, I'll let you know. It might take an additional patch to buildr.
I too like option 2 :) but I'm biased.
We also need to hack the emma code inside of buildr to not try and download emma from a remote repository.
Once that is done, Mike needs to provide an extension to the command line interface to brew: something like brew-buildr, and then modify how that calls brew such that it knows to do a buildr -r localbuild type build. The localbuild file will be something that he controls as part of the mead/brew system, and that will manage the repos used to build candlepin.
This is great for an officially supported release, but what about a community release? usually that has to occur from koji or something like that.
I suspect that the Fedora blessing will only come from a full JPackage approach. This approach is an intermediate step, but one that probably fills the official requirements for the project.
However, one side benefiet of the buildr/brew approach is that we can cascade the repositories. Mead/buildr will look first in the JPackage remote repo, and then in the various repositories defined by Mead. Then the Candlepin team can incrementally fill all of the dependencies with the JPackage RPMs until you have a full solution.
jesus _______________________________________________ candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/13/2010 05:58 PM, Adam Young wrote:
Mike Bonnet was good enough to spend a couple of hours with me getting me up to speed on what he is doing with Mead. The short of it is that he has a middle grouind between mavne repository fetching and JPackage for building Maven based projects.
In order to take advantage of it, we have one of two choices.
- Move Candlepin over to maven
- Help him get Mead able to use buildr.
Note that this would produce a usable build without having to use all of the MySpec RPMS I built. We could selectively use them if we desire.
Mike and/or Adam, so how does this actually work? Are there writeups on MEAD? How is it different from a regular rpm build?
I like option 2, although I might not be able to see it through. In order to do this, we have to close the loop on buildr doing local repository builds. As I can see it this means modifying the -r localbuild option such that, once the localbuild script has modified the remote and local repository values, they can no longer be modified by the buildfile. I think I can make this happen, I'll let you know. It might take an additional patch to buildr.
Adam, is there anything left to do with localbuild? I see there's one in the candlepin repo.
We also need to hack the emma code inside of buildr to not try and download emma from a remote repository.
Adam, is this change still necessary?
Once that is done, Mike needs to provide an extension to the command line interface to brew: something like brew-buildr, and then modify how that calls brew such that it knows to do a buildr -r localbuild type build. The localbuild file will be something that he controls as part of the mead/brew system, and that will manage the repos used to build candlepin.
So why does there need to be a brew-buildr? Doesn't the specfile control what build command gets called?
- -- jesus m. rodriguez | jesusr@redhat.com principal software engineer | irc: zeus red hat systems management | 919.754.4413 (w) rhce # 805008586930012 | 919.623.0080 (c) +---------------------------------------------+ | "Those who cannot remember the past | | are condemned to repeat it." | | -- George Santayana | +---------------------------------------------+
On 05/28/2010 01:10 PM, Jesus M. Rodriguez wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/13/2010 05:58 PM, Adam Young wrote:
Mike Bonnet was good enough to spend a couple of hours with me getting me up to speed on what he is doing with Mead. The short of it is that he has a middle grouind between mavne repository fetching and JPackage for building Maven based projects.
In order to take advantage of it, we have one of two choices.
- Move Candlepin over to maven
- Help him get Mead able to use buildr.
Note that this would produce a usable build without having to use all of the MySpec RPMS I built. We could selectively use them if we desire.
Mike and/or Adam, so how does this actually work? Are there writeups on MEAD? How is it different from a regular rpm build?
Basically, mead is going to be a blessed way of running Brew, that will use a "known good" set of binary Jars files for mavenized builds. Thus, the end prodcut won't be Fedora ready, but will be good for getting RH products based on Maven out the door in a supportable format. THis is primarily to help the JBoss folks
I like option 2, although I might not be able to see it through. In order to do this, we have to close the loop on buildr doing local repository builds. As I can see it this means modifying the -r localbuild option such that, once the localbuild script has modified the remote and local repository values, they can no longer be modified by the buildfile. I think I can make this happen, I'll let you know. It might take an additional patch to buildr.
Adam, is there anything left to do with localbuild? I see there's one in the candlepin repo.
localbuild is for the full Fedora approach. So, in order to close the loop there, you need to be able to build completely using the JPackage repository. Ideally, the localbuild setup would end up in the buildr rpm, with values that would come from the Spec file ie
buildr --jpackage compile
We also need to hack the emma code inside of buildr to not try and download emma from a remote repository.
Adam, is this change still necessary?
I think so. Emma downloads from a different repo definition, and that would violate both the mead and the jpackage approaches.
Once that is done, Mike needs to provide an extension to the command line interface to brew: something like brew-buildr, and then modify how that calls brew such that it knows to do a buildr -r localbuild type build. The localbuild file will be something that he controls as part of the mead/brew system, and that will manage the repos used to build candlepin.
So why does there need to be a brew-buildr? Doesn't the specfile control what build command gets called?
mead is a modification to brew so that it knows about maven. Thus, mead would need to be modified to know about buildr, although it would use much common code for both build systems.
jesus m. rodriguez | jesusr@redhat.com principal software engineer | irc: zeus red hat systems management | 919.754.4413 (w) rhce # 805008586930012 | 919.623.0080 (c) +---------------------------------------------+ | "Those who cannot remember the past | | are condemned to repeat it." | | -- George Santayana | +---------------------------------------------+
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkv/+O0ACgkQvJZ57YntiYOjcgCdEe5efy7AFwPUYwI1jIQFL0BF 7DkAni713DQq7ni25907JXYp/CbVr7p0 =vC1p -----END PGP SIGNATURE-----
On 05/28/2010 01:38 PM, Adam Young wrote:
We also need to hack the emma code inside of buildr to not try and download emma from a remote repository.
Adam, is this change still necessary?
I think so. Emma downloads from a different repo definition, and that would violate both the mead and the jpackage approaches.
Can we make it so that emma is not run as part of the normal build? I would like it on in the continuous build, but does not need to be on as part of brew.
-- bk
On 05/28/2010 01:10 PM, Jesus M. Rodriguez wrote:
On 05/13/2010 05:58 PM, Adam Young wrote:
Mike Bonnet was good enough to spend a couple of hours with me getting me up to speed on what he is doing with Mead. The short of it is that he has a middle grouind between mavne repository fetching and JPackage for building Maven based projects.
In order to take advantage of it, we have one of two choices.
- Move Candlepin over to maven
- Help him get Mead able to use buildr.
Note that this would produce a usable build without having to use all of the MySpec RPMS I built. We could selectively use them if we desire.
Mike and/or Adam, so how does this actually work? Are there writeups on MEAD? How is it different from a regular rpm build?
The best write-up on MEAD at a high level is in a proposal to use it in Fedora (note this hasn't really been discussed with a wide audience yet):
http://fedoraproject.org/wiki/KojiMavenSupport
I like option 2, although I might not be able to see it through. In order to do this, we have to close the loop on buildr doing local repository builds. As I can see it this means modifying the -r localbuild option such that, once the localbuild script has modified the remote and local repository values, they can no longer be modified by the buildfile. I think I can make this happen, I'll let you know. It might take an additional patch to buildr.
Adam, is there anything left to do with localbuild? I see there's one in the candlepin repo.
We also need to hack the emma code inside of buildr to not try and download emma from a remote repository.
Adam, is this change still necessary?
Once that is done, Mike needs to provide an extension to the command line interface to brew: something like brew-buildr, and then modify how that calls brew such that it knows to do a buildr -r localbuild type build. The localbuild file will be something that he controls as part of the mead/brew system, and that will manage the repos used to build candlepin.
So why does there need to be a brew-buildr? Doesn't the specfile control what build command gets called?
The top-level entry-point to a MEAD build is a Maven pom.xml file. buildr has a different entry point, so MEAD would need to be modified to understand and use that.
Note that buildr support is *way* down on my priority list, and I haven't even discussed with the rest of RCM is buildr is a tool we want/need to support directly in Brew/MEAD. The better alternative in my view is getting Candlepin to use Maven instead of buildr.
On Fri, May 28, 2010 at 01:49:39PM -0400, Mike Bonnet wrote:
On 05/28/2010 01:10 PM, Jesus M. Rodriguez wrote:
On 05/13/2010 05:58 PM, Adam Young wrote:
[snip]
The best write-up on MEAD at a high level is in a proposal to use it in Fedora (note this hasn't really been discussed with a wide audience yet):
Thanks for that information.
[snip]
The top-level entry-point to a MEAD build is a Maven pom.xml file. buildr has a different entry point, so MEAD would need to be modified to understand and use that.
Note that buildr support is *way* down on my priority list, and I haven't even discussed with the rest of RCM is buildr is a tool we want/need to support directly in Brew/MEAD. The better alternative in my view is getting Candlepin to use Maven instead of buildr.
I understand. I didn't know how far along MEAD has come. The original thought was to get all of the dependent rpms packaged, then use normal BuildRequires: in the spec file, and have buildr pull in the jars locally from /usr/share/java. We did something similar with Satellite using ant.
On 05/28/2010 03:01 PM, Jesus Rodriguez wrote:
On Fri, May 28, 2010 at 01:49:39PM -0400, Mike Bonnet wrote:
On 05/28/2010 01:10 PM, Jesus M. Rodriguez wrote:
On 05/13/2010 05:58 PM, Adam Young wrote:
[snip]
The best write-up on MEAD at a high level is in a proposal to use it in Fedora (note this hasn't really been discussed with a wide audience yet):
Thanks for that information.
[snip]
The top-level entry-point to a MEAD build is a Maven pom.xml file. buildr has a different entry point, so MEAD would need to be modified to understand and use that.
Note that buildr support is *way* down on my priority list, and I haven't even discussed with the rest of RCM is buildr is a tool we want/need to support directly in Brew/MEAD. The better alternative in my view is getting Candlepin to use Maven instead of buildr.
I understand. I didn't know how far along MEAD has come. The original thought was to get all of the dependent rpms packaged, then use normal BuildRequires: in the spec file, and have buildr pull in the jars locally from /usr/share/java. We did something similar with Satellite using ant.
I still think that is the best long term approach. The Mead approach is more for getting a product available in a shorter time frame. Considering the large number of build deps that Candlepin has currently, getting them all into Fedora is a lot of work. I'd not want to delay shipping Candlepin due to still hunting down those issues. Thus the mead approach is, for Candlepin, a stopgap. Perhaps making a skeleton Maven pom that works with mead but that doesn't have the full set of developers tool would be a short cut.
candlepin@lists.stg.fedorahosted.org
-
Adam Young -
Bryan Kearney -
Jesus M. Rodriguez -
jesus rodriguez -
Mike Bonnet