04 Aug
2010

Warum Management der Abhängigkeiten von Komponenten? NU!

 

Seit einiger Zeit nervt mich folgendes.

Ich arbeite an verschiedenen Projekten, die meisten nutzen auch Komponenten die nicht von mir stammen. Diese wären z.B. xUnit.net, Rhino.Mocks, Automapper, StructureMap usw. usf.

Des weiteren bin ich ein Freund davon alles was man für das Projekt braucht auch unter der Versionkontrolle zu haben um es nach dem ausschecken

  • in Visual Studio öffnen,
  • es kompilieren,
  • auf dem Build-Server starten,
  • Versionspezifische abhängigkeiten habe,
  • usw

ohne dass es dabei zu Problemen kommt und man sofort damit arbeiten kann. Und man nicht schauen muss wo nun noch welche Assembly in welcher Version referenziert wird. Wenn mehrere an dem Projekt arbeiten potenzieren sich die Probleme weil jeder seine Assemblies woanders liegen hat. Somit, alles was geht mit in die Versionskontrolle. Dies sollte jeder so handhaben.

Wo liegt denn jetzt das Problem?

Ist doch alles schön und funktioniert. Nunja, fast, solange die externen komponenten nicht angefasst werden, nicht aktualisiert werden müssen sowie es nur ein Projekt ist. Nun sind auch noch eigenen Komponenten dabei, die zum Teil noch Rege in der Entwicklung sind und öfters aktualisiert werden.

Die Projekte aktuell zu halten, die Komponenten an den richtigen Platz kopieren ist eine nervige und auch für Fehler anfällige Arbeit.

Es wäre doch schön wenn man dies schnell, einfach und mehr oder minder automatisiert machen könnte.

Wir haben 2010, da muss es doch was geben?

Habe mich somit auf den Weg gemacht was zu suchen, was vielleicht eine Art Standard in der .NET Welt ist, Auch soll bei Open Source Projekten der Entwickler der mal kurz reinschnuppern will nicht in weitere Abhänigkeiten gedrängt werden, oder andere Teammitglieder müssen es nicht unbedingt verwenden um das Projekt zu bauen oder daran zu entwickeln.

Irgendwie nichts gefunden was meine Erwartungen und Bedürfnisse erfüllte. Als Software-Entwickler habe ich dies auf die lange MMMM-Liste gestellte (müsste man mal machen).

Ruby hat das Problem schon gelöst

Schaut man in die Ruby-Welt so gibt es da schon gar ewig RubyGems. Kleine Komponenten die man sich sehr einfach lokal auf den Rechner kopieren kann und immer aktuell halten kann.

Dies haben sich Dru Seller, Chris Patterson und ein paar andere auch gedacht und entwickelten NU. Ein kleines Tools welches auf RubyGems aufsetzt und somit auf bewährten. Dies um ein paar Features ergänzt die für “uns” wohl interssant sind.

NU betritt die Bühne

NU existierst nun schon eine ganze Weile aber seit 2-3 Wochen beginnt das ganze an Fahrt aufzunehmen, Nach der Installation von Ruby, Gems und Nu (ist total einfach) kann man schon loslegen.

nu install nhibernate

 

Und kurze später hat man in dem aktuellen Ordner einen LIB Ordner (einstellbar). Indem sich folgendes befindet.

  • castle.core
  • castle.dynamicproxy2
  • log4net
  • nhibernate
  • nlog

Es wurde NHibernate und dessen Abhängigkeiten installiert. Zuerst in das lokale Gem-Repository und dann in das Projekt. Und von da aus natürlich in die Versionverwaltung.

Auf Tekpub befindet sich ein kostenloses Video dazu, dies zeigt in knapp 3 Minuten was NU ist und kann.

http://tekpub.com/view/dotnet-oss/nu

Eigene Gems zu erstellen ist auch sehr einfach

Dazu einfach ein gemspec erstellen und über gem bauen

 

version = File.read(File.expand_path("../VERSION",__FILE__)).strip  

Gem::Specification.new do |spec|
  spec.name        = 'fluentmetadata'
  spec.version     = version
  
  spec.has_rdoc = false
  spec.files = Dir["lib/FluentMetadata.*.dll", "lib/Readme.txt"]
  spec.files.reject! { |fn| fn.include? "Specs.dll"  }
  spec.description = 'FluentMetadata is describing Object-Metadata on one place, and using it from ASP.NET MVC 2 & 3, FluentNHibernate and EntityFramework 4 CodeFirst with EF Feature CTP 4'
  spec.summary     = 'FluentMetadata - Metadata on one place for .NET'
  
  spec.author			 = 'Albert Weinert'
  spec.email             = 'info@der-albert.com'
  spec.homepage          = 'http://wiki.github.com/DerAlbertCom/FluentMetadata/'
end

 

Das bauen eines Gems ist sehr einfach

gem build fluentmetada
gem install fluentmetada

 

Dies natürlich am besten direkt im Build-Skript machen und man braucht sich nicht mehr zu kümmern.

Und schon hat man das Gem im lokalen Repository und fertig. Mit “nu install” kann man dies nun in andere Projekte übernehmen und aktualisieren (am besten wieder über ein Skript oder Batch). Und braucht sich nicht mehr darum zu kümmen wo der kram nun herkommt.

Aktuell kann man die dann noch per “gem push” auf Rubygems.org pushen und dort sieht es dann so aus.

http://rubygems.org/gems/fluentmetadata

Ein Buildscript (mit psake) welches das Gem immer wieder erzeugt kann so aussehen

http://github.com/DerAlbertCom/FluentMetadata/blob/master/default.ps1

Zukunft

Natürlich bringt so ein System nur was wenn es viele, wenn nicht gar alle verwenden. Dann hat man ein schönes Eco-System und viel weniger Probleme und arbeit. Also nutzt es.

Natürlich ist Rubygems.org auf Dauer keine Lösung für uns, und ein eigener Platz für .net gems wäre fein, da wird schon dran gearbeitet und wird nicht mehr so lange auf sich warten lassen.

Aktuell findet man unter http://nu.wikispot.org/ alle wichtigen Informationen und Links.

NU selbst ist weiterhin in Entwicklung in der Mailingliste diskutiert man gerade um es um weitere .net Specifika zu erweitern, mir reicht erstmal die jetzige Funktionalität es fehlen nur weitere Gems für .NET. Also macht mit.

Technorati Tags: ,,,

Der Eintrag ist mir etwas Wert
 

Feedback

# re: Warum Management der Abhängigkeiten von Komponenten? NU!

left by Karsten Samaschke at 8/4/2010 3:53 PM Gravatar
Erinnert mich an Maven in der Java-Welt. Hmm.

# re: Warum Management der Abhängigkeiten von Komponenten? NU!

left by Der Albert at 8/4/2010 4:07 PM Gravatar
NU/Gems ist in ein paar Minuten am laufen , bei Maven habe ich aufgegeben.
Comments have been closed on this topic.