Hey Rapael, I know about this as Tellier told me this once the first time I reported issues when first tried to build beta5. So this is what I as a hobbiest don't understand: if the commit that is made public at least passed all tests once - why it's failing so differently on my different build setups? Java shouldn't behave like this. And as I quickly looked into the source-files causing the issues and couldn't spot any lines that maybe responsible for this I couldn't figure out what went wrong (at least I'm able to read and understand a StackTrace). I expected issues related to Docker as I don't have it installed, but not the one I encountered.
Maybe some wants to know: the tests fail pretty hard on Windows for the maildir target as it seems the tests try to cteate files or folders wich aren't allowed on NTFS/Windows according to IOException: syntax error for filename. Wouldn't any problem when using database as storage - but could lead to unexpected failures during runtime. Matt ---- Raphael OUAZANA schrieb ---- >Hey Matt, > >Thank you for your interest in this project. > >You seem to have some issues building James. That's something that can >happen because with have some flaky tests, and not enough time to solve >them all. >But you should now that each time we are making a commit, all the tests >do pass at least one time (and generally multiple times in practice), so >we are pretty confident with the quality on the commits we merge. > >If you have so much issues building James, please consider to build it >without tests. It will take less than 2 minutes and you will quickly >have the binaries you are looking for. > >To do this, just add -DskipTests=true to your current maven options. > >Regards, >Raphaël Ouazana. > >Le 2017-06-08 01:07, cryptearth a écrit : >> Hey there, >> >> sorry for me to taking so long to reply - but it happend again: as I >> was preparing to set up some VMs for testing - I failed again the >> cursed game of luck to download the working commit and got the RC2 you >> just pushed out. As I didn't knew it the time I just lazyly started >> another try on my root server it surprisingly went very well. At least >> until the test wich starts up RMI - wich failed cause the ports were >> already in use by the running beta6 instance. So I shut down the >> running instance - re-tried it - and it got a success. As there is no >> docker installed on my root I got few docker related issues, but it >> seems these failed tests didn't mattered. After re-running it with >> -Pwith-assembly I also got the zip/tar.gz - wich I'm currently running >> now and over wich this mail is sent. >> >> As I tried to set up a VM to match my servers setup - but it still >> fail at apache-james-mailbox-hbase >> I re-run maven with -X and -e, but still didn't get more than this: >> >> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.217 >> sec <<< FAILURE! - in >> org.apache.james.mailbox.hbase.mail.HBaseMailboxMessageMapperTest >> testMessageMapperScenario(org.apache.james.mailbox.hbase.mail.HBaseMailboxMessageMapperTest) >> Time elapsed: 0.003 sec <<< ERROR! >> java.lang.ExceptionInInitializerError >> at >> org.apache.james.mailbox.hbase.mail.HBaseMailboxMessageMapperTest.<clinit>(HBaseMailboxMessageMapperTest.java:69) >> >> It looks like there is the rest of the stacktrace missing - but I >> can't find it anywhere. >> Line 69 is this one here: >> >> public static final HBaseClusterSingleton CLUSTER = >> HBaseClusterSingleton.build(); >> >> Maybe this helps - even if I still can't understand WHY this happens, >> as it went fine on the same setup on my root. Can't tell any >> difference: same maven, same jdk, same OS and patch-level. Nothing >> wich could cause this fail according to the source as there is nothing >> system-level called, at least nothing I can spot on first look. >> >> >> If anyone want a compiled RC2 buld (as long as the licence permits me >> to offer this) can ask me for a link to download it from my server. Be >> aware: it's 1.1GB in size. >> >> >> Any way - so long - Matt >> >> Am 05.06.2017 um 11:57 schrieb Benoit Tellier: >>> Hi, >>> >>> First thanks for the feedback, it is rather interesting. >>> >>>> So, to start this of with a meme: One does not simply - compile >>>> Apache >>> James from source. >>> >>> :-) >>> >>>> Call me stupid >>> I would never. We all have different backgrounds, thus we don't >>> consider >>> the same things easy. >>> >>> About the 3 fails that you encountered: >>> >>> - apache-james-mailbox-hbase : I already saw our Continuous >>> Integration >>> system fail there. As we don't use this part of the project, we >>> schedule >>> a new build. As it is a very rare event, it doesn't matter much. The >>> question would then be: do you always observe it? >>> - Concerning windows: >>> >>> As far as I am aware of it, all of the recent active James >>> contributors >>> are using Linux. I personally use ArchLinux, some others prefer Debian >>> and Ubuntu. We don't have a license for Windows, thus we can not >>> guaranty we do not introduce bugs regarding it. >>> >>> As it is a free project, anyone can propose patches, and for instance >>> patches for making the test suite run well on windows. >>> >>> Another remark on cross-system: as we are aware of the issues, we >>> provides docker container, continuously delivered, fully tested on >>> each >>> merge. That way one can run James in a reliable environment, whatever >>> the system it is running on. >>> >>> For your information: >>> - https://docs.docker.com/ >>> - https://github.com/apache/james-project/tree/master/dockerfiles >>> >>> >>> That being said, I'm sorry to tell you your mail is hardly readable, >>> and >>> I can not extract interesting information out of it. >>> >>> You did a great work testing different environments, and I should >>> thank >>> you for this. >>> >>> Wouldn't you mind sending us, for each bug you encountered: >>> - The Junit test that failed >>> - The explanation JUnit is giving >>> - The environment (Maven version, Java version, OS, default >>> encoding) >>> >>> >>> That would allow us to work in a rather more productive way. >>> >>> Cheers, >>> -- >>> Tellier Benoit >>> >>> Software engineer dedicated to OpenPaaS at Linagora >>> PMC of the Apache JAMES project >>> VIE in Vietnam >>> >>> https://twitter.com/AwesomePaaS >>> https://medium.com/linagora-engineering >>> >>> Le 05/06/2017 à 16:00, cryptearth a écrit : >>>> So, to start this of with a meme: One does not simply - compile >>>> Apache >>>> James from source. >>>> Idk if and what I'm doin wrong here, but either its my hardware >>>> screwing >>>> up everything I've learned about Java (would explain random crashes >>>> in >>>> GTA5 tho) or I'm just to stupid to correctly setup the needed build >>>> environment to get a successfull build. >>>> But let me start from the beginning why I'm back after abandoning >>>> this >>>> mail-list (still not used to this kind of public communication): >>>> >>>> So as I was successfull to compile one of the latest builds before >>>> this >>>> project moved to Docker and have it running on my openSuSE-tumbleweed >>>> server since (and as smart as I am: deleted the built package - of >>>> course!) - I just looked up the main project page and noticed: oh, >>>> it's >>>> out of beta - RC1 available for download. But as the page shows >>>> "Docker" >>>> (sidenote: yea - I know it makes sense to "containerize" such code - >>>> to >>>> run a Java code as root is not the smartest idea one can have) I said >>>> to >>>> mysefl: "screw it - compile from source" - and off we go from "wonder >>>> if >>>> it's still crap as last time I tried" to "what the F*?". >>>> >>>> So let me show the results first and then let me explain why I think >>>> my >>>> hardware is broken: >>>> >>>> vm - opensuse tumbleweed - failed: apache-james-mailbox-hbase >>>> vm - debian 8.8.0 - failed: james-server-mailets >>>> host - win7 sp1 ulti x64 - failed: apache-james-mailbox-store >>>> >>>> I don't bother you with posting the logs - as it seems some wired >>>> random-ish but surprisingly re-produceable stuff going on here: >>>> As building james isn't more than compiling Java source into bytecode >>>> - >>>> and as Java is supposed to be platform-independent - it should fail >>>> on >>>> the exact same point on each different system - but it doesn't. >>>> Unlike >>>> earlier tries where it "crashed" random on the same system - at least >>>> no >>>> it's "crashing" on the same spot every time - but why and how? The >>>> only >>>> difference are Linux vs Windows and openJDK8u131 vs Oracle 8u121 - >>>> and >>>> as far as I know Java as a hobbiest dev this shouldn't happen. At >>>> least >>>> the error should be the same accross differnt systems - no matter if >>>> VM >>>> or real hardware. >>>> >>>> Ok, the error on windows seems to be some wired random-ish encoding >>>> issue, see the few lines of log as follows: >>>> >>>> Failed tests: >>>> DefaultTextExtractorTest.textTest:44 expected:<...e awesome text >>>> text.[ >>>> ] >>>> "> but was:<...e awesome text text.[ >>>> ] >>>> "> >>>> >>>> I can only imagine there is something goin on with different >>>> line-endings as the build expecting only linux-style \n while my >>>> windows >>>> using \r\n - confusing the equality check to fail (some more like >>>> this >>>> if you try to bootstrap ant from source on windows - it fails cause >>>> windows doesn't support posixfileattributes - wich could checked and >>>> handled in a very easy way - but this should belong to the >>>> ant-maillist). >>>> >>>> The other two on the linux-based systems are very strange: >>>> >>>> On the openSuSE (ok, to be honest - it's the distro I "grew up" with >>>> - >>>> and strangely the only major distro that somehow no body seems to >>>> like >>>> and therefore isn't really supported at all - just: WHY? cause its >>>> german?) it fails with java.lang.ExceptionInInitializerError for >>>> org.apache.james.mailbox.hbase.user.HBaseSubscriptionMapperTest.<clinit> >>>> followed by java.lang.NoClassDefFoundError: Could not initialize >>>> class >>>> org.apache.james.mailbox.hbase.user.HBaseSubscriptionMapperTest >>>> >>>> On the debian (wich went way better and further than the other two) >>>> it >>>> fails with this crap: >>>> >>>> Failed tests: >>>> RemoteDeliveryTest.remoteDeliveryShouldSplitMailsByServerWhenNoGateway:123 >>>> Expecting: >>>> <[FakeMail{msg=null, recipients=[ot...@james.apache.org, >>>> a...@james.apache.org], name=mail_name-to-james.apache.org, >>>> sender=null, >>>> state=null, errorMessage=null, lastUpdated=null, attributes={}, >>>> size=0, >>>> remoteAddr=127.0.0.1}, FakeMail{msg=null, >>>> recipients=[a...@james2.apache.org], >>>> name=mail_name-to-james2.apache.org, >>>> sender=null, state=null, errorMessage=null, lastUpdated=null, >>>> attributes={}, size=0, remoteAddr=127.0.0.1}]> >>>> to contain only: >>>> <[FakeMail{msg=null, recipients=[a...@james.apache.org, >>>> ot...@james.apache.org], name=mail_name-to-james.apache.org, >>>> sender=null, state=null, errorMessage=null, lastUpdated=null, >>>> attributes={}, size=0, remoteAddr=127.0.0.1}, FakeMail{msg=null, >>>> recipients=[a...@james2.apache.org], >>>> name=mail_name-to-james2.apache.org, >>>> sender=null, state=null, errorMessage=null, lastUpdated=null, >>>> attributes={}, size=0, remoteAddr=127.0.0.1}]> >>>> elements not found: >>>> <[FakeMail{msg=null, recipients=[a...@james.apache.org, >>>> ot...@james.apache.org], name=mail_name-to-james.apache.org, >>>> sender=null, state=null, errorMessage=null, lastUpdated=null, >>>> attributes={}, size=0, remoteAddr=127.0.0.1}]> >>>> and elements not expected: >>>> <[FakeMail{msg=null, recipients=[ot...@james.apache.org, >>>> a...@james.apache.org], name=mail_name-to-james.apache.org, >>>> sender=null, >>>> state=null, errorMessage=null, lastUpdated=null, attributes={}, >>>> size=0, >>>> remoteAddr=127.0.0.1}]> >>>> >>>> Just another encoding-issue based on non-standard non-EN/US setup >>>> (all >>>> systems share locale de-de)? This seems to be another issue based on >>>> wrong String comparison. >>>> >>>> So - to complete this kinda sarcastic-ish mail with a few final >>>> words: >>>> >>>> 1.) Does anyone of you have any clue why the same source behave so >>>> differently on different systems? This is somehow against anything >>>> else >>>> I know about Javas famous "write once - run everywhere". >>>> 2.) Could anybody please be so kind to just get a me quick overview >>>> about how to correctly setup a working build environment to get the >>>> current source built successfully? >>>> >>>> Call me stupid - or just naiv cause I don'T know anything about >>>> modern >>>> development on projects this size - but as a Windows-98 kid from >>>> times >>>> where Google didn't existed yet and just got few low-ish games by >>>> burned >>>> CDs from school friends (online DRM wasn't a thing back then) who is >>>> just used to "double-click on setup/install and hit next until it >>>> says >>>> fin" - there is no clue why this to-be-simple-magic-box called "PC" >>>> under my desk behaves this way. It's just a big calculator - and I >>>> expect it to output 2 if I enter 1+1. Maybe someone can explain ... >>>> >>>> >>>> I don'T really expect any serious response/reply - nor to have any >>>> changes in the source - but as Benoit Tellier (btw: big shout outs to >>>> him) once told me: each commit gets auto-compiled and only passed >>>> ones >>>> even released to public - so it has to be some sort of error on my >>>> site. >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org >>> For additional commands, e-mail: server-user-h...@james.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org >> For additional commands, e-mail: server-user-h...@james.apache.org > >--------------------------------------------------------------------- >To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org >For additional commands, e-mail: server-user-h...@james.apache.org >
