Version 4.0.Alpha released
After more than a year, I've decided to do some improvements into the application and I've fixed some things.
The project is now maintained with maven.
I've made a major refactoring of some of the beans to allow a better readability and maintanability. Instead of having many classes that do transformations in the email object (preloaders, loaders, mantisactionlisteners), now there is only one: the mail object is passed to a list of MailProcessor beans. One of these processors is the mantis processor, who creates an entry in mantis. Other is the archiver, who moves the original email to another folder in the inbox. Another one is the resender, who resends an email to another address, and so on.
The application can now read from many folders at the same time.
The application now stays resident instead of doing the job and finishing. You can kill the application locally or remotely issuing a "stop" command.
Due to the previous, now there is no need to persist the id of the read messages. Because it stays resident, it keeps track of the id's of the messages in the next reading cycle.
Version 3.0 Beta released
I am proud to announce that I have released the version 3.0 beta.
Since february much work have been done in order to produce an stable version of Jnestor, and a major refactoring of many parts of the project have been made.
This version has major changes compared against previous releases:
- The mantis connection technology are now the stub libraries for SOAP instead MantisConnect. Later I've discovered that MantisConnect weren't supported and I started a process to find a new technology to replace it. Thanks to Robert Munteanu that put me in the lead to the good solution.
- I've installed a "local folder" object that stores the message id in a database, and checks if the message is stored to avoid treat it again. This prevents the flooding of false issues when the message is not deleted from the inbox folder. I've installed a version without this feature and it created 5,000 (yes five thousand) messages in one night of functioning. With this feature, who can't be removed by error, it is impossible to treat the same message two times.
- Instead of the filter by subject and the complex XML configuration in place, I've created an object called "CustomMailPreprocessor" who is written in Groovy. This is fairly easy to modify and customize what messages should be treated and what messages don't.
- One thing that I've discovered while running the previous versions of Jnestor was that the "disclaimer" section of the emails fills the issues with garbage. In order to prevent this, I've cut the messages to the seventh line and attach the original message as a web page. This can be found and modified at your convenience in the "CustomMailPreprocessor" groovy object. Don't be afraid of changing it to fit your needs. The result is that only the revelant information is there and -at least in our cases- we didn't need to check the original page or the original message to see parts of the message that are deleted by error. And we got rid of these disclaimer paragraphs.
- Another interesting thing is that there is an example of custom actions that you can do whenever a issue is entered in the database. I've created a CustomizableAction in groovy that is configured to fill in a "Country" field, but imagination is free to add your own stuff here. Share your ideas with the list and I will give you the hints you may need!!!
- A big problem I had at the first stages of the project was the resending of the email back with the issue stamped in it: the many tests I did finally were the final straw and I've decided to create four versions of the resender object, so you can pick the one that best fit your needs. To me, it's MantisProcessorActionResendAsHtml.