On Feb 8, 2013, at 9:03 AM, Vincent Massol <[email protected]> wrote:
> > 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 Example: http://ieugen.blogspot.fr/2012/06/java-mbox-parsing-with-apache-james.html Thanks -Vincent > > 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
