YOU WANT

Beautiful, flexible, functional Desktop Software.
The Freedom to use, share, and modify your software.
Full control over your data and privacy.
All This and more isdone by KDE.

Become a supporter of KDE

A  timelines of Google’s acquisition, really beautiful!

Research by Scores.org

Frœningen fait partie du canton et de l'arrondissement d'Altkirch. Le village est situé entre Mulhouse et Altkirch. Le banc communal de Frœningen a une superficie de 440 hectares dont 63 hectares de forêt communale.

Histoire

L'occupation des terres aux alentours de Fræningen semble ancienne. Un cimetière mérovingien et une voie romaine, à la lisière sud-ouest du territoire ont été mis au jour. Le village faisait partie des comtes de Ferrette,descendants de Charlemagne qui règne sur l'ensemble duSundgau qui y construisent un château. Dès 1312, le comte Ulrich de Ferrette cède Frœningen au chevalier Conrad de Flaxlanden. Le village est ensuite cédé aux Hadmansdorf en 1458, ensuite à la famille noble des Reinach-Heidwiller en 1539. Pendant la guerre de Trente Ans, lechâteau est épargné, mais est finalement incendié par les Suisses en 1468 qui sera finalement reconstruit au XVIIIe siècle.Il brûle à nouveau, à la suite d'une négligence d'un cuisinier en 1739. Une légende tenace colportée par les habitants fait état d'un souterrain qui reliait le châteauà la forteresse de Küppele, située sur la colline qui se trouve en face du village. Un trésor y serait caché gardé par une Dame blanche. Le château est reconstruit au début du XIXe siècle, mais tombe sous les bombardements de la Première Guerre mondiale en 1917. Le village avait une importante communauté juive à la fin du XIXe siècle et porta le sobriquet de Petite-Suisse.
Src Contenu soumis à la licence CC-BY-SA. Source : Article Frœningen de Wikipédia en français (auteurs)

Some pictures from my private collection of postal card of Froeningen

I forgot to blog about this presentation at JAZOON 2008, but I did never forget the added value of this plugin. It is not currently in Apache Maven  core but will for sure find its way as an official plugin one day, since it solve elegantly a common problem: technology management

Maven does not know the concept of an artifact life cycle. Such life cycle status information would allow to extend the dependency management in a new dimension. One could declare whether certain dependencies are actually allowed/forbidden/restricted to be used in a project, enabling effective technology management.

Currently a plugin is available to achieve this goal:The AssertDepend plugin. It work by adding metadata, additional xml files in artifact group directory.

The AssertDepend plugin is a Maven extension to perform effective technology management. The plugin checks at build time against lifecycle states defined in metadata on remote repositories in order to inform the developer about inappropriate technology usage (dependency enforcement). Based on a flag the build would either fail or print a warning.

Technology management benefits and means

The capability to manage dependencies and technologies on a mature level is essential for software organizations of a certain size. Technology management becomes a key discipline and must be introduced in a careful way to allow for mutual benefits among its stakeholder including developer, management, and customers.

Artifact lifecycle management

To perform effective technology management, you should keep the number of approved artifacts as small as possible. You cannot remove artifacts from the repository if you want to sustain reproducible builds. Therefore, each artifact in the repository should be marked with a corresponding lifecycle state.

The proposed main states are (but the plugin is not limited, you can create your own)

• approved
• prohibited
• investigating

With these states, it solve elegantly the following use cases.

Scenario 1: Flawed versions
It turns out that my-app-1.4.2.jar contains a serious security issue and is therefore flawed. Clients of this JAR should actually switch to a newer version my-app-1.4.3.jar which fixes the bug and which is safe to use.

Scenario 2: Decommissioning
Let's assume that my-app-1.4.2.jar is not supported anymore and projects should actually switch to a new release stream
(my-app-2.x.y.jar).

Scenario 3: Restricted usage
Consider a library which has a restricted set of client projects, e.g. only certain projects are allowed to depend on a specific artifact.

Usage

Artifact lifecycle metadata must be placed in a file named maven-artifact-lifecycle.xml in the corresponding group directory. For instance, if you want to define lifecycle information for struts, the corresponding metadata file is located here: struts/struts/maven-artifact-lifecycle.xml

This plugin can be downloaded at http://madp.sourceforge.net/index.html