[prev in list] [next in list] [prev in thread] [next in thread]
List: turbine-dev
Subject: Re: commons-email [was: Re: VOTE to apply Scotts' Patch for updated
From: Siegfried Goeschl <siegfried.goeschl () it20one ! at>
Date: 2009-06-15 20:11:12
Message-ID: 4A36AAE0.3030004 () it20one ! at
[Download RAW message or body]
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: dev-unsubscribe@turbine.apache.org
>>>>> For additional commands, e-mail: dev-help@turbine.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
>>>> For additional commands, e-mail: dev-help@turbine.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
>>> For additional commands, e-mail: dev-help@turbine.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
>> For additional commands, e-mail: dev-help@turbine.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
> For additional commands, e-mail: dev-help@turbine.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic