[java] opzetten dev-omgeving veel projecten.

[Alarmnummer]

Het doel van dit topic:
advies inwinnen over het opzetten van een omgeving waarin veel projecten ontwikkeld kunnen worden.

Huidige situatie:
Ik werk aan een groot aantal projecten. Sommige projecten zijn al afgeleverd maar er moet wel eens een bug fix worden uitgevoerd. Sommige projecten die zijn nog niet klaar en ben ik mee bezig (zowel commercieel als opensource). Ik heb vrij veel library-projecten en ik begin intussen een beetje te verzuipen in de dependencies. En dit moet nu verbeterd worden anders gaat het me steeds meer kosten. Ik werk verder met ANT (wil ik niet vanaf) en gebruik een CVS.

Gewenste situatie:
Ik wil een systeem waarbij de dependencies tussen projecten geautomatiseerd kan worden. Als ik bv een nieuwe library heb uitgebracht, dan wil ik dat deze automatisch bij de projecten terecht komt als die er van afhankelijk zijn. Ik zit verder ook te denken aan een continuous integration server die de definitieve distributies voor klanten maakt zodat ik weet dat alle testen daarvoor ook gelukt zijn.


Ik zit op dit moment echt met mijn handen in het haar. Ik weet dat Maven een aantal van deze functies aankan, maar 1) ik wil niet 100% over op Maven. 2) ik zou niet weten hoe te beginnen aangezien mijn situatie niet op de site wordt beschreven. Dus wie heeft ervaring met het opzetten van omgevingen voor een groot aantal projecten en wie kan mij hierover advies geven. Als je verder niets weet dan zou ik het prettig vinden als je niet iets gaat bedenken, want dat heb ik intussen ook al gedaan. Ik zoek dus alleen advies van mensen die hier ervaring mee hebben. Ik wil graag weten hoe te beginnen, welke technieken gebruikt kunnen worden en wat de consequenties ervan zijn.

[Janoz]

Je wilt het misschien niet horen, maar ik denk dat je toch er aan moet geloven om op maven over te stappen. Binnen maven is keurig bij te houden welke versies afhankelijk zijn van welke versies. Hoe het opgezet zou moeten worden moet ik je helaas schuldig blijven. Ik heb me bij mijn vorige werkgever niet bemoeid met de overstap van ant naar maven. Ik heb er wel mee gewerkt en ik vond het een verademing.

Je bestaande ant scripts zijn niet overbodig aangezien deze goed in maven herbruikt kunnen worden. Daarnaast heeft maven een aantal handigheidjes die ant niet heeft.
• In plaats van 'depends' heb je nu pre en post goals. voor je taak X uit dan moet je eerst de pregoals voor X en daarna de postgoals van X uitvoeren. Dit geef je niet bij X aan, maar bij de pre en post goals zelf
• Je kunt extenden. Dat betekend dat je een root project.xml hebt die je voor elk project kunt extenden. In je root project kun je handige goals neerzetten

Om even naar het stukje dependencies te kijken:

XML:

<dependencies>

      <dependency>
         <groupId>EC</groupId>
         <artifactId>EC-distro</artifactId>
         <version>${ECDistro.version}</version>
         <type>ejb</type>
         <properties>
            <ear.bundle>true</ear.bundle>
         </properties>
      </dependency>

      <dependency>
         <groupId>EC</groupId>
         <artifactId>EC-common</artifactId>
         <version>SNAPSHOT</version>
         <properties>
            <ear.module>true</ear.module>
         </properties>
      </dependency>
 
      <dependency>
         <groupId>EC</groupId>
         <artifactId>EC-distro-ejbIF</artifactId>
         <version>SNAPSHOT</version>
         <type>jar</type>
         <properties>
            <ear.module>true</ear.module>
         </properties>
      </dependency>

      <dependency>
         <!-- Required by springframework -->
         <groupId>aopalliance</groupId>
         <artifactId>aopalliance</artifactId>
         <version>1.0</version>
         <properties>
            <ear.module>true</ear.module>
         </properties>
      </dependency>

      <dependency>
         <!-- Required by Fulcrum -->
      <groupId>asm</groupId>
      <artifactId>asm</artifactId>
      <version>1.4.1</version>
         <properties>
            <ear.module>true</ear.module>
         </properties>
      </dependency>
</dependencies>

Hierboven is een stukje van de dependencies van een project waar ik daar aan heb gewerkt. Hierin zitten een aantal voorbeelden. Ten eerste de {$blaat} die uit een property wordt gevult. De SNAPSHOT dat betekend dat ten alle tijden de meest recente versie opnieuw gecompileerd moet worden en gewone versie nummers die zoals tye verwachten de gewone versies aangeven.

Dit lijkt allemaal wat dubbel aangezien je de libs over het algemeen ook in je IDE definieerd. Maven heeft echter voor de meeste IDE's ook targets voor het genereren van project bestanden. Voordeel hiervan is dat juist deze dependecy definities als bron voor je ide lib instellingen gaat dienen!

Misschien moet je gewoon eens 3 testdingetjes neerzetten en gewoon een beetje gaan pielen. Ikzelf vond heel maven nogal overdonderend (geen idee welk target je eigenlijk als eerste aan zou moeten roepen), maar zodra je 'the hang of it' krijgt...

[Alarmnummer]

Ik heb 2 belangrijke argumenten tegen maven
1) Iedereen is bij ons ANT gewend. Aangezien er mede door mij al een aantal (zware) technische verbeteringen zijn doorgevoerd, wil ik heb iets rustiger houden op gebied van veranderingen en pas weer iets nieuws kiezen als dit voor anderen ook een groot voordeel heeft (op dit moment ben ik vooral de gene die er behoefte aan heeft).
2) Ik heb bij ANT 110% controle.. En ik ben niet bereid om met minder genoegen te nemen. Ik heb al een aantal keren gehoord dat mensen met Maven niet de controle hadden die ze nodig zijn.

Maar ik ben wel bereid tot een integratie. ANT voor het builder 1 enkel project. Maven voor de projecten. Ik ben trouwens net tegen dit project aangelopen: http://maven.apache.org/maven2/ant-tasks.html en daar ben ik nu net mee aan het spelen.

[ Voor 11% gewijzigd door Alarmnummer op 26-08-2005 14:20 ]

[Janoz]

hmm, Aangezien de alinea's begonnen met 'Ik werk' en 'ik wil' was ik niet van een ontwikkel team uitgegaan. Voordat je het bij een groep mensen introduceert moet je, los van hoevaak je ze al wat nieuws opdringt, met een solide oplossing komen. In dat geval zal je het zelf dan al druk up and running moeten hebben. Ik was met mijn verhaaltje ook uitgegaan van een eventuele 1 persoons/thuis situatie.

[Alarmnummer]

Janoz schreef op vrijdag 26 augustus 2005 @ 14:22:
hmm, Aangezien de alinea's begonnen met 'Ik werk' en 'ik wil' was ik niet van een ontwikkel team uitgegaan.

Ik zit op dit moment nog in de 'ik kan het onderzoeken.. en ik erger me het meeste aan van ons allemaal'. Uiteindelijk willen we allemaal tools gebruiken die ons zo weinig mogelijk hoofdpijn bezorgen.

Voordat je het bij een groep mensen introduceert moet je, los van hoevaak je ze al wat nieuws opdringt, met een solide oplossing komen. In dat geval zal je het zelf dan al druk up and running moeten hebben. Ik was met mijn verhaaltje ook uitgegaan van een eventuele 1 persoons/thuis situatie.

Dat zal voorlopig ook wel de situatie zijn. Ik ben op mijn werk (en thuis) met een aantal projecten bezig waar ik de voornaamste developer ben, dus ik kan ook experimenteren wat het prettigste werkt. Uiteindelijk is het de bedoeling (als het allemaal fijn werkt) dat iedereen het gaat gebruiken. De vraag is of de moeite en de extra complexiteit (lees extra problemen aangezien complexiteit per definitie meer problemen veroorzaakt) opweegt.

[ Voor 12% gewijzigd door Alarmnummer op 26-08-2005 14:28 ]

[Janoz]

Met maven is het wel zo dat het erg prettig en intuitief werkt als het eenmaal draait. Voordat het draait duurt het echter nog wel even, maar dat had ik de eerste keer dat ik met ant begon ook. Het kwartje moet even vallen en dat lukt over het algemeen het beste wanneer je er zelf wat mee speelt.

Je zou nog iemand bij Fundament kunnen vragen hoe zij het gedaan hebben en tegen welke problemen ze aangelopen zijn. Vraag het dan bij voorkeur aan Cees, die heeft het traject doorgelopen wat jij nu door wilt gaan lopen.

[ari3]

Maven is de manier om grote projecten te managen. Ik ben ruim 1.5 jaar geleden overgestrapt en wil nooit meer terug naar plain Ant.

Waarom Maven:

* Maven regelt de dependencies van alle projecten. Maven kan dependencies erven van andere projecten zodat een nieuwe versie van een dependency automatisch propageert naar andere projecten. Ook dwingt Maven je versienummers te geven aan dependencies. Ant kan zoiets niet zonder dat je het zelf schrijft.
* Maven structureert je projecten. Voor standaard dingen zijn standaard properties gedefinieerd (op basis van best-practices, geen beginners-gekloot). Voorbeeld: wanneer een project een WAR oplevert heb je dus een property die de lokatie van de web.xml aanwijst. Belangrijk voordeel is dat voor iedere project dat een WAR bouwt dezelfde property-namen heeft. Ant kan zoiets niet zonder dat je het zelf schrijft en vereist absolute discipline van het ontwikkelteam.
* Maven regelt haar eigen dependencies. Wanneer je een Maven-plugin (bijv. XDoclet) nodig hebt om een project te bouwen dan is dit onderdeel van de project properties. Collega ontwikkelaars hoeven dus nooit handmatig hun plugins te vernieuwen. Ant kan zoiets niet zonder dat je het zelf schrijft.
* Maven download dependencies zodra het project opnieuw gebouwd wordt. Collega-ontwikkelaars hoeven dus nooit meer handmatig JARs van andere collega's te kopiëren, of erger nog gewoon een versie van het internet te plukken waarvan zij denken dat het wel zal werken. Ant kan zoiets niet zonder dat je het zelf schrijft.
* Maven kan (iedere populaire) IDE inrichten voor een bepaald project. Je hoeft dus nooit meer je build classpath handmatig in te stellen of dependencies toe te voegen in je IDE. Ant kan zoiets niet zonder dat je het zelf schrijft.
* Maven kan releases en snapshots beschikbaar maken aan collega-ontwikkelaars. Ant kan zoiets niet zonder dat je het zelf schrijft.
* Het standaard gedrag van Maven-plugins is te sturen met zgn. pre- en postgoals. Je kunt dus het gedrag van een bepaalde goal wijzigen door zelf een goal te definiëren welke het gedrag heeft zoals jij het wilt. Er zijn maar zeer weinig situaties waar dit echt nodig is.

Merk op dat ik veel nadruk leg op het niet zelf hoeven regelen van de bovengenoemde functionaliteit. Niet dat zelf schrijven het ergste is, het probleem is alleen dat je ziet dat iedere ontwikkelaar iedere keer het wiel opnieuw uitvind met Ant. Wanneer iedere project zijn eigen Ant-build heeft zul je zien dat iedere ontwikkelaar zijn eigen properties en targets gaat bedenken: Sjaak zet een project op en noemt de source lokatie ${src.java}, Arie zet een project op noemt zijn source lokatie ${src.dir}. Maven structureert dit. Een JAR bouwen is altijd de jar-goal en dus niet Sjaak's jar-build target of Arie's compile-jar target.
Maven voorkomt dus dat je bij ieder project waar je onderhoud aan pleegt weer in de Ant-build moet spitten hoe je de zooi kan bouwen omdat iedere ontwikkelaar zonodig zijn eigen build.xml moest schrijven. Kortom, Ant is een tool die door de praktijk is ingehaald. Maven scheelt je gewoon zeëen van tijd om houdt alles beheersbaar.

[Verwijderd]

advies inwinnen over het opzetten van een omgeving waarin veel projecten ontwikkeld kunnen worden.

Dat maven klinkt goed, maar wat als daar nu een C++ project inmoet? Of Pascal (Delphi)? Of VB? Of c#?

Als maven alleen java projecten kan hebben, is het een vrij waardeloos source beheer systeem imo, tenzij je in een bedrijf werkt die alleen java zaken maken.

[ari3]

Verwijderd schreef op vrijdag 26 augustus 2005 @ 22:22:
[...]Dat maven klinkt goed, maar wat als daar nu een C++ project inmoet? Of Pascal (Delphi)? Of VB? Of c#?

Maven is een generiek opgezet raamwerk. Alle functionaliteit, ook die voor Java, loopt via plugins. Mijn kennis van plugins voor andere talen is beperkt. Mijn indruk is dat Maven zich voornamelijk richt op Java en gerelateerde tools.

[CubicQ]

Verwijderd schreef op vrijdag 26 augustus 2005 @ 22:22:
[...]


Dat maven klinkt goed, maar wat als daar nu een C++ project inmoet? Of Pascal (Delphi)? Of VB? Of c#?

Wat nou als je een C++ compiler hebt en je hebt Delphi code? Dat een C++ compiler niet om kan gaan met Delphi code maakt de compiler toch niet minder of onhandig of whatever?

Dat een build tool op 1 platform werkt is imho totaal geen probleem. Het builden van een java project is gewoon heel anders dan het builden van bijvoorbeeld een C++ project. Wanneer je een tool hebt die gericht is op het builden van 1 platform, dan betekent dat ook dat je tool geoptimaliseerd kan zijn voor dat platform en dat het daardoor beter kan zijn dan een generieke tool wanneer je dat ene platform gebruikt.

Als maven alleen java projecten kan hebben, is het een vrij waardeloos source beheer systeem imo, tenzij je in een bedrijf werkt die alleen java zaken maken.

't is dan ook geen source beheer systeem...

[Alarmnummer]

Verwijderd schreef op vrijdag 26 augustus 2005 @ 22:22:
[...]
Dat maven klinkt goed, maar wat als daar nu een C++ project inmoet? Of Pascal (Delphi)? Of VB? Of c#?

Als maven alleen java projecten kan hebben, is het een vrij waardeloos source beheer systeem imo, tenzij je in een bedrijf werkt die alleen java zaken maken.

Ik zal morgen even reageren op de java replies... maar ik zit dus in een java omgeving. Op dit moment zijn non java omgevingen een non issue.

[Alarmnummer]

Ik heb intussen een aantal kleine projecten omgezet en tot zover ben ik er wel tevreden over. De vorm van projecten is erg uniform.. niet meer zoveel geneuzel met ant scripts. Maar het zal zich nog moeten bewijzen bij grotere omgevingen. Misschien dat ik deze week een paar grotere projecten aan ga passen .

Een ding dat ik me nu wel afvraag, is hoe mijn ide beschikking kan krijgen over de libraries die mijn project nodig heeft? Ik kan niet mijn hele locale reposity aan mijn ide toevoegen (zeker niet dat er veel verschillende versies van jars kunnen bestaan).

[ Voor 3% gewijzigd door Alarmnummer op 30-08-2005 20:49 ]

[ari3]

Alarmnummer schreef op dinsdag 30 augustus 2005 @ 20:49:Een ding dat ik me nu wel afvraag, is hoe mijn ide beschikking kan krijgen over de libraries die mijn project nodig heeft? Ik kan niet mijn hele locale reposity aan mijn ide toevoegen (zeker niet dat er veel verschillende versies van jars kunnen bestaan).

Dit gaat middels de Maven-plugin voor je favouriete IDE (Eclipse, JBuilder of IDEA bijvoorbeeld). Deze plugins maken gewoon een IDE-specifieke project file aan waarbij het build-classpath (binnen je IDE) ingesteld wordt met verwijzingen naar libs in je lokale repository.

Voor iedere project krijg je dus alleen de dependencies uit je POM (project.xml) als build-classpath in je IDE.

[Alarmnummer]

ari3 schreef op dinsdag 30 augustus 2005 @ 21:18:
[...]
Dit gaat middels de Maven-plugin voor je favouriete IDE (Eclipse, JBuilder of IDEA bijvoorbeeld). Deze plugins maken gewoon een IDE-specifieke project file aan waarbij het build-classpath (binnen je IDE) ingesteld wordt met verwijzingen naar libs in je lokale repository.

Voor iedere project krijg je dus alleen de dependencies uit je POM (project.xml) als build-classpath in je IDE.

Ik had janoz al even gevraagd. Maar de dependencies worden idd direct uit de locale repository gehaald (dat wou ik even weten).