[jruby-user] joda-time in jruby-complete-1.4.0RC1 ?
kristian
when I switched from jruby-complete-1.3.1 to
jruby-complete-1.4.0RC1.jar I missed joda-time. or do I have a
corrupted jar ?
with regards Kristian
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Charles Oliver Nutter
> hello,
>
> when I switched from jruby-complete-1.3.1 to
> jruby-complete-1.4.0RC1.jar I missed joda-time. or do I have a
> corrupted jar ?
Hmm...nothing should have changed as far as joda goes. We pack it into
the main released jar file. What do you mean "missed joda-time"?
- Charlie
kristian
http://repo1.maven.org/maven2/org/jruby/jruby-complete/1.4.0RC1/
has no org/joda package. that is what I meant I miss it ;-)
I check the file size as well the md5sum and they all match.
with regards Kristian
--
Kristian Meier + Saumya Sharma + Sanuka Meier
Vadakkethu House,
Edayanmula West PO - 689532,
Pathanamthitta District, Kerala, INDIA
tel: +91 468 2319577
protect your privacy while searching the net: www.ixquick.com
_=_
q(-_-)p
'_) (_`
/__/ \
_(<_ / )_
(__\_\_|_/__)
Charles Oliver Nutter
conflicting with other copies of joda.
- Charlie (mobile)
Trejkaz
<hea...@headius.com> wrote:
> Oh, I think we started renaming the package with jarjar to avoid conflicting
> with other copies of joda.
This is good to hear from a clashing perspective, although not so
great for those of us worried about the size of our installers
increasing, as we'll need two copies of joda-time now. :-)
TX
Charles Oliver Nutter
> On Sat, Oct 10, 2009 at 8:59 AM, Charles Oliver Nutter
> <hea...@headius.com> wrote:
>> Oh, I think we started renaming the package with jarjar to avoid conflicting
>> with other copies of joda.
>
> This is good to hear from a clashing perspective, although not so
> great for those of us worried about the size of our installers
> increasing, as we'll need two copies of joda-time now. :-)
Agreed...but I don't know of a better solution. There's a number of
libraries that basically everyone ships now...Joda and ASM are two of
them, and now that we rename them internally, we essentially force
every install to double-up on those libs. But this is nothing new, and
other libraries/apps/projects ship them *unmangled* meaning we can end
up conflicting with the versions they've chosen.
I'm hoping it will be possible to ship only the parts of ASM and Joda
that we're actually using with a little build-file trickery, but
that's the best suggestion I have.
- Charlie
kristian
when I switch the build for the dataobjects drivers (from datamapper)
to jruby1.4.0RC1 then they did not compile anymore because the the
method
getDateTime on RubyTime does return jruby.joda.DateTime now instead of
org.joda.DateTime before.
looking at the git code I still see org.joda.DateTime and the mapping
is done with jarjar at certain point during the build process. even
building the javadocs will show the "wrong" class name.
I am sure there was big discussion about this, but repacking of
classes which are part of the "public" api breaks code which uses that
api.
reducing the joda-time classes to a minimum which is used by jruby
needs to be documented clearly especially when it joda classes remain
part of the public api.
reading the source code and/or javadocs can be confusing if the source
and the binary do not fit together in terms of absolute classnames.
for dataobjects the simplest solution is to follow jruby and disallow
older versions of jruby which is kind of OK since there was not a
release yet and these classes are only internal.
regards Kristian
On Sun, Oct 11, 2009 at 10:14 AM, Charles Oliver Nutter
--
Kristian Meier + Saumya Sharma + Sanuka Meier
Vadakkethu House,
Edayanmula West PO - 689532,
Pathanamthitta District, Kerala, INDIA
tel: +91 468 2319577
protect your privacy while searching the net: www.ixquick.com
_=_
q(-_-)p
'_) (_`
/__/ \
_(<_ / )_
(__\_\_|_/__)
---------------------------------------------------------------------
Stephen Colebourne
>>> Oh, I think we started renaming the package with jarjar to avoid conflicting
>>> with other copies of joda.
As the author of Joda-Time I think this is a really bad idea. I also
think the comparison to ASM is inaccurate. (Picked up this discussion
via Google Alerts, as I don't follow JRuby).
Each version of Joda-Time released so far has been fully compatible with
the previous. This has required great care, and is a strictly observed
policy. The only possible changes envisaged are the removal of long
deprecated classes.
Any future breaking changes will be released in a separate package,
causing no jar-hell situations.
The second problem, and where Joda-Time is different to ASM, is that
Joda-Time is a common class passed as a parameter between different
libraries. Changing the package thus breaks the ability for a JRuby user
to pass an instance of this class to another library. (Whereas ASM is
typically used internally within a framework and is not exposed)
I would like to see the JRuby team reconsider this choice.
Stephen
--
Posted via http://www.ruby-forum.com/.
Charles Oliver Nutter
<hea...@headius.com> wrote:
> This is a good point, also made by Kristian Meier; since the Joda
> classes *are* exposed through some JRuby APIs, mangling them mangles
> those APIs and makes it impossible to integrate JRuby with other
> consumers of Joda classes. Because of this aspect I think we should
> un-mangle.
Bug filed: http://jira.codehaus.org/browse/JRUBY-4089
- Charlie
Charles Oliver Nutter
<li...@ruby-forum.com> wrote:
> As the author of Joda-Time I think this is a really bad idea. I also
> think the comparison to ASM is inaccurate. (Picked up this discussion
> via Google Alerts, as I don't follow JRuby).
>
> Each version of Joda-Time released so far has been fully compatible with
> the previous. This has required great care, and is a strictly observed
> policy. The only possible changes envisaged are the removal of long
> deprecated classes.
>
> Any future breaking changes will be released in a separate package,
> causing no jar-hell situations.
We actually started mangling at the request of JRuby users:
http://jira.codehaus.org/browse/JRUBY-3559
In this case, another package shipped a newer version of Joda that
added a method. The one shipped in JRuby's jar got picked up, causing
that package to break. So it was a valid case for mangling the package
name, at least to avoid the conflict. However...
> The second problem, and where Joda-Time is different to ASM, is that
> Joda-Time is a common class passed as a parameter between different
> libraries. Changing the package thus breaks the ability for a JRuby user
> to pass an instance of this class to another library. (Whereas ASM is
> typically used internally within a framework and is not exposed)
This is a good point, also made by Kristian Meier; since the Joda
classes *are* exposed through some JRuby APIs, mangling them mangles
those APIs and makes it impossible to integrate JRuby with other
consumers of Joda classes. Because of this aspect I think we should
un-mangle.
- Charlie
kristian
<hea...@headius.com> wrote:
>
> We actually started mangling at the request of JRuby users:
>
> http://jira.codehaus.org/browse/JRUBY-3559
>
> In this case, another package shipped a newer version of Joda that
> added a method. The one shipped in JRuby's jar got picked up, causing
> that package to break. So it was a valid case for mangling the package
> name, at least to avoid the conflict. However...
>
just played around with that issue using maven. setting up the
classpath or depedencies:
<dependencies>
<dependency>
<groupId>joda-time</groupId>
<artifactId>joda-time</artifactId>
<version>1.6</version>
</dependency>
<dependency>
<groupId>org.jruby</groupId>
<artifactId>jruby</artifactId>
<version>1.3.1</version>
</dependency>
</dependencies>
works OK, the joda-time-1.6.jar gets loaded first with the maven
classloader. changing the order of the two jar files results in a
compile error.
in other similar situations I used to put the such jar files into bootclasspath.
with regards
Kristian
>> The second problem, and where Joda-Time is different to ASM, is that
>> Joda-Time is a common class passed as a parameter between different
>> libraries. Changing the package thus breaks the ability for a JRuby user
>> to pass an instance of this class to another library. (Whereas ASM is
>> typically used internally within a framework and is not exposed)
>
> This is a good point, also made by Kristian Meier; since the Joda
> classes *are* exposed through some JRuby APIs, mangling them mangles
> those APIs and makes it impossible to integrate JRuby with other
> consumers of Joda classes. Because of this aspect I think we should
> un-mangle.
>
> - Charlie
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
--
Kristian Meier + Saumya Sharma + Sanuka Meier
Vadakkethu House,
Edayanmula West PO - 689532,
Pathanamthitta District, Kerala, INDIA
tel: +91 468 2319577
protect your privacy while searching the net: www.ixquick.com
_=_
q(-_-)p
'_) (_`
/__/ \
_(<_ / )_
(__\_\_|_/__)
---------------------------------------------------------------------