Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.3.1
    • Fix Version/s: 3.0-M1
    • Component/s: None
    • Labels:
      None

      Activity

      Hide
      Robert Burrell Donkin added a comment -

      Submit a patch

      (I'll review it unless anyone beats me to it)

      Show
      Robert Burrell Donkin added a comment - Submit a patch (I'll review it unless anyone beats me to it)
      Hide
      Amichai Rothman added a comment -

      c'mon, it'll take me longer to even just do an svn checkout

      I actually can't even find the repo link on the site - or am I missing it?

      anyway, the API hasn't changed, so it's just a matter of replacing the jar and the link from the build script...

      Show
      Amichai Rothman added a comment - c'mon, it'll take me longer to even just do an svn checkout I actually can't even find the repo link on the site - or am I missing it? anyway, the API hasn't changed, so it's just a matter of replacing the jar and the link from the build script...
      Hide
      Stefano Bagnara added a comment -

      It is not as straightforward as it can seem. I had a big issue when upgrading javamail to 1.4.2 because they changed the way they handle nested encoding in multipart messages. The new way is RFC compliant but I had to fix a lot of code in order to make my deployment work with javamail 1.4.2 instead of 1.4.1.

      A javamail upgrade would require a lot of testing, more than what we are probably willing to do for a 2.3.x release.

      So I think it is better to let some people simply replace the javamail library in their deployment if they need the updated one, for 2.3.1..

      Show
      Stefano Bagnara added a comment - It is not as straightforward as it can seem. I had a big issue when upgrading javamail to 1.4.2 because they changed the way they handle nested encoding in multipart messages. The new way is RFC compliant but I had to fix a lot of code in order to make my deployment work with javamail 1.4.2 instead of 1.4.1. A javamail upgrade would require a lot of testing, more than what we are probably willing to do for a 2.3.x release. So I think it is better to let some people simply replace the javamail library in their deployment if they need the updated one, for 2.3.1..
      Hide
      Robert Burrell Donkin added a comment -

      You're missing it

      Details are in the usual place for a maven site (click on link to 2.3.1 documentation then take a look under project information)

      Show
      Robert Burrell Donkin added a comment - You're missing it Details are in the usual place for a maven site (click on link to 2.3.1 documentation then take a look under project information)
      Hide
      Amichai Rothman added a comment -

      ok, thanks

      I find it somewhat unintuitive - the place I'd expect it is under 'source code' or the 'binary and source' link to the downlaod page - that's generally were svn urls are found in OSS projects. It would actually make a lot of sense if the svn web-viewer (the 'source code' link) would show the real non-web svn url somewhere...

      Show
      Amichai Rothman added a comment - ok, thanks I find it somewhat unintuitive - the place I'd expect it is under 'source code' or the 'binary and source' link to the downlaod page - that's generally were svn urls are found in OSS projects. It would actually make a lot of sense if the svn web-viewer (the 'source code' link) would show the real non-web svn url somewhere...
      Hide
      Robert Burrell Donkin added a comment -

      Submit a patch

      Seriously - 2.3.1 is short of love and attention

      I (and most of the active developers) use the 3.x code base. I know a lot of users want to see more 2.3.1 releases and features but that's not going to happen unless contributors interested in that code base step up.

      Show
      Robert Burrell Donkin added a comment - Submit a patch Seriously - 2.3.1 is short of love and attention I (and most of the active developers) use the 3.x code base. I know a lot of users want to see more 2.3.1 releases and features but that's not going to happen unless contributors interested in that code base step up.
      Hide
      Amichai Rothman added a comment -

      Speaking for myself, I can't exactly say that I'm interested in more releases and features from a codebase with no active developers, targeted at Java 1.4 (won't even compile on 6), with chunks of the project's wiki (task-related pages) last updated 4 years ago, based on some framework projects that have been discontinued years ago... at least that's the impression the project is making in the past couple of years - that it is a dying one.

      But, I wouldn't want to abandon it either. As a user, the alternatives are either the above, or a trunk 3.0 version whose status, progress and future is not quite clear either. Perhaps it's time for a proper alternative? Perhaps an alpha/beta of 3, with a fresh feeling of liveliness? Something to show a clear sign of activity and progress? cleaning up the wiki from ancient roadmaps and plans which have been abandoned long ago? I think that feeling of freshness would make it much easier to contribute than the current uninviting feeling of gloom... I contribute to several projects in my spare time, and this one somehow always gets pushed to the bottom of the list because of that feeling of 'who knows if it's not already dead? Are there more than a dozen users still using it? haven't seen any movement there in too long... why bother?'

      ...is it just me?

      Show
      Amichai Rothman added a comment - Speaking for myself, I can't exactly say that I'm interested in more releases and features from a codebase with no active developers, targeted at Java 1.4 (won't even compile on 6), with chunks of the project's wiki (task-related pages) last updated 4 years ago, based on some framework projects that have been discontinued years ago... at least that's the impression the project is making in the past couple of years - that it is a dying one. But, I wouldn't want to abandon it either. As a user, the alternatives are either the above, or a trunk 3.0 version whose status, progress and future is not quite clear either. Perhaps it's time for a proper alternative? Perhaps an alpha/beta of 3, with a fresh feeling of liveliness? Something to show a clear sign of activity and progress? cleaning up the wiki from ancient roadmaps and plans which have been abandoned long ago? I think that feeling of freshness would make it much easier to contribute than the current uninviting feeling of gloom... I contribute to several projects in my spare time, and this one somehow always gets pushed to the bottom of the list because of that feeling of 'who knows if it's not already dead? Are there more than a dozen users still using it? haven't seen any movement there in too long... why bother?' ...is it just me?
      Hide
      Stefano Bagnara added a comment -

      @Amichai ... please use the mailing list for this kind of comments. Here we should only discuss the issue "Upgrade to Javamail 1.4.2" related to the "2.3.1" release.

      Show
      Stefano Bagnara added a comment - @Amichai ... please use the mailing list for this kind of comments. Here we should only discuss the issue "Upgrade to Javamail 1.4.2" related to the "2.3.1" release.
      Hide
      Amichai Rothman added a comment -

      I apologize - I will.

      As for javamail, since I am not aware of the issues Stefano mentioned a few comments up, I can't do anything about fixing or patching them. I just dropped in the new jar and it seems to work so I didn't realize there was more to it. So I guess this bug can be closed as wontfix, as Stefano implied.

      If trunk/3 isn't using javamail 1.4.2 either, u might want to upgrade it there.

      Thanks

      Show
      Amichai Rothman added a comment - I apologize - I will. As for javamail, since I am not aware of the issues Stefano mentioned a few comments up, I can't do anything about fixing or patching them. I just dropped in the new jar and it seems to work so I didn't realize there was more to it. So I guess this bug can be closed as wontfix, as Stefano implied. If trunk/3 isn't using javamail 1.4.2 either, u might want to upgrade it there. Thanks
      Hide
      Norman Maurer added a comment -

      Trunk was upgraded to javamail 1.4.3

      Show
      Norman Maurer added a comment - Trunk was upgraded to javamail 1.4.3

        People

        • Assignee:
          Norman Maurer
          Reporter:
          Amichai Rothman
        • Votes:
          0 Vote for this issue
          Watchers:
          1 Start watching this issue

          Dates

          • Created:
            Updated:
            Resolved:

            Development