Group items tagged

TouchKit allows developers to make applications that look and behave like iPhone applications using only Vaadin. This add-on is available under two licenses: AGPL and CVAL. If your project is compatible with AGPL, you can use the add-on for free; otherwise you must acquire a sufficient number of CVAL licenses before the 30-day trial period ends. For more info, click the license links in the summary above.

Acceleo is a pragmatic implementation of the Object Management Group (OMG) MOF Model to Text Language (MTL) standard. You do not need to be an expert to start using the plug-ins and create your first code generator : using the provided example projects and the powerful completion feature of the Acceleo editor, it is very easy to get started and understand the basic principles.

The aim of this paper is a brief introduction to MDA technology and a summary / comparison to the approachments to MDA of AndroMDA and Acceleo, intending to be a practical and understandable summary Introduction Model-driven architecture (MDA) is a software design approach for the development of software systems. It provides a set of guidelines for the structuring of specifications, which are expressed as models. It was launched by the Object Management Group (OMG) in 2001 The Model-Driven Architecture approach defines system functionality using a platform-independent model (PIM) using an appropriate domain-specific language (DSL). One of the main aims of the MDA is to separate design from architecture. As the concepts and technologies used to realize designs and the concepts and technologies used to realize architectures have changed at their own pace, decoupling them allows system developers to choose from the best and most fitting in both domains. The design addresses the functional (use case) requirements while architecture provides the infrastructure through which non-functional requirements like scalability, reliability and performance are realized. MDA envisages that the platform independent model (PIM), which represents a conceptual design realizing the functional requirements, will survive changes in realization technologies and software architectures.

The default EMF UML2 repository implementation was changed from UML2 1.x to UML2 2.x, in order to support the most current versions of the MagicDraw and Rational tools. Due to conflicting dependencies in the uml libraries, both implementations could not be supported at the same time.

""Coming from desktop application development, I have found the IT Mill Toolkit [Vaadin] to be a lot of help in the transition to web application development. With the toolkit, writing AJAX enabled web applications is as easy as writing Swing based GUI code. It hides so many frustrating details, and handles browser independence so I don't have to worry about it. Using the toolkit makes it quite easy for me to write sophisticated web applications." Bo Thorsen, Monty Program AB"

Apache ServiceMix is an open source ESB (Enterprise Service Bus) that combines the functionality of a Service Oriented Architecture (SOA) and an Event Driven Architecture (EDA)  to create an agile, enterprise ESB. Apache ServiceMix is an open source distributed ESB built from the ground up on the  Java Business Integration (JBI) specification JSR 208 and released under the Apache license. The goal of JBI is to allow components and services to be integrated in a vendor independent way, allowing users and vendors to plug and play.

Gaelyk is a lightweight Groovy toolkit for Google App Engine Java. Gaelyk lets you deploy small applications on Google App Engine Java. Gaelyk gives you the choice to use Groovy for developing your applications. Gaelyk builds upon Groovlets. and the Groovy template servlet Gaelyk allows you to cleanly seperate your views with Groovy templates and your actions in Groovlets. Gaelyk simplifies the usage of the Google App Engine SDK by providing more concise and more powerful shortcuts when using the datastore, memcache, the blobstore, the images service, the URL fetch service, when sending and receiving emails or Jabber messages, and much more. Gaelyk lets you define friendly REST-ful URLs thanks to its URL routing system Gaelyk provides a simple plugin system for improving code reuse and code sharing You can: download Gaelyk in the download area, learn how to create Gaelyk applications by reading the extensive tutorial, and participate in the community.

A few weeks back, I wrote a blog entry lamenting the attitude toward IDEs in the Scala community. A few people told me that the tooling situation was better than I'd implied, so I thought I'd spend a bit of time looking at using Scala (and Lift specifically) in Eclipse. I think the situation is still a ways away from the tooling situation for Java, but it is actually quite good, and I wanted to post a quick tutorial for those interested in developing Lift in Eclipse. Prerequisites This post assumes that you already have Scala 2.8 final and Eclipse 3.6 on your system. For Eclipse, I recommend upping the Xmx setting if you haven't already - I had issues when I had multiple Lift projects imported with Xmx set to 386. Also, this tutorial is going to use Maven, not SBT. SBT may be a better build tool for Scala projects, but I'm not sure how well it works with m2eclipse - I'm going to play with that more later. I also assume you know how to install plugins into Eclipse - I will create a more in-depth screencast for doing all of this if there is enough interest.

In this article I'll describe the setup I use to do develop Lift applications. While more heavy-weight than if an interpreted language is used, I find this setup provides fairly decent turnaround times. So, it took a little longer than expected to write this article which continues where the previous stopped. But all good things come to he who waits The software used in the previous article all had major updates in the meantime: Scala 2.8 (2.8.1 is just around the corner) Eclipse 3.6 Scale IDE for Eclipse (though a nightly build is currently needed for Eclipse 3.6) Gradle 0.9 RC1 Lift 2.1 RC2

There was a recent outburst in blogs on the topic of Groovy and how it compares to Java. Although I respect the youthfull entusiasim of Groovy and Co. working on this little exercise I'm just perplexed by the "WHY?" in this whole discussion. Let me just say again: W H Y ?!?! 1. Practically no one cares about Groovy (let alone Groovy++ strap-on) beyond Grails community. So this language just as "widely accepted" as Ruby (at least for enterprise software development) 2. If you know Java it's equally "challenging" to pick up either Groovy or Scala. Don't let anyone insult your intelligence by claiming that Scala syntax is somehow more complex than Groovy. In both languages you will need to adapt to functional thinking - and that's where you will have to spend a couple of weekends… 3. If you know Groovy - you already know 90% of Scala (different syntax and few extra features can be picked up in the evening) 4. Scala is designed by people who have proper academic background, experience and talent in the area of language design - Groovy has never been that way (and anyone who dares to look inside of Groovy runtime or history of changes in it will attest to that). NOTE: it did come out rather strong - but that's how I feel about it and after some thinking I'll leave as is. Nothing personal to anyone reading it… 5. Scala as a post-functional language is years ahead of Groovy (static typing with best-in-business type inference, highly tuned mix of imperative and functional styles, powerful and done-right generics, etc.) 6. Groovy will ALWAYS be slower than Scala or Java (latest benchmarks put even Groovy++ about 50 times slower than Java) just by its nature unless someone changes the language and rebuilds the runtime from the ground up. 7. Once we get decent integration with Eclipse, NetBeans and IDEA for Scala, the Groovy will lose its only serious advantage

Last week I decided to challenge Scala's downscalability by trying to replace a Groovy script with a Scala pendant. In this article you will read about this little experiment and a comparision of the Scala result with the Groovy predecessor. But first some background about the script: Some time ago my company introduced a new spam notification system.  When it thinks that a mail contains spam, it keeps it in quarantine and once or twice a day sends an email to the recipient (me) reporting all the kept mails, together with an intranet web link for each  to release it. Here you see an example of such a mail (note: I have my mails displayed in plain text format):

Legacy systems embrace a large number of technologies, making the development of tools to cope with legacy systems evolution a tedious and time consuming task. As modernization projects face with both technologies combination and various modernization situations, model-driven approaches and tools offer the requisite abstraction level to build up mature and flexible modernization solutions. MoDisco provides an extensible framework to develop model-driven tools to support use-cases of existing software modernization :

Papyrus is aiming at providing an integrated and user-consumable environment for editing any kind of EMF model and particularly supporting UML and related modeling languages such as SysML and MARTE. Papyrus provides diagram editors for EMF-based modeling languages amongst them UML 2 and SysML and the glue required for integrating these editors (GMF-based or not) with other MBD and MDSD tools. Papyrus also offers a very advanced support of UML profiles that enables users to define editors for DSLs based on the UML 2 standard. The main feature of Papyrus regarding this latter point is a set of very powerful customization mechanisms which can be leveraged to create user-defined Papyrus perspectives and give it the same look and feel as a "pure" DSL editor.

The Fornax-Platform is a development platform for tools related to the Model-Driven-Software-Development - MDSD. In this context tools are cartridges, transforms, ready-to-use generators or simple enhancements to make it easier to work in a MDSD environment. Another approach is to provide Howto's and tutorials that simplify the undestanding of MDSD. The Fornax-Platform provides infrastructure and tools to simplify the management and the development of such components and tools. It is independent from companies in this area of software development.

"The Eclipse Modeling Project is one of the most active projects within the Eclipse community. Ed Merks will give a quick overview of the Modeling projects in Helios. Then Cedric Brun will demo Acceleo and Sebastian Zarnekow will show Xtext. This presentation was recorded as part of the Helios In Action virtual conference: eclipse.org/​helios/​heliosinaction.php. Presented by Ed Merks, Cedric Brun of Obeo and Sebastian Zarnekow of itemis "

"The Eclipse Modeling Project focuses on the evolution and promotion of model-based development technologies within the Eclipse community by providing a unified set of modeling frameworks, tooling, and standards implementations."

 As TOPCASED project leader I want to assess the usage of ours Tools in Academic and industrial projects. This assessment will help us and you to assure credibility of the Topcased projects and tools and then to insure their durability.  To do this "state of the art" could you give me back your usage of  TOPCASED Tools : which tool, for which kind of projects (evaluation, industrial, research) and all information you are able to give to us ? Specially for academics could you give me information about the usage of our tools in engineers trainees or thesis : which cursus at which level, number of student already trained, subject of thesis.  If you need some confidentiality on your information, tell me that and I will remains it for my own.   Thanks to send your Topcased usage returns to patrick.farail at airbus dot com  Thanks a lot to help us on this work I will give you back this results by mail.   Patrick Farail from Airbus TOPCASED Project leader 

"Besides a rich user interaction many applications need to display a big amount of data sets as diagrams or reports as part of their applications. In order to bridge the gap the BIRT project was created as part of the eclipse ecosystem. BIRT is an open source Eclipse-based reporting system that integrates with your Java/J2EE application to produce compelling reports. That BIRT integrates well with classic RCP applications is a well known fact. But the need for rich internet applications is still growing. And here the RAP comes into play. As a platform for developing Web 2.0 applications with the same patterns as for RCP it paves the way for single sourcing applications running on both platforms. In this talk we will show how to integrate diagrams and reports known from BIRT into RAP applications. Topics covered include how to setup the environment to let BIRT and RAP play well together. In addition we will give advices how to use the reports inside RAP applications and which problems may arise. As a final outcome of we will know everything to bring reporting capabilities into RAP applications. "

"a simple java reporting runtime, capable of running birt reports on google app engine (gae). "