On Feb 8, 2013, at 8:55 AM, Vincent Massol <[email protected]> wrote:
> > On Feb 7, 2013, at 8:17 PM, Jeremie BOUSQUET <[email protected]> > wrote: > >> Hi Vincent, >> >> Thanks for feedbacks ! >> >> Le 7 févr. 2013 18:53, "Vincent Massol" <[email protected]> a écrit : >>> >>> Hi Jeremie, >>> >>> I'm trying to use version 0.2. Some comments: >>> >>> * When I go to http://localhost:8080/xwiki/bin/view/MailArchive/Admin, >> Server's tab and click Add I get a blank page >> Weird, I tested that from a fresh 4.4.1 install... I'll check again. >> Anything noticeable from firebug / ajax request ? >> Anyway, workaround would be to create a page under "MailArchivePrefs" >> space, and add an object of type "MailArchiveCode.ServerSettingsClass" to >> define a server. >>> * On http://localhost:8080/xwiki/bin/view/MailArchive/Statistics it says >> there are 2 posts but obviously I don't have any ;) >> Grrrr... :-) >>> >>> If we wanted to use the mailarchive app on xwiki.org to get all mails >> from our mailing lists, how would we set it up? It seems it needs an email >> account and will get emails using imap, correct? So how do we load all >> mailarchive emails into an email account? :) >> >> Imap or any protocol supported by javamail... >> But you're right, the app acts as a "mail sniffer", and stores mails sent >> to configured account(s) into wiki pages. >> What is planned of course is an "import" feature, but it needs work. >> Currently I plan to allow importing mails from a .pst file if possible. >> Question is: if you would ask for an extract of all mails from the servers >> managing your xwiki mailing-lists, what would be the format ? >> If you have that information, I would focus the import feature to parse >> that format of course. > > There are different options but the simplest IMO is to parse/import mailman's > mbox archive files. Just noticed that Tika Parsers (which we use) should be able to parse MBox files already :) Or http://james.apache.org/mime4j/ which seems to be used by Tika Parsers. - http://svn.apache.org/repos/asf/tika/trunk/tika-parsers/src/main/java/org/apache/tika/parser/mbox/MboxParser.java - http://svn.apache.org/repos/asf/james/mime4j/trunk/examples/src/main/java/org/apache/james/mime4j/samples/mbox/IterateOverMbox.java - http://svn.apache.org/repos/asf/labs/mboxer/mbox-reader/src/test/java/org/apache/labs/mboxer/MBoxTest.java Thanks -Vincent > Here's the format: > * http://en.wikipedia.org/wiki/Mbox > * http://tools.ietf.org/html/rfc4155 > > Thanks > -Vincent > >> If there are other possibilities I'm missing, I'm open to any comment :-) >> >> Br, >> Jeremie >>> >>> Thanks >>> -Vincent >>> >>> On Feb 3, 2013, at 6:30 PM, Jeremie BOUSQUET <[email protected]> >> wrote: >>> >>>> I just tested installation from EM from xwiki.org repository, and it >> seems >>>> to install correctly :) >>>> I'll try my best not to wait so long for next version ... That one is >> far >>>> from perfect but should be far more usable than 0.1 thanksfully. >>>> >>>> >>>> 2013/2/3 Jeremie BOUSQUET <[email protected]> >>>> >>>>> Thanks Vincent ! >>>>> >>>>> Maybe I'm wrong, but I didn't want to use the original groupId of this >>>>> mstor artifact, because its dependencies are slightly modified >> compared to >>>>> the original. I think it would introduce the false impression of >> relying on >>>>> the original artifact, while it's not really the case. >>>>> If someone depends on it, thinking it's the original, in a standalone >>>>> environment, it might not work as expected. While "my" version with >>>>> different transitive dependencies, is the only one that works without >>>>> conflicting with XE. >>>>> For these complex cases, might be nice that EM manages maven >> exclusions, >>>>> though maybe it's a big work for not so frequent use-case. >>>>> >>>>> Nexus config can be somewhat tricky ;-) I know it a little but not pro >>>>> features as staging and promotion. >>>>> >>>>> Thanks again, >>>>> Jeremie >>>>> >>>>> >>>>> 2013/2/3 Vincent Massol <[email protected]> >>>>> >>>>>> >>>>>> On Feb 3, 2013, at 5:05 PM, Jeremie BOUSQUET < >> [email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi Vincent, >>>>>>> >>>>>>> >>>>>>> 2013/2/3 Vincent Massol <[email protected]> >>>>>>> >>>>>>>> Hi Jeremie, >>>>>>>> >>>>>>>> On Feb 3, 2013, at 4:15 PM, Jeremie BOUSQUET < >>>>>> [email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hello devs, >>>>>>>>> >>>>>>>>> Please could you promote release 0.2 of mail archive app in your >> nexus >>>>>>>>> repository ? >>>>>>>> >>>>>>>> Cool :) >>>>>>>> >>>>>>>> Seen that you had some issues to release it? Anything we can help >> with? >>>>>>>> >>>>>>>> >>>>>>> Nothing, except by me some better brains, so I don't forget my GPG >>>>>>> passphrase next time ;-) >>>>>> >>>>>> :) >>>>>> >>>>>>>>> groupId: >>>>>>>>> org.xwiki.contrib.mailarchive >>>>>>>>> artifactIds: >>>>>>>>> xwiki-contrib-mail >>>>>>>>> xwiki-contrib-mailarchive-api >>>>>>>>> xwiki-contrib-mailarchive-ui >>>>>>>>> mstor >>>>>>>> >>>>>>>> I was about to do it when I noticed mstor. What is this? If this is >> a >>>>>> 3rd >>>>>>>> party lib why publish it with the org.xwiki.contrib.mailarchive >> groupid >>>>>>>> instead of using its own groupid as we do for other 3rd paty libs? >>>>>>>> >>>>>>>> >>>>>>> See discussion >>>>>>> >>>>>> >> http://xwiki.markmail.org/search/?q=mstor#query:mstor+page:1+mid:owjykurnlztrxrac+state:results >>>>>>> Basically, I need mstor library to create a Javamail store (to >>>>>>> backup/reload emails), but this library comes with extra transitive >>>>>>> dependencies, that conflict with XE. >>>>>>> I solved that by publishing that lib along my project, without the >>>>>>> conflicting (and useless) transitive deps. >>>>>> >>>>>> I've read the discussion again and still didn't understand why you >> needed >>>>>> to publish that artifact under your own groupid vs publishing it with >> a >>>>>> proper groupid. >>>>>> >>>>>> Anyway I've promoted and released your artifacts. The nexus config >> looks >>>>>> very complex now and I don't master it (I had to close, promote and >> release >>>>>> which sounds like a lot of steps!)… We also need to give you direct >>>>>> permissions to do that IMO but I don't know the config well enough to >> do >>>>>> that now. Maybe Sergiu knows since I think he configured that? >>>>>> >>>>>> Thanks >>>>>> -Vincent >>>>>> >>>>>>>> Thanks >>>>>>>> -Vincent >>>>>>>> >>>>>>>>> Thanks ! >>>>>>>>> >>>>>>>>> BR, >>>>>>>>> Jeremie >>>>>>>>> >>>>>>>>> >>>>>>>>> 2012/12/13 Jeremie BOUSQUET <[email protected]> >>>>>>>>> >>>>>>>>>> Ok I removed them. >>>>>>>>>> Thought about something, is that main problem is if someone wants >> to >>>>>>>>>> install it manually, ie without the Extension Manager, he would >> have >>>>>> to >>>>>>>>>> retrieve the transitive dependencies "by hand". >>>>>>>>>> But as my target is XE 4.X, I'm wondering if it's useful anyway to >>>>>> allow >>>>>>>>>> users installing such extension manually, as it's faaar more easy >>>>>> using >>>>>>>> EM. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2012/12/7 Thomas Mortagne <[email protected]> >>>>>>>>>> >>>>>>>>>>> On Fri, Dec 7, 2012 at 2:52 PM, Jeremie BOUSQUET < >>>>>>>>>>> [email protected] >>>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2012/9/14 Vincent Massol <[email protected]> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Sep 14, 2012, at 9:13 AM, Jeremie BOUSQUET < >>>>>>>>>>>> [email protected]> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> I guess I have to create an extension page for each artifact ? >>>>>> (mail >>>>>>>>>>>>>> extension, mailarchive api extension, mail archive ui >> extension) >>>>>>>>>>>>>> Didn't had time to test within extension repository manager >>>>>> locally, >>>>>>>>>>>>>> so I hope it'll work ! :) >>>>>>>>>>>>> >>>>>>>>>>>>> No don't create one per artifact. To start with I'd suggest >> just >>>>>> one >>>>>>>>>>> for >>>>>>>>>>>>> the UI module. The other artifacts are already in an extension >>>>>>>>>>> repository >>>>>>>>>>>>> since they're in maven.xwiki.org ;) >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> -Vincent >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Back to this, since I didn't see that recommendation, at that >> time >>>>>> I >>>>>>>>>>>> created 3 extension pages for the 3 modules (and not only for >> UI): >>>>>>>>>>>> (UI) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>> >> http://extensions.xwiki.org/xwiki/bin/view/Extension/MailArchive+Application >>>>>>>>>>>> (mail api) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>> >> http://extensions.xwiki.org/xwiki/bin/view/Extension/MailArchive+Mail+Module >>>>>>>>>>>> (mail archive api) >>>>>>>>>>>> >>>>>>>> >>>>>> >> http://extensions.xwiki.org/xwiki/bin/view/Extension/MailArchive+Module >>>>>>>>>>>> >>>>>>>>>>>> As the last 2 do not really need to be materialized in >>>>>>>>>>>> extensions.xwiki.org, >>>>>>>>>>>> and lead to more maintenance from my side, and more confusion on >>>>>> users >>>>>>>>>>>> side, I would like to remove these 2 pages from >>>>>> extensions.xwiki.org, >>>>>>>>>>> and >>>>>>>>>>>> move some of their content to the Design page related to the >>>>>>>> MailArchive >>>>>>>>>>>> Application. >>>>>>>>>>>> >>>>>>>>>>>> Since those 2 were already published, from users point of view >> it >>>>>>>> means >>>>>>>>>>> 2 >>>>>>>>>>>> extensions will "disappear" from the catalog. >>>>>>>>>>>> So I wanted to check with you if it's not a bad practice to do >>>>>> that, >>>>>>>>>>> and if >>>>>>>>>>>> I can safely remove those 2 extensions (according to the fact, >>>>>> also, >>>>>>>>>>> that >>>>>>>>>>>> the whole thing is tagged as "BETA"). >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> There is no official practice on this yet. IMO you can do this is >>>>>> you >>>>>>>>>>> think >>>>>>>>>>> it's the cleaner like this. >>>>>>>>>>> >>>>>>>>>>> It's not going to break anything for users unless there is other >>>>>>>>>>> extensions >>>>>>>>>>> depending of these extensions in which case they won't be able to >>>>>>>> install >>>>>>>>>>> them of course. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Jeremie _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
