6:21 p.m.
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.
7:18 p.m.
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(a)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(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/candlepin
7:50 p.m.
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(a)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(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/candlepin
>
>
_______________________________________________
candlepin mailing list
candlepin(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/candlepin
7:08 a.m.
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:
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(a)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(a)lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/candlepin
>>
>>
> _______________________________________________
> candlepin mailing list
> candlepin(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/candlepin
>
_______________________________________________
candlepin mailing list
candlepin(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/candlepin
8:14 a.m.
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(a)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(a)lists.fedorahosted.org
>>> https://fedorahosted.org/mailman/listinfo/candlepin
>>>
>>>
>> _______________________________________________
>> candlepin mailing list
>> candlepin(a)lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/candlepin
>>
>
> _______________________________________________
> candlepin mailing list
> candlepin(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/candlepin
10:24 a.m.
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(a)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 Young<ayoung(a)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(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/candlepin
_______________________________________________
candlepin mailing list
candlepin(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/candlepin
_______________________________________________
candlepin mailing list
candlepin(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/candlepin
_______________________________________________
candlepin mailing list
candlepin(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/candlepin
--
Devan Goodwin <dgoodwin(a)rm-rf.ca>
http://rm-rf.ca
9:21 a.m.
New subject: wiki update
Documentation on internationalization is up on the wiki:
https://fedorahosted.org/candlepin/wiki/I18n
cheers,
-d
5131
days inactive
5132
days old
candlepin@lists.fedorahosted.org
6 comments
5 participants
participants (5)
-
Adam Young -
Bryan Kearney -
Devan Goodwin -
Dmitri Dolguikh -
Jesus M. Rodriguez