Create a ready-to-use executable

[monochromata]

In the long run I'd like to build jact with Maven, so the build can run in continuous integration.

Tycho (http://www.eclipse.org/tycho/, http://wiki.eclipse.org/Tycho/eclipse-repository) might make it possible to create a single executable (or zip file) so users don't have to contact the marketplace after installing a standard Eclipse. This might make it easier for non-programmers to get started with jACT-R.

[amharrison]

I've always wanted CI, but have never been able to invest all the time and energy into setting up the server and then rejiggering all the packages to be both Maven & Eclipse compatible. Have at it.

A jACT-R specific build of Eclipse is actually trivial to do (w/o CI) - but it's utility was pretty limited since some form of development is always necessary for anything but the most trivial models, so you end up installing PDE, JDT, etc. anyway.

But you're right, most people come to this thinking there is a single executable that will solve all their needs.

[monochromata]

We could include PDE and JDT in the executable. AFAIK JDT and Eclipse are also built using Maven.

[amharrison]

Absolutely. Those were poor examples because they HAVE to be included in order for jACT-R to work at all.

When you've got a good handle on the CI server requirements, we can make a proper game plan.

I'll need to see if I have to switch hosting providers, etc.

Another nice benefit of a CI/Hudson/Tyco solution is that I can finally start signing bundles.

I'm for any idea that improves the infrastructure.

[monochromata]

I'm currently running a Hudson instance on my local computer. You might also run one locally or on a server when we get to the point that we can publish stuff. It might be perfectly possible to run Hudson on a computer that is not publicly accessible and just publish the results incl. test and coverage reports to an existing web server (and maybe other repositories like the central maven repository).

[amharrison]

works for me.

[monochromata]

After trying an initial Hudson set-up (http://www.eclipse.org/hudson/) on a smaller project, I'm reworking it to make it run more smoothly and future-proof.

I've got the following in mind for jACT-R continuous integration.

Artifacts that do not depend on Eclipse (i.e. those from jactr and commonreality repositories) will be deployed as Maven artifacts, eventually in Maven Central, so they can be used by interested parties who wish to integrate jACT-R in non-Eclipse projects. An Eclipse update site will be compiled from these artifacts to make them accessible as Eclipse plugins. The artifacts from the jactr-eclipse repository will be deployed as Eclipse plugins / features to an Eclipse update site. An Eclipse product will be assembled and be made available for download from jactr.org.

The current setup of the smaller project already runs the tests, packages and uploads the Eclipse product. I'm still working to get coverage reports for the Eclipse plugins, too.

There will also be continuous delivery, i.e. build and test will be automatic; new releases will be uploaded automatically, if no errors are found during the tests. This means that acceptance tests need to be automated, too. I'll see if SWTBot is a viable option to achieve this.

I'm interested in using semantic versioning (http://semver.org) and to assign version numbers based on commit comments. E.g. if a commit starts or ends with +minor and the current version number is 1.2.0, the minor number will be incremented automatically during the build, resulting in a new version 1.3.0. If no +major or +minor is included in the commit comments, the patch number will be incremented (i.e. 1.2.0 -> 1.2.1). Continuous integration will be triggered by invoking a URL pointing to the job configured in the Hudson server, or by having the Hudson server poll Github for updates.

Would you be ok with this approach? Any suggestions? (Continuous delivery would actually mean that we need to work test-first.) How are you currently doing the acceptance tests for a new release? Do you have a small fixed set of steps that you perform manually or do you check that old / new functionality works?

[amharrison]

In general this looks like a good plan of attack. There is a little bit of eclipse code in io that should be moved out - but otherwise this shouldn't be a problem.

Let's please make these changes on either a completely separate repo or on a branch until everything is solidified.

[monochromata]

The tags I created in your repo were due to my misconfiguration of Maven. (I pointed the part that is supposed to tag the release to your repository, but checked out from my repository. It's fixed by now.) I will do the Maven changes in my repositories, i.e. https://github.com/monochromata/jactr/ etc.

[monochromata]

A short status update: I'm roughly done with putting CR into a Maven structure. I'll add a project that makes the CR Maven artifacts available via an Eclipse update site, too (so they can be used in jactr-eclipse). Next I'll do the same for jactr.

[monochromata]

What is left for CR is to update the version number automatically and to generate features. I'll switch the build to a Jenkins server than runs in a Docker container so it's easy to set up the build consistently on different machines.

I'm getting closer to have jactr in a state similar to CR and will start working on jactr-eclipse within the next days.