commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Siegfried Goeschl <sgoes...@gmx.at>
Subject Fwd: Re: [VOTE] Release of commons-email-1.3 based on RC5
Date Wed, 12 Dec 2012 20:50:01 GMT



-------- Original Message --------
Subject: Re: [VOTE] Release of commons-email-1.3 based on RC5
Date: Wed, 12 Dec 2012 21:49:39 +0100
From: Siegfried Goeschl <sgoeschl@gmx.at>
Reply-To: sgoeschl@gmx.at
To: Gary Gregory <garydgregory@gmail.com>

Hi Gary,

just checked the Apache site and you are right - no way to remove a
deprecated method using the same major release version

Siegfried Goeschl

On 12.12.12 21:44, Gary Gregory wrote:
> On Wed, Dec 12, 2012 at 3:40 PM, Siegfried Goeschl <sgoeschl@gmx.at
> <mailto:sgoeschl@gmx.at>> wrote:
>
>     Hi Thomas,
>
>     there is some code out there using it to build emails based on maps
>
>     https://turbine.apache.org/__fulcrum/fulcrum-commonsemail/__xref/index.html
>     <https://turbine.apache.org/fulcrum/fulcrum-commonsemail/xref/index.html>
>
>     AFAIK we are free to drop deprecated stuff when doing a minor
>     release - which of course breaks binary compatibility.
>
>
> I do not think so, not for a minor release. Breaking BC is for major
> releases, which also involves a package name and artifact name change,
> if we follow what we've done for [lang] and [vfs].
>
> Gary
>
>
>     Cheers,
>
>     Siegfried Goeschl
>
>
>     On 12.12.12 21:31, Thomas Neidhart wrote:
>
>         On 12/12/2012 08:39 PM, Siegfried Goeschl wrote:
>
>             Hi folks,
>
>             to avoid the full circles here
>
>             * I hopefully fixed the binary compatibility issue, wrote
>             test and also
>             tested it with my production code
>
>             * I moved the constants to EmailConstants because there are many
>             constants and using an non-trivial implementation class
>             (Email) to
>             access a few constants is also questionable in my opinion
>
>             * The design of commons-email is flawed in a few ways and
>             there is not a
>             lot you can fix in a major version. So I suggest that we
>             focus on
>             delivered value instead
>
>
>         Hi Siegfried,
>
>         thanks for your feedback.
>
>         Taking this into account, together with the posts from sebb and
>         Gary,
>         imho the best solutions is as sebb proposed:
>
>         * Change EmailConstants to a public final class
>         * Add back the constants to the Email class by referencing them from
>             EmailConstants
>         * Mark the constants in Email as deprecated
>
>         btw. there are several constants that have not been in use since
>         the 1.0
>         release:
>
>               String SENDER_EMAIL = "sender.email";
>               String SENDER_NAME = "sender.name <http://sender.name>";
>               String RECEIVER_EMAIL = "receiver.email";
>               String RECEIVER_NAME = "receiver.name <http://receiver.name>";
>               String EMAIL_SUBJECT = "email.subject";
>               String EMAIL_BODY = "email.body";
>               String CONTENT_TYPE = "content.type";
>               String ATTACHMENTS = "attachments";
>               String FILE_SERVER = "file.server";
>
>         Does anybody know how or if they are in use? They are now marked as
>         deprecated, but I am really curious about there origin.
>
>         Does everybody agree on wha?
>
>         Thomas
>
>
>             Cheers,
>
>             Siegfried Goeschl
>
>
>             On 12.12.12 15:06, sebb wrote:
>
>                 On 12 December 2012 13:17, Gary Gregory
>                 <garydgregory@gmail.com <mailto:garydgregory@gmail.com>>
>                 wrote:
>
>                     On Wed, Dec 12, 2012 at 3:59 AM, Thomas Neidhart
>                     <thomas.neidhart@gmail.com
>                     <mailto:thomas.neidhart@gmail.com>>__wrote:
>
>                         On Wed, Dec 12, 2012 at 4:58 AM, Gary Gregory
>                         <garydgregory@gmail.com
>                         <mailto:garydgregory@gmail.com>
>
>                             wrote:
>
>
>                             Thank you for doing another RC.
>
>                             While I was digging for a justification of
>                             the Clirr errors, I
>                             found this
>                             in the release notes: "Clirr reports several
>                             errors for this
>                             release due
>
>                         to
>
>                             moving constants from the Email class to the
>                             newly introduced
>                             EmailConstants interface. These changes are
>                             guaranteed to be binary
>                             compatible."
>
>                             Is it really binary compatible? What if I
>                             use reflection to access the
>                             constant on Email, will the reflection call
>                             be redirected to
>                             EmailConstants? There's unit test for ya ;)
>
>                             Using an interface to define constants is a
>                             no-no in my book. I've
>                             seen
>                             this discussed before in other places and
>                             for a long time, but to
>                             summarize, I see an interface as defining a
>                             contract for a class to
>                             implement. A constant does not fit.
>
>                             Constants in interface feels like a hack to
>                             provide the short hand
>                             of a
>                             class implementing an interface just to be
>                             able to access the
>                             constants
>                             without qualifying them with a type. Not
>                             nice design IMO and a
>                             dubious us
>                             of an interface, very Java 1.0. It seems
>                             that static imports is
>                             another
>                             attempt to solve this desire for a short
>                             hand to use constants.
>
>                             What to do? Move the constants back to their
>                             1.2? What's so bad about
>
>                         that?
>
>                             Hm...
>
>                             Make the EmailConstants a class instead of
>                             an interface? If binary
>                             compatible is broken, the constants have to
>                             move back, and you can
>                             still
>                             have a new EmailConstants class and
>                             deprecate the old constants to
>                             point
>
>                         to
>
>                             the new class.
>
>                             Maybe I'll see this more clearly in the AM...
>
>                             Interested in you all's feedback.
>
>
>                         Hi Gary,
>
>                         well, I think we go in circles with this change ;-).
>
>                         I assumed that this topic is settled after
>                         reading the comment from
>                         sebb in
>                         the RC2 thread (see
>                         http://markmail.org/message/__svrb7nf3ocz7lgmd
>                         <http://markmail.org/message/svrb7nf3ocz7lgmd>).
>
>                         Otoh, it's the first time I see constants in an
>                         interface and would
>                         be in
>                         favor of reverting to the previous version (also
>                         because I do not fully
>                         understand the rationale behind the change, some
>                         of the constants
>                         are not
>                         even used and thus have been deprecated).
>
>                     --
>
>
>                         Maybe we should postpone this kind of
>                         refactoring to 2.0 and do it
>                         then in
>                         a proper way. Introducing this interface just
>                         created headaches and
>                         I also
>                         had to disable some checks (e.g.
>                         InterfaceIsAType in checkstyle)
>                         because of
>                         it.
>
>
>                     That sounds like a good way to go to get 1.3 out the
>                     door.
>
>
>                 Agreed.
>
>                     Gary
>
>
>
>                         Thomas
>
>
>                             On Tue, Dec 11, 2012 at 5:24 PM, Thomas Neidhart
>                             <thomas.neidhart@gmail.com
>                             <mailto:thomas.neidhart@gmail.com>>__wrote:
>
>                                 Hi,
>
>                                 I would like to call a vote from
>                                 commons-email-1.3 based on RC5.
>
>                                 This release candidate has the following
>                                 changes compared to RC4
>
>                                 +) update index and building page with
>                                 correct information wrt Java
>                                       compatibility
>                                 +) update release notes with info on
>                                 Java compatibility and Clirr
>
>                         errors
>
>                                 +) fix svn:keywords for all source files
>                                 and remove use of $Date$
>                                 tags
>                                 +) add $Id$ tags for all newly
>                                 introduced source files in 1.3
>                                 +) update javax.mail.mail dependency to
>                                 1.4.5
>                                 +) fix PMD warnings and add NOPMD
>                                 comment for false positives
>                                 +) added findbugs exclude filter for
>                                 false positives
>                                 +) fix release date in changes.xml
>                                 +) correctly removed *.asc.[md5,sha1]
>                                 files from Nexus staging area
>
>                                 The files:
>
>                                 The artifacts are deployed to Nexus:
>
>                         https://repository.apache.org/__content/repositories/__orgapachecommons-137/
>                         <https://repository.apache.org/content/repositories/orgapachecommons-137/>
>
>
>                                 The tag:
>
>
>                         https://svn.apache.org/repos/__asf/commons/proper/email/tags/__EMAIL_1_3_RC5/
>                         <https://svn.apache.org/repos/asf/commons/proper/email/tags/EMAIL_1_3_RC5/>
>
>
>                                 The site:
>                                 http://people.apache.org/__builds/commons/email/1.3/RC5/
>                                 <http://people.apache.org/builds/commons/email/1.3/RC5/>
>
>                                 Additional Notes:
>
>                                 o the download page and api links to
>                                 older releases only work on
>                                      the published site and will be
>                                 corrected after release.
>
>                                 Please take a look at the
>                                 commons-email-1.3 artifacts and vote!
>
>                                 ------------------------------__------------------
>                                 [ ] +1 release it
>                                 [ ] +0 go ahead I don't care
>                                 [ ] -1 no, do not release it because
>                                 ------------------------------__------------------
>
>                                 Vote will remain open for at least 72 hours.
>
>                                 Thanks in advance,
>
>                                 Thomas
>
>                                 ------------------------------__------------------------------__---------
>                                 To unsubscribe, e-mail:
>                                 dev-unsubscribe@commons.__apache.org
>                                 <mailto:dev-unsubscribe@commons.apache.org>
>                                 For additional commands, e-mail:
>                                 dev-help@commons.apache.org
>                                 <mailto:dev-help@commons.apache.org>
>
>
>
>
>                             --
>                             E-Mail: garydgregory@gmail.com
>                             <mailto:garydgregory@gmail.com> |
>                             ggregory@apache.org <mailto:ggregory@apache.org>
>                             JUnit in Action, 2nd Ed:
>                             <http://goog_1249600977>http:/__/bit.ly/ECvg0 <http://bit.ly/ECvg0>
>                             Spring Batch in Action:
>                             <http://s.apache.org/HOq>http:__//bit.ly/bqpbCK
>                             <http://bit.ly/bqpbCK>
>                             Blog: http://garygregory.wordpress.__com
>                             <http://garygregory.wordpress.com>
>                             Home: http://garygregory.com/
>                             Tweet! http://twitter.com/GaryGregory
>
>
>
>
>
>                     --
>                     E-Mail: garydgregory@gmail.com
>                     <mailto:garydgregory@gmail.com> |
>                     ggregory@apache.org <mailto:ggregory@apache.org>
>                     JUnit in Action, 2nd Ed:
>                     <http://goog_1249600977>http:/__/bit.ly/ECvg0
>                     <http://bit.ly/ECvg0>
>                     Spring Batch in Action:
>                     <http://s.apache.org/HOq>http:__//bit.ly/bqpbCK
>                     <http://bit.ly/bqpbCK>
>                     Blog: http://garygregory.wordpress.__com
>                     <http://garygregory.wordpress.com>
>                     Home: http://garygregory.com/
>                     Tweet! http://twitter.com/GaryGregory
>
>
>                 ------------------------------__------------------------------__---------
>                 To unsubscribe, e-mail:
>                 dev-unsubscribe@commons.__apache.org
>                 <mailto:dev-unsubscribe@commons.apache.org>
>                 For additional commands, e-mail:
>                 dev-help@commons.apache.org
>                 <mailto:dev-help@commons.apache.org>
>
>
>
>
>             ------------------------------__------------------------------__---------
>             To unsubscribe, e-mail: dev-unsubscribe@commons.__apache.org
>             <mailto:dev-unsubscribe@commons.apache.org>
>             For additional commands, e-mail: dev-help@commons.apache.org
>             <mailto:dev-help@commons.apache.org>
>
>
>
>         ------------------------------__------------------------------__---------
>         To unsubscribe, e-mail: dev-unsubscribe@commons.__apache.org
>         <mailto:dev-unsubscribe@commons.apache.org>
>         For additional commands, e-mail: dev-help@commons.apache.org
>         <mailto:dev-help@commons.apache.org>
>
>
>
>
>     ------------------------------__------------------------------__---------
>     To unsubscribe, e-mail: dev-unsubscribe@commons.__apache.org
>     <mailto:dev-unsubscribe@commons.apache.org>
>     For additional commands, e-mail: dev-help@commons.apache.org
>     <mailto:dev-help@commons.apache.org>
>
>
>
>
> --
> E-Mail: garydgregory@gmail.com <mailto:garydgregory@gmail.com> |
> ggregory@apache.org <mailto:ggregory@apache.org>
> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/>
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message