|Date||6th May 2012, 1300 CET|
|Participants||Peter Gorm Larsen, Sune Wolff, Augusto Ribeiro, Kenneth Lausdahl, Joey Coleman, Nick Battle, Nico Plat, Marcel Verhoef|
The action item list is maintained as a tracker on SourceForge.
No change to items this time.
The title is “VDM++ specification as structured Japanese Requirement specification”
I have to teach Overturetool and VDMTool.
Changed “old” variable processing for postconditions to copy only affected state. This is more efficient and corrects a problem found with accessing old-inherited state. Corrected pattern handling for empty sequence/sets.
The parser and type-checker were synched with VDMJ. Next steps are implementing the test framework that thoroughly tests the parser and type-checker and start the interpreter implementation.
VDM 2 UML translator
The VDM 2 UML translator is in process of being changed to use the ASTv2 parser.
4 RMs presently in Discussion, but need more consideration.
Source code in Git
The entire Subversion repository has been migrated to Git on sourceforge, and a page explaining basic Git usage is partially written at Using Git. The devs at IHA have migrated their work, however, configuration of Nick Battle’s setup is unfinished. For the moment it is possible to synchronize between the old SVN repo and Git (but this isn’t a great long-term solution). Part of the push to shift to Git has to do with the proposal for the Release Process, below. Joey is available –as time permits– to help assist anyone who needs to transition their build setup.
Release Process proposal
This is a proposal, comments desired — this will be written up into a wiki page for comment before the next core netmeeting
Note that one of the strongest features of Git is its handling of branches –parallel streams of development– both ‘cheaply’ and with clearer history tracking as compared to Subversion. Branches are not reflected in the file structure of the repository, but rather as names pointing to specific version in the history.
The Git master branch now has a maven configuration such that mvn install in the project root will now properly compile the Overture source. Further, mvn eclipse:eclipse (mostly) does what we expect and gives us an environment that we can use for development. Version number increments can now be done in a very small handful of places, and can be automated with a small number of commands (which are documented in the repository). We are able to compile a working version of the tool that we’ve tested on Windows and OS X.
One major change resulting is that we now depend on maven 3 for the build of the IDE portion of the source tree. We’ve not yet investigated how much effort it would be to make it work with maven 2; feedback would be welcomed as to whether this is necessary (for new developers, probably not; the question relates more to present needs). As far as we are aware, maven 2 still works in the core portion of the source tree.
The development pages on the wiki will be updated soon, in light of both the transition to Git and the update to the maven setup.
Action for all: feed back on necessity of Maven 2 to Joey
https://sourceforge.net/tracker/?func=detail&aid=3438625&group_id=141350&atid=1127184 RM 3438625 has been added to the Release Planning document, but it remains unscheduled for the usual resourcing reasons.
Present situation is confusing — we have a number of mailing lists in different places, and their purposes aren’t clear. Also, the ‘correct’ way of getting in touch with the community is not presently clear.
Nick Battle to take an action (62/1) to summarise current state and propose a better state of affairs.
Discussed, see Planned Publications.
Overture Workshop at FM2012
Hoping for more submissions at the moment, we may have to consider some changes in the plan for the day.