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.
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
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 Youngayoung@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
great work! I Assume you are sending this back to our JBoss bretheren?
-- 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:
- Push the sources.jars into the /usr/share/jave dirs
- 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 Youngayoung@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
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:
- Push the sources.jars into the /usr/share/jave dirs
- 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 Youngayoung@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
Very cool, nice to hear we might be doing something that could help with the larger state of affairs of Java in Fedora. Kudos!
On Fri, Apr 16, 2010 at 10:14 AM, Adam Young ayoung@redhat.com wrote:
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 Youngayoung@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
candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
Documentation on internationalization is up on the wiki: https://fedorahosted.org/candlepin/wiki/I18n
cheers, -d
candlepin@lists.stg.fedorahosted.org
-
Adam Young -
Bryan Kearney -
Devan Goodwin -
Dmitri Dolguikh -
Jesus M. Rodriguez