I just had a successful build with all unit tests passing.

In order to do this, I needed the version of buildr I created, and called buildr from the command line with:

buildr -f buildfile.new -r localbuild.rb package

localbuild.rb is checked in, but I haven't added my version of the buildfile: I'll attach it here. I've tried to keep the versions of the RPMs I use consistant with the ones from the original buildfile. The biggest diversion is quartz, which has a very heavy dependency list, and on versions of jakarta-commons that are not compatible with the rest of the project. This, I've used a much older version of quartz. If this proves to be a problem, I can battle through getting the more recent one built.

These are the JPackage RPMS I have installed. These is a mix of 5 and 6 in there.

jakarta-commons-logging-1.1.1-2.jpp6.noarch jboss-transaction-1.0.1-api-5.0.1-2.jpp6.noarch jakarta-commons-httpclient-3.1-1.jpp6.noarch geronimo-specs-poms-1.2-13.jpp5.noarch jboss-javaee-poms-5.0.1-2.jpp6.noarch geronimo-specs-poms-1.2-13.jpp6.noarch jdom-1.1.1-2.jpp6.noarch hibernate3-ejb-persistence-3.0-api-1.0.2-4.jpp6.noarch aopalliance-1.0-5.jpp6.noarch antlr-2.7.6-7.jpp6.noarch dom4j-1.6.1-12.jpp6.noarch asm-1.5.3-7.jpp5.noarch jakarta-commons-logging-jboss-1.1-4.jpp5.noarch hibernate3-entitymanager-3.4.0-2.7.jpp6.noarch jboss-common-core-2.2.14-2.jpp6.noarch glassfish-javamail-1.4.0-4.jpp6.noarch hibernate3-annotations-3.4.0-1.4.jpp6.noarch plexus-containers-component-api-1.0-0.a32.3.jpp5.noarch geronimo-ejb-3.0-api-1.2-13.jpp5.noarch geronimo-jta-1.1-api-1.2-13.jpp6.noarch jboss-common-logging-spi-2.1.0-2.jpp6.noarch glassfish-jaf-1.1.0-6.jpp6.noarch hibernate3-commons-annotations-3.1.0-3.jpp6.noarch jakarta-commons-modeler-2.0-5.jpp5.noarch cglib-2.2-4.jpp6.noarch

I think the glassfish ones are required for building quartz, and are not strictly speaking necessary.

This is an incomplete list of the ones I've built by hand:

guice-throwingproviders-2.0-4.young.noarch guice-assistedinject-2.0-4.young.noarch jakarta-commons-cli-1.2-4.young.noarch jta-1.1-3.young.noarch persistence-api-1.0-3.young.noarch hibernate-commons-annotations-3.3.0.ga-1.young.noarch jakarta-commons-dbcp-1.4-3.young.noarch servlet-api-2.5-3.young.noarch jakarta-commons-collections-testframework-3.2.1-5.young.x86_64 guice-multibindings-2.0-2.young.noarch commons-dbcp-1.4-3.young.noarch hibernate3-validator-3.1.0-4.young.noarch resteasy-guice-1.2.1.GA-4.young.noarch hibernate-tools-3.2.4.GA-3.young.noarch guice-2.0-5.young.noarch jakarta-commons-collections-3.2.1-5.young.x86_64 guice-servlet-2.0-2.young.noarch

emma-2.0-0.5312.5.fc12.noarch

I only recently started tagging my builds with young, so I have others that were built with fc12.

Here is a list of RPMS I've forced in with --nodeps.

freemarker-2.3.15-1.jpp5.noarch.rpm jdom-1.1.1-2.jpp6.noarch.rpm dom4j-1.6.1-12.jpp6.noarch.rpm jakarta-commons-modeler-2.0-5.jpp5.noarch.rpm quartz-1.5.2-7.fc12.noarch.rpm geronimo-ejb-3.0-api-1.2-13.jpp5.noarch.rpm

On 04/27/2010 02:49 PM, Jesus Rodriguez wrote:

Adam,

I'm in the process of writing a script that will convert your MySpecs tree into something I can use tito with to submit the pkgs into koji.rhndev.

Basically the structure would be one dir per project, for example, emma would be turned into:

 MySpecs/emma
 MySpecs/emma/emma.spec
 MySpecs/emma/emma-2.0.5312-build_xml.patch
 MySpecs/emma/emma-2.0.5312-code-source.patch
 MySpecs/emma/emma-2.0.5312-dependencies_xml.patch
 MySpecs/emma/emma-2.0.5312-no-javac-target.patch
 MySpecs/emma/emma-2.0.5312-no-version-stamp-tool.patch
 MySpecs/emma/emma-2.0.5312.pom
 MySpecs/emma/emma-2.0.5312-src.zip
 MySpecs/emma/emma_ant-2.0.5312.pom

In the process of writing my script I found that some of the Sources / Patches referenced by the spec files are NOT in your SOURCES directory.

For example,

ls: cannot access SOURCES/buildr-buildpath.patch: No such file or directory ls: cannot access SOURCES/heckle-local.patch: No such file or directory

Do these need to be checked in? where are they?

The reason behind what I'm doing is very similar to the thirdparty tree we built for spacewalk. It allowed us to manage third party packages which were not in fedora/rhel that we needed in koji.rhndev to build spacewalk. This is the example same situation with the packages in your MySpecs. This will all go away once we push these upstream, but for now I think this will work.

My plan was to:

• get the script written (mostly done)
• fork MySpecs on github
• run the script
• prep repo for tito
• commit / push
• have you do a pull request to merge in the changes

Thoughts?

jesus