When is 3.0 ready for GA?

Hi David,

All help is good help. I can say that these items are of immediate interest to most:

- connection to postgresql database instead of mysql db !
- usage of attached documents on a webdav repository (through an extension of the FCKEditor) with access control
- French localization
- some improvements in the access rights (IG 3.0 allready has improvements but perhaps you have more in mind).
- better handling in mail sending with publications

Regards
Mattias Bogeblad

David wrote:Hello,

Sorry for the late answer !

Infoglue is running as the official CMS at the Lille 1 university for more than 3 years now. About 20 web sites have been designed on Infoglue. Our team is also an active member of the esup-portail consortium (http://www.esup-portail.org). We have selected infoglue to optimize investment on technologies.

We cannot imagine that the Infoglue development stops in the upcoming years. We cannot put a lot of effort on the development tasks, but we're ready to offer our contribution.

On the infoglue side, we can only develop parts of the code that we are obliged to adapt to our own needs.
After a short meeting of our web team, we identify a few major points that require to be improved :
- connection to postgresql database instead of mysql db !
- infoglue used as back office for our institutional portal (Jasig uPortal) [ex : rss feeder or small web sites with access control ]
- usage of attached documents on a webdav repository (through an extension of the FCKEditor) with access control
- user and group right management consistent with our institutional portal (required by the two last points)
- French localization
- some improvements in the access rights
- better handling in mail sending with publications

Apart the first point which requires a lot of work out of our scope, we propose to help the infoglue community by developing / sharing codes on the the others points.
This implies that the requirements can be discussed and validated by an infoglue community.

Best regards

Hi,

You busy little bees. Mostly great features and yes - we have been awful on reviewing and accepting contributions due to lack of time and organisation. Unfortunately some of the features are now also implemented in V3.
But let's not dwell on the the past - with you obvious competence I would say you have a given place in the committer group and then we can discuss how to merge your branch with the 3.0-version.

Best Regards
Mattias Bogeblad

uibcti wrote:Hi all,
We are a group working at the University of the Baleric Islands (SPAIN) and we would be also interested on working and maintaining alive IG, as our main site, and many others, are already running IG. Just some numbers to clarify:
.- 70+ Repositories/multilanguage sites
.- 4.900+ Sitenodes
.- 55.000+ Contents
.- 31.000+ DigitalAssets
.- 50+ Editors
Running on a Linux SUSE+Tomcat and the DB as an Oracle RAC 11gR2.

In order to do that, some of the things we had to do were:
.- Spanish and Catalan localization
.- Adding the capability to have different templates on each stage (working,live) as properties of the site.
.- Good quality thumbnail generation (PNGs with transparency)
.- Publication control per site, so the buttons to (un)publish are displayed just if the user has the required roles
.- Bulk upload of documents/images though a web form that automatically creates the individual content objects required for each file.
.- Generation of language-aware URLs (adding the language automatically as part of the URL)
.- A filter to access directly the digitalAssets even when they are not linked from any given content (needed to provide direct URLs to downloads, direct access to images...)
.- Modifications to the publishing workflow and the caching sistem (in SelectiveLivePublication mode)
.- Added new functionalities as JSR168 compliant Portal (taking into account PortletModes and per-portlet-instance preferences managent)
.- Plenty of bug fixing

That means we run a moderately modified version of IG running, as our previous attempts to contribute back some of our work/fixes/improvements just seemed to go pipe to /dev/null . I have to admit that this situation had us a bit worried regarding the upcoming? 3 version as we were facing the lose-lose choice between re-implementing all of our changes again in the new codebase or keep our own codebase based on version 2. None of them really appealing.

That's also we are happy to see something done about the community and we would probably voluntteer on points number 2 & 5 (GUI and core development) as that's where our main expertise lays.

We also agree that IG seems to be, for good or bad, quite unique in the CMS market and in part that's why we chose it. I'm not sure how the dual licensing would work in this case as it has its own set of drawbacks, depending on how you apply that. OpenCMS, for example, has the commercial part "just" as extensions to the core, because dual-licensing the core is tricky bussiness if you want to keep a really open community alive. Not that it cannot be done, but it needs to be carefully planned and executed and it will require a company behind.
But that's not a problem just for IG, almost all open source projects that cross the "enterprise" boundaries need to face that decission sooner or later. The more sucessful, the sooner .

Anyway, we just wanted to say that we are commited to IG and that we'd like to help it move forward., so that would be it for now.
S!

PD: Congrats on your kid, Mathias, mine is 20 months in 2 days so I know the kind of fun you are talking about .

Hi Stefan,

Impressive setup - may I ask which organisation you represent? Mail me privately if sensitive (mattias.bogeblad at googles mail service).

I don't want to see InfoGlue dead any more than you do and I'm sure we can find a really good spot in the core team. Perhaps lead on the GUI-side? The version 3.0 RC1 is coming up and the GUI is totally remade allready but I'm not the best GUI-developer and I'll be happy to get help.

Regards
Mattias Bogeblad

Stefan wrote:We started to use Infoglue for large scale installations in the end of 2009. The message we got when we contacted Mattias and the others was that there was no indication of these upcoming problems. We developed a setup of 240 sites in 127 languages and it has become huge. The reason why we chose Infoglue was simply that it was and still is the absolutely best large-scale CMS on the market. We also looked at the commercial ones and Infoglue could definitively compare itself with the best ones and the architecture of it is more promising than any we have seen.

We are definitively interested to contribute. Especially to protect our investment.

We see one weak side with Infoglue and that is the administrative user gui. I guess we could contribute to make it more ajax/javascript and less page oriented. Additionally, we could contribute with the design of the architecture. If that goes well, we might set off one or two more programmers.

We need further directions how to go on from here!

There is no way to see Infoglue dead in any means!

Stefan

As we are closing in on a Infoglue 3.0 RC1 we want participants to our beta program.

If you are interested follow this link for more information

http://www.bogeblad.se:8087/infoglueDeliverWorking/infoglue/en/Developers/InfoGlue_3.0_Beta_program

bogeblad wrote:1. Are you willing to share the role of code/commit approver? I.e. can you accept that code is checked into the main branch of IG without your explicit knowledge?
YES - especially if #2!

Great! Yes, if we switch to git (or something similar) and use a good hosting service, contributions will be very much easier to track and accept.

bogeblad wrote:2. Would you consider moving to git for source control?
YES - in the process actually - any input on which hosting service we should use?

My (somewhat limited) experience is with github, and I like their extremely simple way of branching repositories and merging back changes.

A quick search comes up with at least one alternative though:
gitorious - has a system for requesting merges from downstream and hosts such notables projects as Qt and OpenSUSE.

Both are free for open source projects.

bogeblad wrote:3. How do you see Modul1's role in the community in the future?
No idea.

OK, thanks.

bogeblad wrote:4. Do you run infoglue.org?
Yes - but I probably want others to help depending on my decisions ahead.

Great, at least I like if it is in the hands of the community (even if that is only you

) and not some other entity.

bogeblad wrote:5. Would you consider getting the community work going by allowing some trusted users in as admins on infoglue.org (as the site is sadly outdated)?
No problem - i'll be glad to hand some accounts out.

OK!

Thanks for you answers.

One thing to think about before opening to others commiters is to define code convention.
It would be cool to have a code formatting convention (with eclipse, you can easily define this file and share it with others) : for example eclipse default formating + 200 character line wrapping ...
After having this convention, we could enable formatting on save (automatic save actions).
We also could use automatic save action to automatically organize imports.

Eclipse is great to format java, css and xml file (not that much on javascript / html).

That way, we could have the same base files at start and if 2 people work on the same file, there won't be any formatting conflict.

It's a one-man job to that and it's not that difficult with eclipse.

One great thing would be to use some tool like checkstyle and simple rule like "how to manage log : no system.out, use commons log" ... It would be a step toward clean code and automatic reporting if we move to continuous integration.

This message was edited 1 time. Last update was at 11/01/2011 08:45:51

Hi Astik and Peter,

I actually allready moved a few projects (eclipse ide and my branch of infoglue 3.0) to github after some investigation. Perhaps not the best in all respects but with most momentum currently and free for public projects. I'm going to try it out.
I think astik has very valid points and the time to really restructure the work/environment is now. Checkstyle is a must and perhaps there are other tools we can use also default. I would also like a discussion on build / dependency management / continuous integration etc. Our ant-scripts are working but we will need to write new ones for new types of build (I have several in mind) and perhaps now is a good time to go Maven2 or Ant+Ivy or something else.

Also - the community (www.infoglue.org) is currently running on a very old pc at the mercy of tripnet.se which has been great to us. But if we are going to do this more professionally I would propose securing financial muscles to at least rent 2 servers on the amazon cloud or similar. One for the new community and one for a good demo-environment which InfoGlue still misses and which makes use very hard to evaluate and compare. If anyone could take the lead on configuration management I will promise to listen this time.

On a earlier subject: I'm still not ready with my own thought on how to continue with Infoglue. I find it hard to work hard with it on my prescious spare time unless I find some business model around it. I hope to find some way and I'll let you know soon what I decide.

Best Regards
Mattias Bogeblad

astik wrote:One thing to think about before opening to others commiters is to define code convention.
It would be cool to have a code formatting convention (with eclipse, you can easily define this file and share it with others) : for example eclipse default formating + 200 character line wrapping ...
After having this convention, we could enable formatting on save (automatic save actions).
We also could use automatic save action to automatically organize imports.

Eclipse is great to format java, css and xml file (not that much on javascript / html).

That way, we could have the same base files at start and if 2 people work on the same file, there won't be any formatting conflict.

It's a one-man job to that and it's not that difficult with eclipse.

One great thing would be to use some tool like checkstyle and simple rule like "how to manage log : no system.out, use commons log" ... It would be a step toward clean code and automatic reporting if we move to continuous integration.

This message was edited 1 time. Last update was at 11/01/2011 08:46:11

bogeblad wrote:Hi Astik and Peter,

I actually allready moved a few projects (eclipse ide and my branch of infoglue 3.0) to github after some investigation. Perhaps not the best in all respects but with most momentum currently and free for public projects. I'm going to try it out.

We have tried to clone the infoglue repository and so far so good. We are using Mercurial as distributed SCM but Git should also be fine. Having a distributed SCM instead of CVS/SVN would at least help all us maintaining our modifications without having to deal with a secondary SCM, which is great.

bogeblad wrote:I think astik has very valid points and the time to really restructure the work/environment is now. Checkstyle is a must and perhaps there are other tools we can use also default. I would also like a discussion on build / dependency management / continuous integration etc. Our ant-scripts are working but we will need to write new ones for new types of build (I have several in mind) and perhaps now is a good time to go Maven2 or Ant+Ivy or something else.

If I had to choose, I would start with Ant+Ivy as moving to Maven is quite a move for a project like InfoGlue. Not that it cannot be done, but, for example, Maven "forces" you to have just one artifact per module, so just seeing that the InfoGlue project produces at least 4 artifacts (.jar, .war files) that means you need to start dividing the module in submodules... It can be done but I would do it step by step, once you have introduced the concept of dependency management etc. Maven is nice if you adapt to the way it works, so IMHO, it takes a while until you give in the way you were doing things and adapt to it, if you want to.

On a side note, I had to add a couple of modifications to the build script as starting from scratch, the compiler has to process 1.283 files at once so it runs out of memory :). I have experience with Ant + Ivy so I can have a go at it, if you want. I also have some experience with Maven, but not as extensive so I'd rather leave that for a more experienced Maven-guy. It would also be interesting to split the building properties to have the common one and the per-developer ones separated.

Regarding code style etc. I agree with would be nice to have it all automated, using checkstyle, findbugs etc. to normalise the code. Formatting seems to be a bit tricky, as the ones that I used to use either have gone commercial or are now abandonware. We might also try to use Eclipse command line to format the files, as it is explained in this message (http://blogs.operationaldynamics.com/andrew/software/java-gnome/eclipse-code-format-from-command-line.html) but it is a bit old so I'm not sure if it's still possible or how.

Cheers and happy new year!
D.

This message was edited 2 times. Last update was at 11/01/2011 08:46:21

Has anyone used Apache BuildR? Is it an option? Perhaps we should move this discussion to another thread? Peter J - can you set up a new area for build / tools - discussions?

Regards
Mattias Bogeblad

uibcti wrote:

bogeblad wrote:Hi Astik and Peter,

I actually allready moved a few projects (eclipse ide and my branch of infoglue 3.0) to github after some investigation. Perhaps not the best in all respects but with most momentum currently and free for public projects. I'm going to try it out.

We have tried to clone the infoglue repository and so far so good. We are using Mercurial as distributed SCM but Git should also be fine. Having a distributed SCM instead of CVS/SVN would at least help all us maintaining our modifications without having to deal with a secondary SCM, which is great.

bogeblad wrote:I think astik has very valid points and the time to really restructure the work/environment is now. Checkstyle is a must and perhaps there are other tools we can use also default. I would also like a discussion on build / dependency management / continuous integration etc. Our ant-scripts are working but we will need to write new ones for new types of build (I have several in mind) and perhaps now is a good time to go Maven2 or Ant+Ivy or something else.

If I had to choose, I would start with Ant+Ivy as moving to Maven is quite a move for a project like InfoGlue. Not that it cannot be done, but, for example, Maven "forces" you to have just one artifact per module, so just seeing that the InfoGlue project produces at least 4 artifacts (.jar, .war files) that means you need to start dividing the module in submodules... It can be done but I would do it step by step, once you have introduced the concept of dependency management etc. Maven is nice if you adapt to the way it works, so IMHO, it takes a while until you give in the way you were doing things and adapt to it, if you want to.

On a side note, I had to add a couple of modifications to the build script as starting from scratch, the compiler has to process 1.283 files at once so it runs out of memory :). I have experience with Ant + Ivy so I can have a go at it, if you want. I also have some experience with Maven, but not as extensive so I'd rather leave that for a more experienced Maven-guy. It would also be interesting to split the building properties to have the common one and the per-developer ones separated.

Regarding code style etc. I agree with would be nice to have it all automated, using checkstyle, findbugs etc. to normalise the code. Formatting seems to be a bit tricky, as the ones that I used to use either have gone commercial or are now abandonware. We might also try to use Eclipse command line to format the files, as it is explained in this message (http://blogs.operationaldynamics.com/andrew/software/java-gnome/eclipse-code-format-from-command-line.html) but it is a bit old so I'm not sure if it's still possible or how.

Cheers and happy new year!
D.

This message was edited 1 time. Last update was at 11/01/2011 08:46:33

uibcti wrote:
Not that it cannot be done, but, for example, Maven "forces" you to have just one artifact per module, so just seeing that the InfoGlue project produces at least 4 artifacts (.jar, .war files) that means you need to start dividing the module in submodules... It can be done but I would do it step by step, once you have introduced the concept of dependency management etc. Maven is nice if you adapt to the way it works, so IMHO, it takes a while until you give in the way you were doing things and adapt to it, if you want to.

In maven you've got the "maven overlay" feature which is quite pertinent in our case.
You can begin by defining only one module containing all files from actual project. Then you can define 4 other modules, depending onthe first one and redefining only the specific part.
I've done a maven module separation of infoglue months ago. Maybe I can see if it still fits with actual infoglue. If I remember well, I sent a demo of this to Mattias.

This message was edited 1 time. Last update was at 11/01/2011 08:52:54

bogeblad wrote:Perhaps we should move this discussion to another thread? Peter J - can you set up a new area for build / tools - discussions?

I suggest you start a new thread in the subforum "Developers/Core Development", named something like "What build tools should we use in the new InfoGlue" (or whatever

).

I edited the last 3 or 4 messages, btw. BB Code was off and that made all quotes ugly. I hope that was OK.

Hello again,

I wanted to post some datails of our IG install before but it was quite complicated these days. We are users of infoglue since a long time. We are on 2.9.6 now Here we have about 100 repositories (sites/microsites) and more than 100 users campus wide. Many of the sites are multilingual as we have two official languages here. IG let us to scale to a distributed model around the campus. Even today, few other tools (if any) would let us do similar things.

Our IG installation has:

- Multilingual using just the core IG, without modification.
- Integration with web services (to connect to ERPs)
- Integration with Nutch as search engine
- Integration with Bedework (campus calendar)
- Spanish localization.
- Some customization work to improve notification of page changes to a group of coordinators
- Oracle

We have made any source modification (actually, we avoided it) and we ever try to run the official code, as we do in other open source we have. Unfortunately we cannot collaborate on developing source core, but we would do our best to help on other tasks (as #1 in the list Mattias said)
Regards

Carlos
Public University of Navarra

bogeblad wrote:

What we need to be able to work towards a valid community:
1. 2-3 Information managers (people who keep the website up2date, answer questions on forums, register infoglue on index sites, writing about IG on other sites etc).
2. Configuration manager (resposible for a maven/subversion setup for example)
3. 1-2 GUI-developers (javascript, html, css)
4. 1 Designer
5. 3-x ACTIVE core developers
6. A steering committé of 4-5 persons

I'd say we would probably have to add some Quality Assurance to this list. We are starting to to build an organization of testers and applying a test strategy to our local installation at umeå university. Since we already have a strong tradition of methodical, professional testing in other systems and areas inhouse, we firmly believe we could contribute a lot in this area. Not necessarily on a voluntary basis but as part of our local campaign in quality assuring our installation. 3.0 will be evaluated for local purposes as well. But as we all know: Local is Global!

janbidner wrote:

bogeblad wrote:

What we need to be able to work towards a valid community:
1. 2-3 Information managers (people who keep the website up2date, answer questions on forums, register infoglue on index sites, writing about IG on other sites etc).
2. Configuration manager (resposible for a maven/subversion setup for example)
3. 1-2 GUI-developers (javascript, html, css)
4. 1 Designer
5. 3-x ACTIVE core developers
6. A steering committé of 4-5 persons

I'd say we would probably have to add some Quality Assurance to this list. We are starting to to build an organization of testers and applying a test strategy to our local installation at umeå university. Since we already have a strong tradition of methodical, professional testing in other systems and areas inhouse, we firmly believe we could contribute a lot in this area. Not necessarily on a voluntary basis but as part of our local campaign in quality assuring our installation. 3.0 will be evaluated for local purposes as well. But as we all know: Local is Global!

I agree 100% and I probably left out some more roles in my short list but the point is we need more people and the question is how. Not many these days will come with the intention to do this as a hobby. Perhaps some but I think commitment from organisations like your own which has a self interest in getting a better platform and a future-proof platform by being able to influence it is the way to go. Perhaps we can get a few enthusiast in the mix but at least 50% needs to be in this with some kind of finansing. Either consultant firms like Modul1 / KnowIT / Other or users of the system who do inhouse projects on their own.

I have stated this many times now to different people but the need for a coordinator of all activities is vital and if we don't get something like that finansed somehow I don't think there is any future in the community and I will not commit to it anymore. The reason the current community exists and the platform is what it is today is because of thousands of hours on my free time just working with releases, website, documentation, non customer related features and much more. I know it sounds much but I have actually kept track of a couple of years work and it takes a lot time to keep a piece of software together. On top of that many more thousands of hours have been put into features and websites paid for by customers like yourself.

I would like to get in contact with all organisations who wants to participate in a constructive dialog on how we can build a realistic community together. Both financed, planned and executed together. Some organisations may only want to sponsor the work to make sure work is done and some will want to participate / commit also and both are fine.
Jan - can you look internally if there is a interest in being part of the discussion and if so who I can invite. Mail me at my personal address if so. Anyone else interested in securing the future of Infoglue mail me also.

Regards
Mattias Bogeblad

jaric wrote:With a little insight in what's going on, my guess is that 3.0 will not be ready for use any time in the close future. I will happily hear something else from any of the Modul1 guys, though!

The main developer of InfoGlue, Mattias Bogeblad, has quit Modul1 to work for another company. I do not know if he will carry on working with InfoGlue there or not, but I am sure it will affect the future of IG, and in particular 3.0.

I don't know .