On 04/16/2010 08:08 AM, Bryan Kearney wrote:
great
work! I Assume you are sending this back to our JBoss bretheren?
I will, once we have a complete working product. The JBoss folks won't
be impressed, as they are on a later version of tools: 3.3. versus our
work which is 3.2. JPackage would like it, and probably Fedora.
I see this as part of the larger effort to getting a clean Java
development methodology for working inside Fedora. I'll do a complete
write up of my approach, and I'll post the tools I use in a git repo,
with the goal of having them get into Fedora as well, either as a stand
along project, or as a part of the jpackage-utils. Since I wrote in
ruby, my guess is that it will be a separate project, at least to start.
A couple other things on top of the list below: We'll need to provide
the pom.xml file used to generate the spec, and update the JPackage
mapping for Maven....
Which leads me into the buildr approach. The JPackage folks have an
interesting approach to Maven. THere is a mapping file installed in
/etc/maven named
maven2-depmap.xml
which, if I understand correctly, is generated from the files in
/etc/maven/fragments and assembled when a new RPM gets installed. When
you run maven with the switches
-Dmaven2.offline.mode -Dmaven2.ignore.versions -Dmaven2.usejppjars
or the shortcut
mvn-jpp
It should use the jars from /usr/share/java as specified by the depmap
file. I think we would like to be consistent with this approach in
buildr. Yes, it is more xml, but that is the price we pay for
bootstrapping off of maven in the first place.
-- bk
On 04/15/2010 08:50 PM, Adam Young wrote:
Jesus,
I'm more than willing to do that, if I understood what Tito gave us. I
need to learn more about it.
I still need to clean up the specs significantly. Some items:
1. Push the sources.jars into the /usr/share/jave dirs
2. Figuring out why I have both jakarta-commons and commons versions
of
some of the files. I might need to rename and respin the
jakarta-commons files to keep the convention with RHEL/Fedora
3. It looks like I havea a fvew Gernoimo files for stuff like
/usr/share/jta.jar. I suspect that thes should be dependencies on the
files and not the packages.
4. Clean up the versioning. For the most part, I use the simple named
jar file from usr/share/java, which might not be correct.
And of course, we need to make these things work.
For using buildr to make an RPM, we have two ways we can go. We can
either force it to look for all dependencies in /usr/share/java (my
preference) or we can build a symlinked maven repo inside of BUILDROOT.
I don't lioke this becaueI don't want buildr to decide to download
something sua sponte.
On 04/15/2010 08:18 PM, Jesus M. Rodriguez wrote:
Sweet, and yes patching is acceptable IMO
:) Awesome work.
Also, not to be a tito zealot, but with your MySpecs project, it would
be
quite easy to integrate tito into that and use it to manage all of your
spec files. Tagging, etc as you go along. We did this with a bunch of
third party jars for Spacewalk as well. :) But that's my sales pitch
for
the day.
jesus
On Thu, Apr 15, 2010 at 7:21 PM, Adam Young<ayoung@redhat.com>
wrote:
OK, I couldn't quite give up on hibernate
tools, so I just spent one
more day on it and...well, I got it to compile. I haven't tested it,
nor any of the other RPMS for that matter.
Hibernate tools was the only one I had to patch. Once I accepted that
this was a viable route, I was happy.
In the version of Hibernate that tools was origianlly built against,
therei s a class called CacheFactory that basically pulls in a mother
load of other dependencies. Really poor design. It also has four
symbolic constants for strings. It was only these strings that the
rest
of the build needed, which means that this class wasn't even loaded at
run time: javac replaces the strings with the literals anyway. So, I
hacked everything but the symbolic constants out of the class and added
in via a patch.
diff -Nurd
hibernate-tools-needed-classes/org/hibernate/cache/CacheFactory.java
hibernate-tools-3.2.4.GA.new/org/hibernate/cache/CacheFactory.java
---
hibernate-tools-needed-classes/org/hibernate/cache/CacheFactory.java
1969-12-31 19:00:00.000000000 -0500
+++
hibernate-tools-3.2.4.GA.new/org/hibernate/cache/CacheFactory.java
2010-04-15 19:04:03.091745593 -0400
@@ -0,0 +1,13 @@
+//$Id: CacheFactory.java 5685 2005-02-12 07:19:50Z steveebersole $
+package org.hibernate.cache;
+
+/**
+ * @author Gavin King
+ */
+public final class CacheFactory {
+
+ public static final String READ_ONLY = "read-only";
+ public static final String READ_WRITE = "read-write";
+ public static final String NONSTRICT_READ_WRITE =
"nonstrict-read-write";
+ public static final String TRANSACTIONAL = "transactional";
+}
With that, I should be done, but Dmitri snuck in yet another dependency
on me today. I'll get that tomorrow.
_______________________________________________
candlepin mailing list
candlepin@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/candlepin
_______________________________________________
candlepin mailing list
candlepin@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/candlepin
_______________________________________________
candlepin mailing list
candlepin@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/candlepin