Infoglue and Maven

OK, I see. Thanks!

InfoGlue is full of hidden features, that's for sure.

jaric wrote:
InfoGlue is full of hidden features, that's for sure.

You can't be more right

astik wrote:

jaric wrote:
what template editor?!!?

In content type definition, when you edit text area, you have some options to enable or disable some editors. You may have done it with WYSIWYG editor set to true.
You have other usual editor : content relation and structure relation editor. There is some more editors like the template one.

To be honest I never used it, as I worked only in Eclipse. Even back in the days, I used to copy/paste template in eclipse and back to IG =D

The template editor was built a long time ago and was a applet editor which provided line-numbers, velocity code help and some syntax highlighting but it was crap and I never used it much either. I doubt it is used much if any. I vote for removal.

Regards
Mattias Bogeblad

This message was edited 1 time. Last update was at 31/01/2011 01:01:16

bogeblad wrote:I vote for removal

Agree.
Let's get rid of what is not used, starting with applet =)

CMS application is nearly finish, but I'm kind stuck right now :(

I have disable Milton in web.xml (servlet and servlet mapping) as I don't have the needed to make the custom milton distrib Infoglue is using.

I having issues with velocity. As we said earlier, there is a jar marked as IG patched, if we uncompress this jar and decompile some class, we can see there are differences from the official distrib (v1.6.3). I can't go further.
If I let the jar "as is" (official release of velocity 1.6.3 and webwork 1.4), I've got a null pointer exception while initializing the velocity context. If I go back to v1.5, it works, but velocity template don't render because the use some new feature from 1.6 (at minimum).

It seems there are also difference with webwork.jar, except if the version include in Infoglue is not 1.4. In that case, I really like some help on this one too :?

Before going to bed, I'd like to know if there is a reason to use org.infoglue.deliver.portal.dispatcher.PortalServletDispatcher as the action servlet in the CMS instead of webwork.dispatcher.ServletDispatcher ? For the deliver side I can understand the logic (portal needs), but the back office ...

This message was edited 1 time. Last update was at 31/01/2011 10:53:55

astik wrote:CMS application is nearly finish, but I'm kind stuck right now :(

I have disable Milton in web.xml (servlet and servlet mapping) as I don't have the needed to make the custom milton distrib Infoglue is using.

I having issues with velocity. As we said earlier, there is a jar marked as IG patched, if we uncompress this jar and decompile some class, we can see there are differences from the official distrib (v1.6.3). I can't go further.
If I let the jar "as is" (official release of velocity 1.6.3 and webwork 1.4), I've got a null pointer exception while initializing the velocity context. If I go back to v1.5, it works, but velocity template don't render because the use some new feature from 1.6 (at minimum).

It seems there are also difference with webwork.jar, except if the version include in Infoglue is not 1.4. In that case, I really like some help on this one too :?

Before going to bed, I'd like to know if there is a reason to use org.infoglue.deliver.portal.dispatcher.PortalServletDispatcher as the action servlet in the CMS instead of webwork.dispatcher.ServletDispatcher ? For the deliver side I can understand the logic (portal needs), but the back office ...

Hi Astik,

About the Milton patch it was made so webdav would work on Mac OSX I think. There was some idiotic bug which made it impossible to use otherwise. I'm not sure how we handle this.

About velocity I also made some patches (small ones) as the 1.6 and now 1.7 seems to be backward-incompatible and from my point of view we cannot risk having all customer sites break because of velocity. The change in behaviour is mainly that it has become much stricter (which is good in a way) in nulls and macros. The problem is that it throws exception were it before did not and although we may change our templates in the cms-app to meet this I don't think we can expect all customers to be so understanding. Should we check in the patched source so you can replace the velocity jar or how is it best handled.

I'll come back on the Dispatcher-issue - I have not had time to look at it. Also - I judge this as not critical for now and we can change this behaviour in 3.1 instead if we want so maybe I put it on the backlog. Objections?

Regards
Mattias Bogeblad

bogeblad wrote:
About the Milton patch it was made so webdav would work on Mac OSX I think. There was some idiotic bug which made it impossible to use otherwise. I'm not sure how we handle this.

If there are patched sources, we must get all the modified jar source and put them into infoglue source control. i did it for "property set" as there is no official distrib for the latest version.

bogeblad wrote:
About velocity I also made some patches (small ones) as the 1.6 and now 1.7 seems to be backward-incompatible and from my point of view we cannot risk having all customer sites break because of velocity. The change in behaviour is mainly that it has become much stricter (which is good in a way) in nulls and macros. The problem is that it throws exception were it before did not and although we may change our templates in the cms-app to meet this I don't think we can expect all customers to be so understanding. Should we check in the patched source so you can replace the velocity jar or how is it best handled.

As earlier for milton, we must check in the modified source and depend only on our new jar. But the best thing would be to depend on official release to make evolution easier. Even if it breaks some user modifications, it will push the quality forward.

bogeblad wrote:
I'll come back on the Dispatcher-issue - I have not had time to look at it. Also - I judge this as not critical for now and we can change this behaviour in 3.1 instead if we want so maybe I put it on the backlog. Objections?

The idea is to remove portal dependency (pluto) from the CMS as it don't seem to be needed and make the CMS as light as it can be =)

astik wrote:

bogeblad wrote:
About the Milton patch it was made so webdav would work on Mac OSX I think. There was some idiotic bug which made it impossible to use otherwise. I'm not sure how we handle this.

If there are patched sources, we must get all the modified jar source and put them into infoglue source control. i did it for "property set" as there is no official distrib for the latest version.

bogeblad wrote:
About velocity I also made some patches (small ones) as the 1.6 and now 1.7 seems to be backward-incompatible and from my point of view we cannot risk having all customer sites break because of velocity. The change in behaviour is mainly that it has become much stricter (which is good in a way) in nulls and macros. The problem is that it throws exception were it before did not and although we may change our templates in the cms-app to meet this I don't think we can expect all customers to be so understanding. Should we check in the patched source so you can replace the velocity jar or how is it best handled.

As earlier for milton, we must check in the modified source and depend only on our new jar. But the best thing would be to depend on official release to make evolution easier. Even if it breaks some user modifications, it will push the quality forward.

bogeblad wrote:
I'll come back on the Dispatcher-issue - I have not had time to look at it. Also - I judge this as not critical for now and we can change this behaviour in 3.1 instead if we want so maybe I put it on the backlog. Objections?

The idea is to remove portal dependency (pluto) from the CMS as it don't seem to be needed and make the CMS as light as it can be =)

Hi,

Yes - I'll check in all the patched source. Since it is for both cases only a line or two in on or two classes it seems stupid but when I use the latest velocity nothing in infoglueCMS works due to bad coding in velocity. The same would probably happen to a lot of customers so I'll propose we try to get the patches accepted in the velocity main branch.
Again - about the dispatcher - let's do that in 3.1 instead - we have to much to do as it is. At least my todo is long and I would prefer we take the critical issues and bugs first.

Regards
Mattias Bogeblad

I moved to thread to the Core Developer forum. I hope that was OK...

jaric wrote:I moved to thread to the Core Developer forum. I hope that was OK...

Hi, I fixed a few bugs tonight (mainly gui and logic) but also removed the tree-applet and the code-editor applet.
Tomorrow I will look into publishing the velocity and milton-dependencies. Hope you can wait.

Regards
Mattias Bogeblad

bogeblad wrote:

gmw wrote:As I didn't notice this thread before I posted in the "Core Development" section, I'll post my thoughts here I spent some time last fall trying to track down InfoGlue's Maven dependencies, and also stumbled into the dependencies you mention in the README.txt.

Regarding the dependencies: the JSObject class can be found in the "plugin.jar" file in the JDK (it's part of the JDK applet/browser integration), so it should be possible to refer to this jar using the "system" scope as described in

http://stackoverflow.com/questions/364114/can-i-add-jars-to-maven-2-build-classpath-without-installing-them

Although this is not a recommended practice, I think it is better than forcing every developer to install a dummy artifact that's already guaranteed to be present on the local machine (at least when using Sun/Oracle's JDK). Of course, if the codeeditor was implemented as a non-applet, it would be even easier

Regarding the pmiw.jar (the com.mullassery.imaging.* classes), it's being used to scale images in about two places in the actual code (as I remember it),
so perhaps it's not a lot of work replacing it by say, JAI (http://jai.dev.java.net)?

While I did spend some time trying to track down InfoGlue dependencies, I spent no time at all on structuring components. It's great to see some work being done on that as well!

Hi,

I would say we ditch the template editor. With the eclipse-plugin and new webdav-support we don't really need an applet there do we? If we can find a simple code highlighter i javascript that would be enough I think inside Infoglue.
Do you agree?

Regards
Mattias Bogeblad

Hi,

I looked a bit at pmiw.jar-replacements and I cannot find any real good options. The JAI seems to have been discontinued and has not been updated for a while. Perhaps we can use it anyway but I would rather find an even better library. Or we include the pmiw.jar-source inside Infoglue if possible.

What do you think?

Regards
Mattias Bogeblad

bogeblad wrote:
Perhaps we can use it anyway but I would rather find an even better library. Or we include the pmiw.jar-source inside Infoglue if possible.

We have to get all the sources for Infoglue to be as transparent as possible, especially for uncommon jar. So, while looking for something new / better, we can include the pmiw sources.

Hi Astik,

I'm trying to find the src for the image library but it seems completely removed from the web.
Can you see if you can find it as wel so I'm not just blind. Otherwise I guess we have to decompile his code or something if we cannot have the jar as is.

We should implement our own scale/crop-classes instead ASAP but I have read some bad comments about JAI and memory etc.

Regards
Mattias Bogeblad

bogeblad wrote:
I'm trying to find the src for the image library but it seems completely removed from the web.
Can you see if you can find it as wel so I'm not just blind. Otherwise I guess we have to decompile his code or something if we cannot have the jar as is.

That's where I'd been last year, i couldn't find the sources. In that case, no need to decompile, we'll put the jar "as is".

Hi - I will try to implement an example I found on the net which does the scale / crop but not through JAI but through plain old java. Not as fancy but we don't need fancy right now.

Regards
Mattias Bogeblad