Joda-time in jruby-complete-1.4.0RC1?

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 ?

with regards Kristian


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

On Fri, Oct 9, 2009 at 12:05 PM, kristian [email protected] wrote:

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

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

the jar file I got/get from
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 :wink:

I check the file size as well the md5sum and they all match.

with regards Kristian

On Sat, Oct 10, 2009 at 12:49 AM, Charles Oliver N.
[email protected] wrote:

  • 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
        '_) (_`
        /__/  \
     _(<_   / )_
  (__\_\_|_/__)

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

On Sat, Oct 10, 2009 at 8:59 AM, Charles Oliver N.
[email protected] 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. :slight_smile:

TX


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

On Sat, Oct 10, 2009 at 10:35 PM, Trejkaz [email protected] wrote:

On Sat, Oct 10, 2009 at 8:59 AM, Charles Oliver N.
[email protected] 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. :slight_smile:

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

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

I was away the last two days so my late response:

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 N.
[email protected] wrote:

Agreed…but I don’t know of a better solution. There’s a number of

  • 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
        '_) (_`
        /__/  \
     _(<_   / )_
  (__\_\_|_/__)

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Charles Nutter wrote:

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

Oh, I think we started renaming the package with jarjar to avoid
conflicting with other copies of joda.

  • Charlie (mobile)

On Oct 9, 2009, at 16:13, kristian [email protected] wrote:

[email protected] wrote:

http://xircles.codehaus.org/manage_email


To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

On Mon, Oct 12, 2009 at 3:44 AM, Stephen Colebourne
[email protected] wrote:

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

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

On Mon, Oct 12, 2009 at 11:01 AM, Charles Oliver N.
[email protected] 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

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

On Mon, Oct 12, 2009 at 10:31 PM, Charles Oliver N.
[email protected] 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:


joda-time
joda-time
1.6


org.jruby
jruby
1.3.1


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

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
        '_) (_`
        /__/  \
     _(<_   / )_
  (__\_\_|_/__)

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email