import other classes to a class is mainly a pain… a lot of imports are normally needed, a few are duplicated, and this is crap… based on PMD… ok it might be right, but in my point of view the compiler should clean the import… not that i have ever thought about it, but currently i do… 😛
and eclipse can clean the imports easyly….
Crtl+Shift+o
bah…
this bug sucks… and its funny, because i get it from time to time… solution is kinda easy…
add following link in eclipse.ini
-vm
C:\java\jdk\bin\javaw.exe
before
-vmargs
Comments Off on Eclipse is running in a JRE, but a JDK is required
Posted in Uncategorized
ok tryed some things with the mule imap:connector and its kinda cool… and its kinda crap… a few functions are really cool, but dont work as expected…
imap:connector
imap:inbound-endpoint
all in all it is a really powerful connector, which reads the mailbox frequently and can be used as perfect flow starter… additionally it returns an MimeMessage, with all the Headers and so on… but on the other hand, it cant handle the mails on the imap server… it looks like the handling on the server needs to be implemented with a POJO… if this is the way to go is a complete new question…
A game in which each player must respond with a question. Statements are out, repetition and rhetoric are not allowed.
Comments Off on Verbal tennis
Posted in Uncategorized
in my project at work we need to read a mail box… sounds not so easy, but actually is… mule imap:connector for the win 🙂
but testing this is a pain… first of all i needed a mail account with imap access… my company is really big an the processes to get such an email adress is huge… and yeah… we are an isp 😛 so just try to get a simple free email adress with imap… kinda hard… fastmail.fm is the solution…
could connect, but couldnt read or find directories… so had to connect with telnet, to find out everything…
in commandline:
this helped…
mule is a simple message router, which is configured in an .xml (mostly mule-config.xml)… following main elements can be found in it:
there are 2 types of flows… flows with an outgoing-endpoint and flows without… in a flow it is possible to define multiple entrypoints and it should be possible to define multiple endpoints… i think, only 1 component can be defined… a PoC will show…
so a normal flow will be as followed:
additionally there is a model and services in the config file… couldn’t figure out, what the heck they are for…
my project at work will use mule as central framework and so i need to come up to speed with this technology as well…
mainly it should be an esb… but actually is my understanding of a bus completely different… mule is a centralized server, where messages are forwarded… ok its a little bit bigger… incoming messages are handled in a flow… transformed if needed and sent out, as outgoing messages to other applications, components…
but where is the bus? my bus understanding is a (lets say) cable, where all applications/components can attach themselfs and lock into the dataflow in the cable, and take the message, if it concerns them… like Observer-Pattern… but in mule, the message flow is defined on the server, with inbound- and outbound-endpoints… so where is the bus?
pom.xml is the configuration file of maven… the main file… the one most important file… and its kinda confusing… 🙁
the basic xml tags are easy and mostly slefexplaining… every thing is based on the basic lifecycle… but with plugins it is possible to improve and change the lifecycle…
first of all it is possible to create Mojo classes (<name>Mojo)… these classes can be executed during the build process… whereas the pluginname (artifactId) is mavan-<name>-plugin… and if set a groupId a java package name… with a <configurations> tag it is possible to set private parameters on initialisation…
additionally these classes can be executed… in the <execution> the when of the execution can be defined, in which phase (phase-tag).
actual its really confusing but i think i start to see the power of maven… but i think learning maven is only possible to do so on the job… so only if you really need to create plugins, dependencies and other fancy stuff, you really understand it… and the problem of this learning approach is lerning-it-wrong possibility…
currently there is a pom.xml file on my project, so my maven learning curve will be slow 🙁 or just flat 😛
ok commands are cool… understanding them is easy… but seeing behind it is hard, but important… follworing list of commands is from Build Lifecycle Basics:
the important thing here is, that if you call package, all the commands before will be called… eg. validate, compile, test and package.
this is the default behavior and can be modified by plugins…
the tutorial is actually really good, and i think i understand it… ok currentlly its just the basic tutorial project, but hey… i really didnt know anything…
following command list might be useful 🙂
there are other commands… but currentlly less important…