OpenEMM Support

[maschoff]

... to be served in the future?

1. Just a tarball with directories and files?
2. Project for Eclipse
3. Web project for MyEclipse
4. Something else

Please tell us!

[skoehler]

1. i would like to have access to a CVS/SVN repository. This makes it easier, to generate patches against latest version etc.

2. I like Eclipse very much. If Eclipse is used, i would suggest not to depend on too many 3rd party plugins. Eclipse + WTP + CDT + PyDev should do. Also configure the Eclipse-Project properly. Most settings can be done per project and stored in the project-folder and committed to CVS/SVN. Set a file-encoding for the project, set the compiler-settings for the project etc. - maybe even configure the code-formatter the way you like it.


(And if you configure the project's compiler settings, i would ask you to turn on all warnings that you consider usefull - like warning for unused code, coding style etc. - that will improve code-quality)

[nviraj]

Hi,

A Project with Eclipse will be highly appreciated.

Regards

[porkiey]

Agreed - SVN would be very helpful!

[maschoff]

We plan to setup a SVN repository with read access for everybody (and write access for committers) after the release of OpenEMM 5.5 in May.

[elecnix]

To keep track of local changes, I would favor Git over SVN or CVS.

http://git.or.cz/

[rvullriede]

Hi,

Is the svn repository already available?

Regards,
Raphael

[maschoff]

Not yet, because we decided to do a big refactoring for OpenEMM 6.0 to introduce a modular architecture which offers the possibility to write extension modules for OpenEMM (planned release date: February 2009).

Our concern is that any changes in the code base before this refactoring would have to be rewritten.

[elecnix]

Git allows developers to make local commits and easily maintain a private development branch. I have imported all OpenEMM releases into a public Git repository on GitHub:

http://github.com/elecnix/openemm

It is not as good as a SVN import, since it doesn't show individual commits, only releases. The master branch contains the current latest version: 5.5.1, but you may checkout and compare any older version among:

OpenEMM-5.0.0-RC2
OpenEMM-5.0.0-RC3
OpenEMM-5.0
OpenEMM-5.0.1
OpenEMM-5.0.2
OpenEMM-5.0.3
OpenEMM-5.1.0
OpenEMM-5.1.1
OpenEMM-5.3.0
OpenEMM-5.3.1c
OpenEMM-5.3.2
OpenEMM-5.4.0
OpenEMM-5.5.0
OpenEMM-5.5.1

[mkalen]

Please tell us!

Some kind of source control is a must! Be it CVS, SVN or Git - the choice is not so important. (Eclipse support is better for CVS and SVN today but this will change as more and more people adopt Git and the Eclipse plugin gets better.)

The project is already on SourceForge, would not the natural place for the source code be a repository on SF? I was spending some time today (confused by the new SF.net look) just to finally realize that you do not publish the code there! This is really strange for an open source project in my opinion.

I expect to be able to create patches to send to you when I find faults in the product. To do this I now had to download a tarball with the source, unpack in two different directories, make changes/rebuild and test in one directory and then use a shell script to diff against files in the untouched directory. Not exactly productive...

SF.net has the infrastructure and the tools for access control etc. so you would not have to re-invent the wheel if you put the source there.

Regards,
Martin

[maschoff]

After release 5.6 (scheduled for February) we will do an internal fork and put the 5.x code in an open SCM. Since the 6.0 branch involves heavy refactoring its state will only be published at release time.

[chumpster]

It's now June... I wonder if there's any word on v5.6 or 6.0?

thanks....

[mkalen]

I wonder if there's any word on v5.6 or 6.0?

It seems the OpenEMM Twitter channel is more up-to-date than forum/website. Check it out here for some info from Agnitas:
http://twitter.com/openemm

[maschoff]

Or check out our public roadmap at

http://www.openemm.org/roadmap.html

[anondev]

Another idea would be switching from Ant to Maven (3?) for builds/dependencies/tests/configuration. You would gain much flexibility there, and efficiency.
Have you already considered it?