Infoglue and Maven

Hi all,

As discussed in other thread, we are trying to make Infoglue work with maven.
I had worked on this task for a long time 2 years ago and had a pretty decent result. Past week-end, I decided to make it work with the latest sources (now on GIT). Some stuff are missing to make it fully work with maven :
- some jar are not available anywhere on the net (2 of them) : binaries are available in the project, you'll need to deploy / install them manually
- some jar are available on the net only as source, no binary : sources have been collected and add into a maven project
- some jar are patched by IG (2 of them : milton + velocity) : no source available for the patch, I've got only the official binaries

For Milton, the patch seems to be more important as there is a Factory of Factory that is defined and I don't have it anywhere.

For all the other jar, I managed to find the dependency information (version and specific repository).

The simpliest thing to do is to put all the source in only on jar, but that is not the maven spirit. The idea is to make little jar specialised on a specific area : actions, utils, entities, webservice, controller, ... That way it would be simplier to make it evolve.

To do that, we need to make less coupling between jar, and the first thing to do is to organise import. I have forked infoglue and have done this task, there is a pending pull request on that. Matthias it's your choice =)

I also will need the source for the patched jar, maybe we should put them into the Infoglue source directory, or take a look to see if we still need those patches.

My work will be available on GIT soon. I hope to do it before the end of the week.

Very good effort, Astik!

Thanks for moving the community forwards

This message was edited 2 times. Last update was at 24/01/2011 14:55:35

Hi Astik - it's very nice to have a do:er in the project.
I will look at the patched files and see if we can manage without. Otherwise I will publish the patches.
Also - I will look at the pull request - I just love Git in this respect - so much easier to submit and accept changes etc. You should however sign a committer agreement. Should I send one over?

Regards
Mattias Bogeblad

This message was edited 1 time. Last update was at 25/01/2011 11:40:14

bogeblad wrote:Also - I will look at the pull request - I just love Git in this respect - so much easier to submit and accept changes etc.

Indeed, it will simplify centralization of code and I think it will simplify a lot merge for you.

bogeblad wrote:You should however sign a committer agreement. Should I send one over?

I'd be happy to join the commiter team !
Here are my github info : https://github.com/astik

For information :

2 jars can't be found on the Internet :
- netscape-javascript.jar
- pmiw.jar

One other particular jar, propertyset-1.4 is not available as a build, it is only available as a tag in openymphony svn.
I don't know if there is a Infoglue patch over it.

2 jars are into Infoglue as patched jar :
- Velocity : velocity-1.6.3IGPatched
- Milton : milton-api-1.5.4IGPatched

Hi,

The Version that is in the Git repository is version 3? I thought it was version 2 so I was waiting for version 3 to be there to start breaking things

. On a side note, it seems that the consensus is to use Maven. Should we create a Git branch testing the Ant+Ivy approach or is it already clear that Maven is the way to go?

uibcti wrote:Hi,

The Version that is in the Git repository is version 3? I thought it was version 2 so I was waiting for version 3 to be there to start breaking things . On a side note, it seems that the consensus is to use Maven. Should we create a Git branch testing the Ant+Ivy approach or is it already clear that Maven is the way to go?

Hi, its the 3.0 beta that is transferred to Github - the 2.x branch is still in cvs and I doubt we will move that very soon. I think we can move forward with maven instead of investigating a lot and do nothing. But of course if someone has a strong mind about Ivy/ant we sure apprechiate someone making an example and proving it. It may be a case of "the first solution wins"

. If a functional setup is made with ant/ivy I would not stress the need of maven and vice versa.

Regards
Mattias Bogeblad

For those who want to give it a try :
https://github.com/astik/infoglue-maven

There is a readme explaining how it works.

The project contains an empty maven structure which is populated with the java source from a branch.
The populate part is made with ant.
So, to be clear, it is not the final maven vision =)

For now, it only manage the src/java part of the source.
There is a lot of work to do, tell me if we must go on this way.

This message was edited 1 time. Last update was at 28/01/2011 12:51:21

astik wrote:For those who want to give it a try :
https://github.com/astik/infoglue-maven

There is a readme explaining how it works.

The project contains an empty maven structure which is populated with the java source from a branch.
The populate part is made with ant.
So, to be clear, it is not the final maven vision =)

For now, it only manage the src/java part of the source.
There is a lot of work to do, tell me if we must go on this way.

Hi Astik,

Great initiative - I will try to test it but I think I should not mess around in all areas so I would be fine with appointing you lead in the configuration / build management area. If you want that title and responsibility that is. No pressure.
On objectives forward I would say we should start with the different deployment-bundles so we can start testing for a RC1 built by Maven. Initially this would mean just being able to generate the application war-files for example.

Regards
Mattias

This message was edited 2 times. Last update was at 27/01/2011 15:30:02

bogeblad wrote:
I would be fine with appointing you lead in the configuration / build management area. If you want that title and responsibility that is. No pressure.

Challenge accepted =)

bogeblad wrote:
On objectives forward I would say we should start with the different deployment-bundles so we can start testing for a RC1 built by Maven. Initially this would mean just being able to generate the application war-files for example.

That's why I made the ant mechanism to populate. If we migrate right now, it would freeze development while finishing the migration. Having the population process allows development to go on.
My main goal is to have the 4 webapps running. Now that I have done the jar part, it won't be too difficult I think.
If you want to help on this, thanks to github, please fork =D

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!

gmw wrote:
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!

If you could send me the results of your search, it'll be great as I'm not sure of what version are really used for the component =/
Or you can fork my project and we can work on it together =D

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

This message was edited 1 time. Last update was at 28/01/2011 12:55:28

bogeblad wrote:I would say we ditch the template editor.

Excuse a newbie, but: what template editor?!!?

This message was edited 1 time. Last update was at 28/01/2011 13:01:37

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