[
https://issues.apache.org/jira/browse/SOLR-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14050875#comment-14050875
]
Hoss Man commented on SOLR-2245:
--------------------------------
FWIW:
* everything _but_ the source headers seems to agree that greenmail is ASL
licensed...
** SF.net license label added by project maintainer:
http://sourceforge.net/projects/greenmail/ ->
http://sourceforge.net/directory/license:apache2/
** project website: http://www.icegreen.com/greenmail/ ->
http://www.apache.org/licenses/LICENSE-2.0.txt
** maven pom.xml:
http://sourceforge.net/p/greenmail/code/HEAD/tree/trunk/pom.xml#l18
** license.txt shpped with project:
http://sourceforge.net/p/greenmail/code/HEAD/tree/trunk/license.txt
* from what i can tell, even files copied verbatim from Apache James, w/o any
modifications, have the exact same LGPL copyright header - which smells like a
straight up IDE generated header mistake to me.
* there is a feedback page on the icegreen.com domain that links to contact
details on another site -- i suppose you could try reaching out to the dev that
way: http://www.icegreen.com/greenmail/feedback.html ->
http://waelchatila.com/pages/consulting.html
* greenmail appears to be the epitome of a completely dead project -- any
resolution of this issue that involves on waiting for developer response /
action is probably a bad idea...
** Latest code commit: 2010-06-03
http://sourceforge.net/p/greenmail/code/HEAD/tree/
** issue tracker contains 8 bug reports going back to 2009-03-15, none of which
have ever recieved a comment from any project developer:
http://sourceforge.net/p/greenmail/bugs/
** most recent mailing list postings from project dev:
*** latest reply to user list from a dev: Jan 2010 -
http://sourceforge.net/p/greenmail/mailman/message/24321407/
*** latest release announcement list message: Dec 2007 -
http://sourceforge.net/p/greenmail/mailman/greenmail-announcement/
** project website has a "blog" link that redirects to another domain (same as
contact details) where most recent "greenmail" blog is 1.3 release announcement
from 2007: http://www.icegreen.com/articles -> http://waelchatila.com/ ->
http://waelchatila.com/tags/greenmail/
> MailEntityProcessor Update
> --------------------------
>
> Key: SOLR-2245
> URL: https://issues.apache.org/jira/browse/SOLR-2245
> Project: Solr
> Issue Type: Improvement
> Components: contrib - DataImportHandler
> Affects Versions: 1.4, 1.4.1
> Reporter: Peter Sturge
> Assignee: Timothy Potter
> Priority: Minor
> Fix For: 4.9, 5.0
>
> Attachments: SOLR-2245.patch, SOLR-2245.patch, SOLR-2245.patch,
> SOLR-2245.patch, SOLR-2245.patch, SOLR-2245.zip
>
>
> This patch addresses a number of issues in the MailEntityProcessor
> contrib-extras module.
> The changes are outlined here:
> * Added an 'includeContent' entity attribute to allow specifying content to
> be included independently of processing attachments
> e.g. <entity includeContent="true" processAttachments="false" . . . />
> would include message content, but not attachment content
> * Added a synonym called 'processAttachments', which is synonymous to the
> mis-spelled (and singular) 'processAttachement' property. This property
> functions the same as processAttachement. Default= 'true' - if either is
> false, then attachments are not processed. Note that only one of these should
> really be specified in a given <entity> tag.
> * Added a FLAGS.NONE value, so that if an email has no flags (i.e. it is
> unread, not deleted etc.), there is still a property value stored in the
> 'flags' field (the value is the string "none")
> Note: there is a potential backward compat issue with FLAGS.NONE for clients
> that expect the absence of the 'flags' field to mean 'Not read'. I'm
> calculating this would be extremely rare, and is inadviasable in any case as
> user flags can be arbitrarily set, so fixing it up now will ensure future
> client access will be consistent.
> * The folder name of an email is now included as a field called 'folder'
> (e.g. folder=INBOX.Sent). This is quite handy in search/post-indexing
> processing
> * The addPartToDocument() method that processes attachments is significantly
> re-written, as there looked to be no real way the existing code would ever
> actually process attachment content and add it to the row data
> Tested on the 3.x trunk with a number of popular imap servers.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
