Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [mylar-dev] Re: Bugzilla Repository cannot be added


From: mylar-dev-bounces@xxxxxxxxxxx [mailto:mylar-dev-bounces@xxxxxxxxxxx] On Behalf Of Eugene Kuleshov
Sent: Thursday, March 09, 2006 1:49 PM
To: Mylar developer discussions
Subject: Re: [mylar-dev] Re: Bugzilla Repository cannot be added

 

Mik Kersten wrote:

I wonder whether to really work it would need to be tied in to an integrated
tool that allows reading/authoring of those messages?  

  Viewing would be really easy to implement (both text and html emails)
  Editing little more tricky (at least for html that can't be converted to text). I hoped to look for existing SWT/JFace email clients (if any), or perhaps there was something done on Hipikat project...

 

Seems like there could be a simple HTML viewer that just used the Browser widget, and then add-on viewers could do more (since they’re likely to require other libraries).  There isn’t anything suitable from Hipikat.

Without that if my personal preference as a user might be to have a repository task that has a
URL link to the corresponding email message, since they're easy to link on eclipse.org (and maybe some UI sugar for creating reports from news/mail messages).

  Well, this thingy I built could be that "report". Then we can create a task from it using copy-paste (don't work now) and then manually add web url, or resolve it semi automatically if web interface exists for given email/nntp repository.

Yup.

 

Which reminds, me, if a bug report does have a URL property set
we could add a separate browser tab for viewing it that message.  But
obviously that wouldn't give the benefit of grouping by thread within the
list, etc.
  

  Those are the advanced features that would require tasks locally preserved and have some facility to iterate/search trough them.

Regarding incorporating this into Mylar, what is the exact list of
dependencies and licenses?  Each would require an EMO review, and as far as
I know impossible for us to add GPL dependencies or any other non-EPL
compatible ones.
  

  To support imap and pop3 (including ssl support) we need at minimum JavaMail and Activation framework (licenses are on the download page).
  http://java.sun.com/products/javamail/  (ver. 1.3.3 or 1.4ea)
  http://java.sun.com/products/javabeans/jaf/index.jsp  (ver. 1.0.2 or 1.1ea)

  Can you check if those would be an issue?

JAF looks fine.  JavaMail is under the Java Research License (http://java.net/jrl.csp) which looks like it’s incompatible with the EPL, but I will find out next week.  Regarding doing the update site-based external dependency thing as we do with Tigris.org for Jira Core Services, there we are not depending on any incompatible license (only EPL and Apache), and that’s important because what’s in our source code repository ends up having a dependency on the external project.  So I’m not clear if we could depend on GNU stuff this way.  At EclipseCon next week I will figure out the precise rules for this.

 

Is it possible to do RSS with compatible licenses only?


  To support nnt protocol I've used whitebox JavaMail implementation from GNU classpathx:

  lib/inetlib-1.0.jar,\
  lib/activation-1.0.2.jar,\
  lib/mail-1.3.2.jar,\
  lib/providers-1.0.jar

  There is a chance that minimalistic nntp provider for JavaMail can be implemented on top of Jakarta Commons Net library, so it would be compliant. If not, we can host an optional Eclipse plugin with GNU JavaMail providers externally (sf or codehaus).


 


Back to the top