Felix Console for iDempiere OSGi Bundles

ADempiere is now on the OSGi platform of the Equinox kind, but Apache has an OSGi platform called Felix that has a cool GUI web-based console for installing and managing the plugins and bundles in the running application.

This cross marriage of a sister technology onto iDempiere's Equinox framework is done by Low Heng Sin and you can get more into the source to see how its done.

I know of this before while looking for an installer control panel that is GUI-like and found out to my dismay that it exists not in Equinox but Felix. So when I brought it up to him, during lunch some weeks ago, he told me that he's been tinkering with it but it was not ready. He wanted to implement it without any modification to the Felix code so as not to fork or break from it, as that will entail further maintenance in future.

So I was very excited when in my next lunch meeting with him he told me it is now done, and committed. I went home trying to make it work but couldn't at first due to some new plugin fault. Once that was cleared I could get it up by accessing it via :/osgi/system/console/

You have to ensure the two felix bundles are present and in resolved mode:

266    RESOLVED    org.apache.felix.webconsole_4.0.0
267    RESOLVED    org.apache.felix.webconsole.plugins.memoryusage_1.0.4

The browser should show:

In the third menu bar from the top, you can find a install/update button. Pressing it pops out a dialog box for you to choose the bundles that you already have stored in your own computer.

 

 This means you have to download those bundles first. The next cool thing is that you can install en masse multiple bundles at the same time and tick them to start off right away.
Of course for the plugins I converted such as POS Integration, Asset Maintenance, WithHolding Tax and HR Payroll, they contain database model changes which need to start in consecutive manner.

That can be done when the bundles appear in the stack. On each row of displayed bundle there are control buttons on the right to start, refresh and even discard them.

This is what I meant when I started looking for such a panel before this. A dashboard that is more modern and user-friendly than the techie OSGi console that requires repeat 'ss' to refresh the bundle stack.

As usual, I made a movie about this:

 

ERP Software Marketplace with P2 sites

Finally yesterday on a marvelous date of 12.12.12, I pulled off what I will call the greatest trick out of the hat of Open Source Software for the ERP marketplace. We can now publish and distribute 3rd party ERP features or plugin modules in a decoupled manner via the use of Eclipse P2 or Provisioning Platform.

With your iDempiere installed, you can just run a short script in your idempiere-server to pick up a sample plugin ready to run on the fly here:

java -Dosgi.noShutdown=false -Dosgi.compatibility.bootdelegation=true -Dosgi.install.area=director -jar plugins/org.eclipse.osgi_3.7.*.jar -application org.eclipse.equinox.p2.director -consoleLog -profile DefaultProfile -profileProperties org.eclipse.update.install.features=true -repository http://downloads.sourceforge.net/project/red1/p2/POSIntegration/ -i POS-Integration.feature.group

And upon running the app, a new module in total functioning order magically appears.

Total functioning order means the DB model changes are applied via 2Pack, and the processes usable via OSGi extensions declared within the plugin. Testing it proved their working as well as the dependent jars of the core project and ActiveMQ tooling.

For more details, visit my forum posting or read the complete tutorial to develop such a plugin from start to end.

(Epilogue) I made a movie on how this can work in a 'hot running' mode:

 

Is ADempiere set for another War?

I hope not. But i cannot make reports like this in my mailbox go away. I just want the guys who took over from us to practice some decency and due process of law. I know they are busy in making money out of our FOSS ERP project just like I am too.

But there must be a clean and fair process for all as it is a community project and not some club of vested interests. Am i correct? I don't know. You have to prove your innocence by coming out clean. 'It is not enough that justice be done but must be seen to be done.' goes the famous legal saying.

You can read further up the link above how another member of the community (non-voting rights given for going against the regime) has lodged a complain to SourceForge.net Community Manager and they are asking back what can be done to help.

Again, i don't know and i don't really care as the iDempiere project is blooming fine away from such filth. In fact i rather let such filth stays there and not bother us.

But that is been unfair and cruel to so many users since 2006 that has invested in ADempiere and now has a dilemma of reselling a new name or project to their stakeholders.

Do i care? No, because the project has grown beyond me. It is a collective matter. The whole community including the other side must sit in, smoke it out and reason with reason.

Everything on iDempiere is Here

This latest fork of the Compiere family captures my imagination because it attempts to use the Eclipse framework of Equinox OSGi and quite cool stuff from there such as Buckminster instead of Maven, P2 to publish new code changes for automatic online access by remote users. It also blows me away on how real components can exist for scalability and better features of software technology.

The following are links to anything and everything you need to know about the iDempiere project:

This googlegroup is for users of iDempiere ERP to forward feedback on its performance.
To report any confirmed bug please do so at http://jira.idempiere.com.
You can monitor its development progress at http://jenkins.idempiere.com.
You can check out its sourcecode from its http://bitbucket.org/idempiere/idempiere twitted at http://www.twitter.com/idempiere.

For best growth of the project and community, keep comments in the open also at the following places:
You can document your experience in a structured way and in different languages at http://wiki.idempiere.org/
If you wish to visit a general old buletin board you can try http://red1.org/adempiere
Or have a chat at http://webchat.freenode.net/?channels=idempiere
If you are a Facebook fan, you can keep track at https://www.facebook.com/groups/adempiere/ 

Do not take my word for it. Go check iDempiere today and see if it is a better place for Free and Open Source ERP applications.

Openbravo POS integration as an OSGi Plugin Sample

With iDempiere long awaited alpha release, I have set upon to create a sample OSGi plugin to use on the stack, or at least prove the concept works. I managed that with my old Openbravo POS Integration and written out a piece with 3 in 1 value:

1) Show that you can easily create your own plugin for your old module from ADempiere/Compiere into iDempiere;

2) Show that you can Pack Out and Pack In via the META-INF location and Activator code;

3) POS Integration upgraded for iDempiere use.

I am using Eclipse Juno version in a Windows 7 environment. The following youtube movies tell the whole story:
 A) Packing Out

B) Creating the new plugin

c) Packing back in

Next down the road, is to show how to deploy this to your binary or application home using P2 and Buckminster tools. Further, we will try to convert the LCO (Localization Colombia) of Carlos Ruiz into 3 plugins packaged in a feature and well documented in a PDF guide for others to design or migrate their localizations accordingly.
I have also written a PDF guide for the above in my good charming whacky way.
My works are presently sponsored by SYSNOVA of Bangladesh to whom I owe much gratitude.
(Note: The plugin is now deploy-able remotely)

iDempiere Windows Installer

It was last August that i upgraded our ADempiere Windows Installer, but last few days i been working feverishly to upgrade it to work on iDempiere, our ADempiere on plugins, bundles or technically known as OSGi, supported by IBM's Equinox, the same that Eclipse IDE is based on.
I wrote a whole 17-page tutorial guide on it with two pages more squeezing my 5 month incredible journey through Europe and South America recently into it.
Again i reuse the NSIS scripts but this time i have to tackle the silent setup which is tricky here as now i try something new - passing a StdIn file as input to a proper console setup batch program. But there is some trick to the quotes format and after googling around i found it has to be like:

' "$INSTDIR\console-setup-alt.bat" < $INSTDIR\StdIn.txt '

The StdIn has to be saved in Windows format as my earlier creation of it in my Mac refused and refused to work. But when it does, it is simply amazing this NSIS.
Another thing i learnt is how oname is used. It is like a proxy handler but also where you move your source files around to the installer directory for easier handling or execution.
One big headache i had was to make another batch program run at a relative directory path. Again i suspect because the file is not created originally in MS mode. But i tried more Dos commands in it to debug and display where things are such as @dir and to see if the environment variables are working with

@echo %ADEMPIERE_DATABASE_PATH%

This Windows non acceptance of Mac created format is irritating. I did know the format issue before because i hit the same in Krefeld, Germany but am too lazy to google for the answer. I just do the long way by recreating again the text files in my Windows PC. Even my image bitmap files have to be re-exported in Windows. But i wished NSIS accepts smaller size JPEG files instead of insisting only on BMP.
Otherwise I must praise NSIS again. It works like a charm. Yes there is a learning curve when things do not work and Googling takes long hours to trace of any similar experience and solution from others.

ADempiere on OSGi is by itself amazing. This new vast improvement by Low Heng Sin assisted by Carlos Ruiz is lighter, smaller and faster. It needs less setup and its console interrogation of its active bundles via the 'ss' command in its terminal windows gives you a sense of control over the application's innards. However sometimes the lazy bundles takes longer or really long time to wake up and i am often left unsure if it is my fault in the installer when all i need to do is to copy over the really working OSGi plugins and setup and import database.

I maintained the same song into this installer but with the other acoustic version Mellow Mark first arranged in Potsdam.
This time i found a friendly German blond from my recent travels, while passing through Bavaria country, to fit the cover image of the installer which i used as background throughout the installation process. Amazingly she is so caught in by this whole Open Source travel experience i am passionate about that she is joining me this August as an intern for 6 months. I hope to bring her to some really exotic Asian spots.
Great things really happen when you are contributing to the world. So build your karma points today by taking this free ERP software and spread the word to save the world from high cost proprietary licensing and non freedom from locked code.
Lastly i must thank my sponsor for this effort, SYSNOVA of Bangladesh. Thus, much of the karma points also goes to them.

iDempiere GWT on Tomcat7

After upgrading to iDempiere GWT, we can deploy it to work outside Eclipse on its own under Tomcat. I did it today with the latest Tomcat 7. But there is a small error in the web.xml's servlet mapping which is:

<servlet-name>GWTLoader</servlet-name>
<url-pattern>/*.html</url-pattern>

That will trap all htmls into the CompiereService extending HttpServlet which hits the illegal super.doGet method giving

HTTP Status 405 - HTTP method GET is not supported by this URL

and does not allow the Entry Point Class to come into effect. By commenting the above away solved it. I found the answer as i thought it was strange that this runs in Eclipse but not out there under Tomcat. Then I remember that the /*.html is an invalid URL pattern to Tomcat and i have to remove the /. So that made me look closer at what it is doing which tells me it is forcing the html calls there. But when i see that the servlet class has a <load-on-startup> i quickly guessed that this html redirecting is redundant and turned it off to allow the entry point class taking over.

To fully deploy, with your Tomcat 7 running, just drop the contents of the war from the project-space under the WebApp folder with any suitable name - iDempiereGWT.

Now, I have made a WarBuilder.xml that creates iDempiereGWT.war to make life easier. Put that iDempiereGWT.war under WebApp with Tomcat 7 running and you will see it extrating itself and appearing in its Manager panel.

All artifacts and a similar tutorial are in the forum. Just base this on your present ADempiere instance. It will look for your present properties files which access your database. Copy your ADempiere.jar and AdempiereCLIB.jar onto WEB-INF/lib and everything should work.

If you do not use your own jars but the ones already given, then your ADempiere instance has to be the latest in my SourceForge. You need to use the database dump given so there be no error as those binary jars has Fixed Assets included.

To go further from here, we probably have to migrate a few more jars from JBoss to Tomcat, such as those that handle Accounting or Java WebStart deployment. If you know something that i don't do drop me a line and whatever help it maybe the community will be equally grateful.

(The Russians have joined in by donating a bunker here http://demo.idempiere.info/iDempiereGWT/)