"We compile things" is _not_ valid reason. I simply have no idea what it's good for. > I'm not going to get dragged into that debate but the fact is this is Gentoo, The filename didn't change though, which is why I didn't spot this mistake. I was originally packaging that JAR with wstx, which has a different PV and that PV forms part of the URI. > Or not, stax2-api-src-3.1.1 can not be fetched. The previous attempt looked like guesswork at best.
I am also an experienced Java packager and have tested that it works. > building from source, it is the many bundled packages that I dislike.īuilding it from source will mean that any missing classes or other incompatibilities will get reported at compile time. > However, I am currently testing you ebuild. I'm not going to get dragged into that debate but the fact is this is Gentoo, we compile things.
#Davmail gateway java code
> point of java that the sources build thze same byte code vereywhere that runs > And what use it is to create the same jars? I am no java expert, but wasn't the However, this is just a shot in the dark as I am completely at sea here. In the working version, the log continues with the identification of the server being the right one (known hash) and a long log where it downloads the specific calendar. In the log file the program seems to check the server, and then stops after getting this reply: The XML snippets in my logs looked weird, and as there's everything XML, the message "Empty response" could point towards bad parsing? No, certainly not the culprit as the logging looked fine.īut this might be the cause. I did not expect davmail to use smb for the connection, everything is done via http (As I do not need the EWS method) so this should be perfectly save unless this is used for the server identification and validation.
#Davmail gateway java how to
But as I am no java expert, I have no idea how to find out which. One of the deps seems like having the wrong version. And now everything is working normally again. I removed the following packages, and re-installed from the attached ebuild (which is simply a renamed version of the previous "bundled" one). Next my LDap Adress book stopped to work.įinally the exchange Mail stopped working stating wrong Username and/or Password. ((*) But I'll give it a try below)įirst, whenever I wanted to check one of my calendars, I got the message from kontact, that the server reply was empty. I can not say which dep it is (*), but after upgrading using the new "unbundled" ebuild, nothing worked any more. Sorry, but there is something completely broken with one of the dependencies. I am afraid I would be the wrong person as I do not have the time to do it. > If anybody is interested in placing similiar article in English section of wiki > Currently I'm writing the article in ru. As this is a laptop I am using, I do not need davmail anywhere but in the office, so I do not start it when I am off work. > app DE launcher, later it's invoked by DEs autostart subsystem). > manually is started manually: it could be done from terminal emulator or run > It just overloads "Application" menu with practically useless item (davmail > I disagree with the necessety of creation of the davmail invocation menu item: So I am not the original author.īut as I have opened this bug, I would surely like to improve the quality of the ebuild. I have taken the ebuild from the quoted forums thread and didn't do anything to it. Hello Sergey, thanks alot for your feedback! > How (and with whom) I can speak about optimization of ebuild? Net-mail/davmail-3.9.7 - Binary (packaged/bundled) version Net-mail/davmail-3.9.6 - Binary (packaged/bundled) version Net-mail/davmail-3.9.4 - Binary (packaged/bundled) version (davmail-3.9.0_p1630-r1.ebuild,892 bytes,ĭesktop file for davmail (davmail moved from Office to Network) Version bump to 3.9.0 relying on system packages if possibleīundled version, fixing the not-working-dependency reported below Davmail-3.8.8_p1608.ebuild new Version, released yesterdayĭavMail Icon File (with correct Mime-Type)
0 kommentar(er)
