You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-user@james.apache.org by cryptearth <cr...@cryptearth.de> on 2017/06/05 09:00:44 UTC
failed to compile from source - again
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=[other@james.apache.org,
any@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=[any@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=[any@james.apache.org,
other@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=[any@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=[any@james.apache.org,
other@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=[other@james.apache.org,
any@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.
Re: AW: Re: failed to compile from source - again
Posted by Raphael OUAZANA <ra...@linagora.com>.
Hi,
The best way if you want to fix these flaky tests (ie non deterministic
tests) is to try to reproduce them in your favorite IDE.
Regards,
Raphaël Ouazana.
Le 2017-06-08 13:28, cryptearth a écrit :
> Hey Benoit,
>
> first: sorry for getting your name the wrong way around - I was
> confused by your signature.
>
> About maildir not supported on Windows: didn't knew, but IOException
> got thrown and the stack for it made it pretty clear whats happening.
>
> Fun fact: try to compile a class called "aux" - it will fail cause the
> filename "aux.class" is reserved and can't be choosen as file- or
> folder-name by normal user.
>
> I'm getting confused about HBase as I couldn't find any line that's
> system depended, so I can't figure out what's raising the error as the
> stack looks incomplete. Is there any other way to get a full stack for
> such errors? Maybe I'm able to figure out what's wrong when I get the
> line causing the fail.
>
> Matt
>
> ---- Benoit Tellier schrieb ----
>
>> Hi,
>>
>> My answers inlined...
>>
>> Cheers,
>>
>> Le 08/06/2017 à 16:16, cryptearth a écrit :
>>> 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).
>>
>> ByteCode runs everywhere, true.
>>
>> However, you still depend on the system for fileSystem (resource
>> names),
>> what your operating system allows (file locks, etc...), encoding,
>> etc...
>>
>> That is some kind of concerns that should be enforced in your code...
>>
>>> 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.
>> Note that maildir in James is documented as not supported for Windows.
>>
>>> Wouldn't any problem when using database as storage - but could lead
>>> to unexpected failures during runtime.
>>
>> True, this can create issues at run-time.
>>
>> That being said, it's an open source project. Contributions are
>> welcome
>> to improve cross plateform situation.
>>
>>>
>>> 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=[other@james.apache.org,
>>>>>>> any@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=[any@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=[any@james.apache.org,
>>>>>>> other@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=[any@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=[any@james.apache.org,
>>>>>>> other@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=[other@james.apache.org,
>>>>>>> any@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-unsubscribe@james.apache.org
>>>>>> For additional commands, e-mail: server-user-help@james.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>>>>> For additional commands, e-mail: server-user-help@james.apache.org
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-user-help@james.apache.org
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-user-help@james.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
AW: Re: failed to compile from source - again
Posted by cryptearth <cr...@cryptearth.de>.
Hey Benoit,
first: sorry for getting your name the wrong way around - I was confused by your signature.
About maildir not supported on Windows: didn't knew, but IOException got thrown and the stack for it made it pretty clear whats happening.
Fun fact: try to compile a class called "aux" - it will fail cause the filename "aux.class" is reserved and can't be choosen as file- or folder-name by normal user.
I'm getting confused about HBase as I couldn't find any line that's system depended, so I can't figure out what's raising the error as the stack looks incomplete. Is there any other way to get a full stack for such errors? Maybe I'm able to figure out what's wrong when I get the line causing the fail.
Matt
---- Benoit Tellier schrieb ----
>Hi,
>
>My answers inlined...
>
>Cheers,
>
>Le 08/06/2017 à 16:16, cryptearth a écrit :
>> 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).
>
>ByteCode runs everywhere, true.
>
>However, you still depend on the system for fileSystem (resource names),
>what your operating system allows (file locks, etc...), encoding, etc...
>
>That is some kind of concerns that should be enforced in your code...
>
>> 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.
>Note that maildir in James is documented as not supported for Windows.
>
>> Wouldn't any problem when using database as storage - but could lead to unexpected failures during runtime.
>
>True, this can create issues at run-time.
>
>That being said, it's an open source project. Contributions are welcome
>to improve cross plateform situation.
>
>>
>> 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=[other@james.apache.org,
>>>>>> any@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=[any@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=[any@james.apache.org,
>>>>>> other@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=[any@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=[any@james.apache.org,
>>>>>> other@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=[other@james.apache.org,
>>>>>> any@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-unsubscribe@james.apache.org
>>>>> For additional commands, e-mail: server-user-help@james.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-user-help@james.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-user-help@james.apache.org
>>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>For additional commands, e-mail: server-user-help@james.apache.org
>
Re: failed to compile from source - again
Posted by Benoit Tellier <bt...@linagora.com>.
Hi,
My answers inlined...
Cheers,
Le 08/06/2017 à 16:16, cryptearth a écrit :
> 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).
ByteCode runs everywhere, true.
However, you still depend on the system for fileSystem (resource names),
what your operating system allows (file locks, etc...), encoding, etc...
That is some kind of concerns that should be enforced in your code...
> 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.
Note that maildir in James is documented as not supported for Windows.
> Wouldn't any problem when using database as storage - but could lead to unexpected failures during runtime.
True, this can create issues at run-time.
That being said, it's an open source project. Contributions are welcome
to improve cross plateform situation.
>
> 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=[other@james.apache.org,
>>>>> any@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=[any@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=[any@james.apache.org,
>>>>> other@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=[any@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=[any@james.apache.org,
>>>>> other@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=[other@james.apache.org,
>>>>> any@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-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-user-help@james.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-user-help@james.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-user-help@james.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: failed to compile from source - again
Posted by cryptearth <cr...@cryptearth.de>.
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=[other@james.apache.org,
>>>> any@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=[any@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=[any@james.apache.org,
>>>> other@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=[any@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=[any@james.apache.org,
>>>> other@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=[other@james.apache.org,
>>>> any@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-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-user-help@james.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-user-help@james.apache.org
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>For additional commands, e-mail: server-user-help@james.apache.org
>
Re: failed to compile from source - again
Posted by Raphael OUAZANA <ra...@linagora.com>.
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=[other@james.apache.org,
>>> any@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=[any@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=[any@james.apache.org,
>>> other@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=[any@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=[any@james.apache.org,
>>> other@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=[other@james.apache.org,
>>> any@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-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-user-help@james.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> For additional commands, e-mail: server-user-help@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: failed to compile from source - again
Posted by cryptearth <cr...@cryptearth.de>.
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=[other@james.apache.org,
>> any@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=[any@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=[any@james.apache.org,
>> other@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=[any@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=[any@james.apache.org,
>> other@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=[other@james.apache.org,
>> any@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-unsubscribe@james.apache.org
> For additional commands, e-mail: server-user-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: failed to compile from source - again
Posted by Benoit Tellier <bt...@linagora.com>.
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=[other@james.apache.org,
> any@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=[any@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=[any@james.apache.org,
> other@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=[any@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=[any@james.apache.org,
> other@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=[other@james.apache.org,
> any@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-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: failed to compile from source - again
Posted by Matthieu Baechler <ma...@apache.org>.
Hi,
There's several things worth saying :
1. I'm pretty sure you can build james by preventing the test suite to
execute (-DskipTests should do the trick)
2. A huge test suite is something every serious software should have but
it makes everything more complicated. What would you prefer : random
bugs appearing with every commit or a hard to manage test suite ?
Actually, we try to manage this complexity by providing a standardized
test env : the docker image.
3. if you want more support, please connect to our gitter channel : it's
much more comfortable for most people and would probably avoid calling
our work "crap"
Hope you join us soon on gitter,
--
Matthieu Baechler
On 06/05/2017 11:00 AM, cryptearth wrote:
> 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=[other@james.apache.org,
> any@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=[any@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=[any@james.apache.org,
> other@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=[any@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=[any@james.apache.org,
> other@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=[other@james.apache.org,
> any@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.
>