Infoglue and Maven

It seems like there is not a lot of (free) imaging libraries for Java. Some links on the subject:

http://stackoverflow.com/questions/244164/resize-an-image-in-java-any-open-source-library

http://stackoverflow.com/questions/603283/what-is-the-best-java-image-processing-library-approach

Hi,

I replaced the pmiw.jar with imgscalr 2.0 instead. Removed all dependencies in classpath and logic etc. It resulted in better quality where used as well although I did not time it. Those features where it is used now are infrequently used. If we should change all thumbnail gen to use this as well however we must profile and test very thorough.

I also removed and checked in all references to tree and templateEditor-applets and removed the netscape-javascript-jar you complained about. Good to clean the codebase now and then. I would like a program to go through all the presentationStrings-files and check which labels are no longer used. But before that - we should remove all old GUI-templates (v2-interface) as they contain most of those references. And old images with text in them should go as well... many tasks. But let's find all the bugs first.

Next up
Regards

Good job on this Mattias !

This message was edited 1 time. Last update was at 02/02/2011 10:29:04

astik wrote:Good job on this Mattias !

Thanx - not so much fun but thanx for pushing us toward a better / cleaner codebase (it's easy to get comfy). Now it's just velocity and milton...

/Mattias

Hi,

I've done quite some tests on milton (webdav) and velocity (now 1.7) and the problems I had with them which made me patch them remains.

Milton or the client softwares on mac has some bugs that makes it impossible to upload anything. Perhaps we can sort this later but for now I cannot get how. The compability guide on milton webdav site states that many platforms has problems with webdav so it's not a protocol I suggest we promote hard. I think we should either skip webdav support totally or use the patched jar I have (I have the source-code but don't know where to put it). The patched one seems to work ok on windows and mac.

When it comes to velocity it's only a small method in one class I have patched:

The old one was

The exception we got was that when we had a null or nonexistent value velocity (unlike in 1.5) throws an exception here because the callingArgument is not a Node in many of our cases but rather our Action-object. I have not checked deeper into why this is and if there are a better way to solve it but I changed the method into:

This can be used by us to find all nullplaces as the system out in it writes out the location. Perhaps we can fix most problems in the velocity files but the risk is imminent that there are special cases that may be missed. And having velocity break down in that case seems bad. Instead I propose we keep our patched jar and changed class and try to talk to the velocity guys. We should fix as many of the velocity-problems we can also. Hopefully a future version of velocity will have corrected this and then we can throw away ours.

What do you think? Any alternative routes you see?

Regards
Mattias Bogeblad

bogeblad wrote:
Milton or the client softwares on mac has some bugs that makes it impossible to upload anything. Perhaps we can sort this later but for now I cannot get how. The compability guide on milton webdav site states that many platforms has problems with webdav so it's not a protocol I suggest we promote hard. I think we should either skip webdav support totally or use the patched jar I have (I have the source-code but don't know where to put it). The patched one seems to work ok on windows and mac.

I have heard a lot of issues coming from webdav on mac, it's not only milton =/ If you decided to skip mac support, use the official jar. If you want to keep it, please add the milton source code to infoglue source code (maybe as a separate folder at first), it will be easy to manage it with maven as a separate module (as I did with the property set). The choice for the mac support is up to you =)

bogeblad wrote:
When it comes to velocity it's only a small method in one class I have patched:

Same here, provide the complete source code as a separate folder, maven will do the rest =)

Should I put the patch-versions of the two frameworks in the infoglue-project or can we have it in the maven-project? Perhaps you stated earlier but remind me if so.

Regards
Mattias

bogeblad wrote:
Should I put the patch-versions of the two frameworks in the infoglue-project or can we have it in the maven-project? Perhaps you stated earlier but remind me if so.

For now, the maven-project take the infoglue-project and morph it into a maven hierarchy.
So if the patch is not inside the infoglue-project, i won't get it.
Another way to do it, as I did for property set, is to send me the complete source for each jar that have been patched with their proper patch. A readme explaining the reason of the patch would be helpfull for maintainability. Don't forget to tell me which version of each jar are patched (velocity 1.7 ? milton 1.5.6 ?).

I think I prefer the latter to avoid cluttering the infoglue-project so I'll send you a lonk to the zipped patched projects and you can handle them like propertyset.

Regards
Mattias

For those of you curious enough, there is a maven CMS application available.
You have to build it following this link : https://github.com/astik/infoglue-maven.
Have fun

This message was edited 1 time. Last update was at 16/02/2011 14:00:07

I just tried that and I was unable to package/install the project due to the velocity:jar (1.7-IGPatched) dependency missing.
I guess some more manual processing has to be added in order to install it in the local maven repository, but then it would be nice ot have it automated or documented in the README

.

I played a bit with it and added a new property infoglue.path at the build properties to specifiy where the latest version of "normal" Infoglue is being held, and modified the paths in build.xml to take the property into account.
This way you can have your version of InfoGlue as a "separate project", instead of inside build, and you can update it with Git etc. and then run the ant command to update the sources to InfoGlueMaven whenever you want.

I googled a bit to see if that process could be more easily automated, but Git+Ant are not that integrated (you can call it using the exec task but no pure java task) and as it is something temporary while the project is migrated to Maven...
Maybe the part of calling Ant to update the sources from the normal InfoGlue could be automated and added to Maven, but again not sure if is worth the hassle for something temporary.

S!

Edit: Re-reading the instructions, I see that I might have to go manually to the propertyset, velocity directories to build the jars... my bad, I thought they would be specified as dependencies and built automatically before. So forget my first problem

.

uibcti wrote:I just tried that and I was unable to package/install the project due to the velocity:jar (1.7-IGPatched) dependency missing.
I guess some more manual processing has to be added in order to install it in the local maven repository, but then it would be nice ot have it automated or documented in the README .

It's already in the README =) Look at step2, there are 3 libraries to install before paying with infoglue : propertyset, milton, velocity. After installing those 3 libraries you can install infoglue.

uibcti wrote:
I played a bit with it and added a new property infoglue.path at the build properties to specifiy where the latest version of "normal" Infoglue is being held, and modified the paths in build.xml to take the property into account.
This way you can have your version of InfoGlue as a "separate project", instead of inside build, and you can update it with Git etc. and then run the ant command to update the sources to InfoGlueMaven whenever you want.

I googled a bit to see if that process could be more easily automated, but Git+Ant are not that integrated (you can call it using the exec task but no pure java task) and as it is something temporary while the project is migrated to Maven...
Maybe the part of calling Ant to update the sources from the normal InfoGlue could be automated and added to Maven, but again not sure if is worth the hassle for something temporary.

I don't do the checkout from git or cvs because the ant build move files. So if you screw your build, you have to checkout again, which can be really long =/
Same thing if you're using the ant build from your git project, it will move files and screw your project.
Building from the zip from github is simple and you can archive the zip if the repository is not looking good (which is not the case, but it could be =D)

uibcti wrote:
Edit: Re-reading the instructions, I see that I might have to go manually to the propertyset, velocity directories to build the jars... my bad, I thought they would be specified as dependencies and built automatically before. So forget my first problem .

Didn't see the edit, sorry =)

Anyway, I wish I could have done that by adding those modules as submodules of infoglue-maven parent pom. But for some of those 3 libraries (milton if I remember well), there is already a parent configuration that exclude the possibility to add this project into my pom. To be consistent, I move the 3 libraries out to have only the infoglue part into the "official" maven project.

astik wrote:Didn't see the edit, sorry =)

Anyway, I wish I could have done that by adding those modules as submodules of infoglue-maven parent pom. But for some of those 3 libraries (milton if I remember well), there is already a parent configuration that exclude the possibility to add this project into my pom. To be consistent, I move the 3 libraries out to have only the infoglue part into the "official" maven project.

I see. I added the velocity one and I see one has to modify the parent pom.xml and causes the same problems that inheritance has in Java

. Oh well, it's not such a big deal as those modules are not supposed to change much so calling once mvn install inside them is not that much.

astik wrote:I don't do the checkout from git or cvs because the ant build move files. So if you screw your build, you have to checkout again, which can be really long =/
Same thing if you're using the ant build from your git project, it will move files and screw your project.
Building from the zip from github is simple and you can archive the zip if the repository is not looking good (which is not the case, but it could be =D)

And why use move instead of copy? Wouldn't it be better to simply copy and not having to download the whole 64MB of zip file everytime Mattias commits something and you want to try it out? It would also allow one to use a custom branch as base source instead of the zipball without breaking one's project. Again, not challenging but just wondering

(sometimes forum written messages do not carry the tone of the dialog completely

)

S!