MPS and continuous integration Follow
Using continuous integration, like having a CruiseControl/Continuum/YourFavourite server check out all code modules, build, run tests and run module integraiton tests every hour is essentially the only way to keep projects larger than 4 developers on track. A precondition for this is that building and testing is fully automated through ant or maven scripts. How does MPS fit into this picture?
I have a feeling that MPS may have a huge potential in enterprise areas like banking, insurance etc where large systems are developed around a somwhat consise domain model/language (what's the difference anyway?). Now, such systems are developed by large teams that use more or less agile and test driven development with continuous integration. (At least the only teams likely to discover MPS are those who are that much in touch with technology trends). At least where I work, it is obvious that if its not possible to build with cvs, cruisecontrol and maven, then it doesn't exist.
Now, how does a graph editing tool like MPS match up to the requirements of "most likely commercial customers's" (my assumption) requirements of being text-based and scripted?
Please sign in to leave a comment.
Well, one thing I forgot: At least with maven, one golden rule is that generated items (code or similar) is never ever modifiable and is never ever persisted between clean builds.
The reason for that is of course to facilitate change everywhere. If you modify generated code by hand and later modify the generation sources, you have to regenerate the gode and lose your manually made changes. So: never ever think that generated is modifiable or persistable (or precious). It should never ever be. Instead, make sure it is easy to generate it again, all the time.
Hello, Eirik,
We used to have ability for MPS models generation during continous integration, but now we don't use it anymore, because you have to spend some to make it work and our team isn't large enought yet to make it a good idea.
MPS is bootstrapped with itself so if we break some core generator and don't have a generated file we won't be able to generate code generated for it that makes it's impossible to use MPS. For some languages of course it is a good idea but for bootstrap ones it isn't.
Thanks for the answer.
To the question of whether or not the code-generation module and/or editor module should be compiled as "source" in a pre-compile step (for use with continuous integration), I guess that depends on the type and use of the language being developed with MPS.
I've noticed that the Java compiler doesn't start by compiling itself. Java is a stable and generic language, and the development of the language is definately a project that is independent of the projects using it, so there is absolutely no need to recompile the compiler as part of all the user-projects.
On the other hand, if you work with XML documents in a "language" defined by a project-specific WSDL, and perhaps also use XMLBeans to generate an "editor" for those documents, you would typically have the WSDL and XMLBeans-generation as a continuously recompiled module along with the other source code. This is because the "language" is definition is part of the project, and moves along with it.
I guess it's all a question of how close the relationship is between the language you are defining and the project you are using the language in. My guess is that generic languages can do without integrating the build of the language tools into the build cycle. Such languages may, however, have little use of more advanced tools than JavaCC (eh, well, it might be a bit easier to use MPS, though :-).
Domain-specific languages will, I guess, be defined along with a project that's using it for some pilot purpose. Therefor, they need to have the language tools built along with the other source code in the project. If MPS targets that kind of use in enterprise environments, I think supporting continuous integration with the language tools is a necessity. At least, it must be possible for a server like cruisecontrol or continuum to compile the project/domain-specific language files and their compiler somehow.
Thanks for your effort, though. MPS is an extremely exciting tool, but you should investigate how to integrate its use in maven2 projects. (and, by the way, native maven2 support in intellij 6.1. would be a really nice feature, too ...).
eirik.
Is it available now to import an MPS language from maven repository into IDEA, modify model and then integrate model compilation into a maven compile target?
You can use build language to describe a build of your languages and solutions and then use generate ant script to run a build on continuos integration server.