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]
