Hi Scott, I'm currently releasing commons-email-1.2 but need to cut another RC tomorrow - if you would like to play with the last RC
Tag: https://svn.apache.org/repos/asf/commons/proper/email/tags/EMAIL_1_2 Site: http://people.apache.org/builds/commons/email/1.2/RC1/site/index.html Binaries: http://people.apache.org/builds/commons/email/1.2/RC1/staged/commons-email/commons-email/1.2/ Cheers, Siegfried Goeschl Scott Eade wrote: > Siegfried, > > Do you happen to be in a position to push out an updated version of > commons-email? > > I assume you are just rolling your own jar at present, yes? > > Thanks, > > Scott > > Siegfried Goeschl wrote: >> Hi Scott, >> >> you literally saved my day since I run across the same issue - I >> opened a JIRA issue >> >> https://issues.apache.org/jira/browse/EMAIL-77 >> >> Thanks >> >> Siegfried Goeschl >> >> >> >> Scott Eade wrote: >>> And having just tried commons-email-1.1 I would now say that >>> commons-email should be left at 1.0. It appears that HtmlEmail and >>> attachments are totally broken in 1.1 - for my purposes it is unusable. >>> >>> Running commons-email-1.0 with javax.mail-1.4.1 and activation-1.1.1 >>> (these last two being overridden in my pom from 1.4 and 1.1) seems >>> to be working fine. >>> >>> Scott >>> >>> Scott Eade wrote: >>>> Don't you just love having such a multitude of maven repositories! >>>> >>>> Here is some additional information that may influence the path we >>>> take: >>>> >>>> * While javax.actvation:activation:1.1.1 is available from >>>> http://download.java.net/maven/1 (which has been added to >>>> maven.repo.remote in turbine's project.properties), it is not >>>> currently available from http://download.java.net/maven/2 or any >>>> of the other obvious m2 repositories. For maven 2 builds the >>>> best >>>> source would appear to be version 1.1 from the main m2 >>>> repository. For this reason we may want to go with 1.1 rather >>>> than 1.1.1. People that want 1.1.1 will need to install it into >>>> their local repositories manually and override the dependency in >>>> their pom. >>>> * javax.mail.1.4.1 is in the same boat - we may want to go with 1.4 >>>> rather than 1.4.1. >>>> * log4j:log4j:1.2.15 adds a couple of jmx related dependencies that >>>> are not currently available from the obvious m2 repositories >>>> so we >>>> may want to stick with 1.2.14. >>>> >>>> So the updates to the latest activation and mail versions were >>>> prompted by the fact that these could be downloaded automatically. >>>> I'm going to flip-flop on this and suggest we actually use the >>>> following versions on the basis that it makes things easier for >>>> people when using both m1 and m2: >>>> >>>> * javax.activation:activation-1.1 >>>> * javax.mail:mail-1.4 >>>> * log4j:log4j-1.2.14 >>>> >>>> The other dependencies are all fine as far as availability in m2 >>>> repositories is concerned. >>>> >>>> Scott >>>> >>>> Scott Eade wrote: >>>>> Jürgen Hoffmann wrote: >>>>>> [X] +1 Update versions >>>>>> [ ] +0 go ahead I do not care >>>>>> [ ] -0 I don't care >>>>>> [ ] -1 The updated libraries make current 2.3.2 applications useless >>>>>> >>>>> My main concern was that updating to these versions did not impact >>>>> others, but since we don't do a release too often so we should >>>>> take the opportunity to move forward when we have it. In >>>>> particular though: >>>>> >>>>> * commons-email-1.1 would seem to go hand in hand with JavaMail >>>>> 1.4, >>>>> also see http://commons.apache.org/email/release_1_1.html which >>>>> mentions a couple of bug fixes that seem fairly important. >>>>> * commons-fileupload-1.2.1 contains a fix to an issue raised by >>>>> Thomas V. >>>>> (http://commons.apache.org/fileupload/changes-report.html) so I >>>>> imagine he is already running a patched version of this. >>>>> >>>>> Usually a minor digit increase would signify a bug fix, so 1.2.0 >>>>> to 1.2.1 for fileupload would usually be addressing problems and >>>>> hence a good thing. A point release (e.g. commons-io from 1.3.1, >>>>> skipping 1.3.2, to 1.4) might add features but hopefully be >>>>> backwards compatible (in most cases the version numbers we are >>>>> moving to state binary and source compatibility). In summary, I >>>>> prefer to take the opportunity to adopt the current versions when >>>>> we have it, but will certainly balance this with testing. >>>>> >>>>> Looking at version numbers is interesting when we look at what are >>>>> we doing - going from 2.3.2 to 2.3.3 radically understates the >>>>> significance of the changes made. Unfortunately history has us a >>>>> little trapped: >>>>> >>>>> * turbine-3, which no longer exists, is still in use by scarab, >>>>> though it seems that occasional efforts are being made to port >>>>> this over to the trunk. [Is anyone else out there still using >>>>> turbine-3?] >>>>> * the trunk is called turbine-2.4-dev - I think this is where >>>>> we all >>>>> really want to be, and the release being worked on now is really >>>>> setting us up to move this ahead >>>>> * here we are working to release 2.3.3, which without the >>>>> historical >>>>> baggage would clearly be worth calling 2.4 >>>>> >>>>> I think after 2.3.3 is out of the way we should consider our >>>>> version numbering carefully in order to get back on track. My >>>>> suggestion would be that what we currently call 2.4-dev should >>>>> become 4.0-dev. >>>>> >>>>> I am also +1 for going straight to 2.3.3-rc. >>>>> >>>>> My thanks to Thomas, Siegfried and Jurgen (welcome back) for >>>>> making such great strides ahead in the last couple of weeks. >>>>> >>>>> Scott >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
