Newsgroup: it.comp.java
Titolo: Che ne pensate di Maven?

Salve al gruppo,
Sono un cosiddetto software developer, lavoro in una software house.
Da un po' di tempo abbiamo un nuovo collega che ci sta trasformando i
progetti in una struttura integratissima (nel senso di continuous
integration) e sta introducendo Maven nel nostro spazio lavorativo.
Per intendersi, adesso in Eclipse non si compila piu' come una volta
(Project -> Build) ma con l'uso di un plugin Maven (click destro su un
progetto + Run as -> maven install)
Quindi, al posto di un progetto solo, ne abbiamo circa una ventina
tutti gestiti da maven. Questo significa che il progetto viene creato
automaticamente, i sorgenti scaricati dal repository, persino il nome
del progetto gia' deciso.
Insomma, adesso invece di pensare a fare codice dobbiamo essere
consapevoli di tutto il ciclo vitale del progetto (compile, build,
assembly, test, package, dipendenze, e chi piu' ne ha piu' ne metta).
Alla fine per fissare un baco, ci metto 1 ora, di cui 10 minuti per
scrivere codice + test, il resto per capire come compilare.
Insomma, riconosco che questo maven possa essere utile, ma secondo me
piu' al build team, mentre il developer team deve subirlo un po'.
Sinceramente, a me poco importa di sapere tutti questi dettagli di
plugin e phases, vorrei riuscire a concentrarmi sul codice, sul
business. Ma non ci riesco piu'.
Che dire? Son troppo vecchio? Colpa mia che non riesco a imparare cose
nuove?
O forse le mie perplessita' sono condivise da qualcun altro?
Per favore, indicatemi la via
TN

 TN
Nicola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 Per favore, indicatemi la via
Sembra che sia successo un terremoto nel vostro team di sviluppo. Non 
preoccuparti pian piano imparerai ad usare queste astrusit� e se sono 
utili sarai felice di usarle, se non sono utili il team prima o poi 
decider� di non usarle piu'.
-- 
Andrea Francia
http://www.andreafrancia.it/

 Questo puo' essere un bene ma spesso e' un male.
E' un bene quando viene fatto un po' alla volta valutando i risultati di 
ogni passo.
E' un male quando viene fatto perch� qualcuno (anche te stesso) ti ha 
convinto che ne hai assolutamente bisogno e che quello � il silver 
bullet per risolvere i problemi dello sviluppo, e quando applichi tutto 
quello che leggi in giro senza chiederti se si applica al tuo caso 
specifico.


piu' al build team, mentre il developer team deve subirlo un po'.
Non credo che seguire nuove regole debba terrificare gli sviluppatori.
Tutto dipende (vedi sopra) dal livello di adeguamento e comprensione
richiesto.

 O forse le mie perplessita' sono condivise da qualcun altro?
penso sinceramente che nel tuo malcontento maven c'entri meno che nulla. 
  se c'� una cosa che maven fa egregiamente � proprio semplificare.
nel tuo progetto sono stati introdotti nuovi concetti che prima non 
gestivate, questo � il motivo del tuo malumore. malumore che, a mio 
modesto avviso, giustifichi con argomentazioni un po' bislacche: nessuno 
pu� dire che queste procedure siano adeguate al progetto, quando per� 
sostieni che impatta sullo sviluppo dai la netta sensazione che tu stia 
banalmente remando contro.
-- 
++ Fino all'anno scorso avevo un solo difetto. Ero presuntuoso.
http://unopuntozero.wordpress.com/
http://www.flickr.com/photos/marko_po/

 banalmente remando contro.
Confesso di essere piuttosto confuso. Non ho mai avuto problemi a
capire le nuove tecnologie. Ma questa volta non riesco proprio a
farmelo entrare nella testa. Per questo le mie argomentazioni sembrano
un po' confuse: perchè non capisco bene la bestia che ho di fronte e
non so da che parte prenderla.
Io credo che ci sia modo e modo di applicare una tecnologia, a
discapito del titolo del post forse non si può dare un giudizio su
maven, ma su chi lo applica al contesto. Come tra l'altro suggerivano
n.n. e A. Francia.
Fatto sta che tutti gli sviluppatori da noi sono un po' perplessi.
Tutti stanno remando un po' contro. Ma allora forse c'è veramente
qualcosa che non va. E se il team è scontento, la produttività cala.
Ergo, Maven nel nostro caso sta impattando sullo sviluppo in modo
negativo.
Grazie per le risposte, mi hanno chiarito un po', ma qui il problema è
tutto nostro, dovremo ridiscutere la cosa tra di noi.
TN

build, ed è falsissimo che non si riesce ad evitare di fare un build
da 10 minuti per una modifica. Addirittura io eseguo i test Junit
direttamente da Eclipse, da Netbeans o da riga di comando senza dover
fare un build completo; con in più i vantaggi di avere Maven.
Perché invece che sospettare di tutto e di tutti non proponete di
farvi fare un corso sull'argomento, magari dal nuovo arrivato? Ne
avete solo da guadagnare!!
Se volete fare una partenza "morbida" vi consiglio AppFuse:
http://appfuse.org/
--
www.megadix.it

 come un abuso di potere da parte della prima burbetta che arriva...
non siamo a fare il militare.
se a una persona viene dato un compito di introdurre nuovi processi mi 
devi spiegare perchè è un abuso di potere. perchè è nuova? beh, sarà il 
caso di farsene una ragione: se l'ambiente dimostra di essere inerte e 
statico è assolutamente normale che poi certi compiti di aggiornamento 
vengano affidati a nuove persone.


 vengano affidati a nuove persone.
Proprio perche' la cosa viene proposta da un nuovo collega e non da un
capo, non viene vissuta come un abuso di potere. Anzi, abbiamo deciso
tutti assieme di iniziare questa ristrutturazione e abbiamo dato carta
bianca al rookie, che tra l'altro e' una persona molto in gamba. Ora,
passati vari mesi, la mia impressione e' che forse siamo andati troppo
oltre.
La mia richiesta per un parere "tecnico" si e' trasformata in
un'indagine socio-psicologico-attitudinale. L'ambiente dove lavoriamo
non e' assolutamente statico, ogni giorno vengono proposte nuove
soluzioni. In particolare, io mi sto occupando della migrazione
dell'applicazione dal vecchio struts verso JSF/Facelets. E siamo
sempre li' a migliorare, applicare nuove idee, etc...
Quindi non scambiate la mia richiesta per un'implicita lamentazione
contro una situazione "nuova". Sto veramente cercando un parere
tecnico. Se no scrivevo su it.discussioni.psicologia
grazie comunque delle risposte
TN

 un'indagine socio-psicologico-attitudinale.
il parere tecnico è:
- maven come strumento è idoneo a tutti i livelli. usarlo semplifica 
*sempre*, a prescindere dalla complessità del progetto e del suo ciclo di 
sviluppo.
- gestire le dipendenze col metodo maven (esternamente, senza versioning 
delle librerie) è notevolmente efficiente a prescindere dal progetto
- introdurre nel ciclo di sviluppo altri processi come i test automatici 
e il versioning dei rilasci non si può dire che sia opportuno oppure no, 
dipende da una serie di fattori legati al progetto. gli unit test sono a 
mio modesto avviso sempre opportuni, altre cose dipende dalle esigenze 
finali del progetto. è chiaro che se si tratta di un software sviluppato 
su commessa difficilmente esiste l'esigenza di fare il versioning dei 
rilasci, se però è un prodotto o (ad esempio) una libreria riutilizzabile 
è possibile che questa esigenza ci sia.


 sempre li' a migliorare, applicare nuove idee, etc...
Benissimo! Allora siete sicuramente pronti per passare a Maven :)
Infine, condivido in pieno le considerazioni di rootkit, aggiungo solo
che anche sul software su commissione noi usiamo il versioning perché
c'è sempre qualche bug da risolvere o il cliente chiede nuove
caratteristiche. Ben venga quindi il versioning :)
--
www.megadix.it

 Benissimo! Allora siete sicuramente pronti per passare a Maven :)
ok, mi avete convinto, berro' l'amaro calice.
Sto gia' laegendo la documentazione, per la terza volta.
Speriamo di farmelo entrare, stavolta...
TN


Uno dei problemi di maven e che fa di tutto e questo lo rende poco 
comprensibile.
Anch'io faccio a fatica a comprenderlo. Adesso lo sto usando solo per le 
dipendenze e usando un progetto creato dal wizard del plugin maven per 
netbeans.


Ciao,
   non so se lo hai già trovato. Ti segnalo questa pagina che contiene
un testo in PDF, "Better builds with Maven", liberamente scaricabile:
http://www.exist.com/better-build-maven
Ci sono anche esempi di codice che dovrebbero aiutare nella lettura e
nell'apprendimento.
Ciao
Daniele

 Andrea Francia



Io sviluppo progetti Maven anche parecchio complessi, con vari moduli
e sottoprogetti.
Ti assicuro che non da alcun problema con la compilazione in Eclipse,
anzi.
Io evito accuratamente il plugin di Eclipse, in quanto (almeno nel mio
caso, avendo sottoprogetti) non funge benissimo.
In compenso mi trovo egregiamente da linea di comando.
Per prima cosa faccio:
mvn eclipse:eclipse
Questo genera i file di configurazione per poter gestire il tuo
progetto da Eclipse. Dopo qusto comando posso importare il progetto e
compilarlo, vedere gli errori, navigare tra i sorgenti.
Se devo fare una build uso mvn:
mvn package
Per i test puoi benissimo usare maven
mvn test
oppure Eclipse stesso, e debuggo pure tranquillamente (preferibile se
si e' in fissaggio di un bug)!
Quindi in definitiva, Maven non introduce alcuna complessita' (se non
il doverselo imparare all'inizio) e anzi come dice rootkit semplifica
di molto il processo di build, test, deploy.
Per lavoro sto utilizzando ant in un grosso progetto multi modulo.
Sinceramente rimpiango alla grende Maven.


Se persino Seam si prende la briga di supportarlo a pieno, forse non
ci sono tutti questi grandi problemi come dici. Alcuni minori
senz'altro, non lo si nega, per carita'.
E quali sarebbero, in definitiva, i problemi di Maven?

 comprensibile.
Bah, a me sembra che faccia le cose basilari: compilazione, test,
impachettamento, test di integrazione, deploy.
Poi se non ti basta hai i plugin. Se installi un plugin nel tuo
pom.xml sicuramente sai anche perche' lo stai usando e come lo stai
usando.
Non mi e' mai capitato che maven mi facesse cose di nasconsto (non
introduce problematiche da hibernate insomma).

 dubbiosi.
tutti dubbiosi, ma nessuno che esprima con chiarezza cosa c'è che non va.
per quanto mi riguarda solo per il fatto che basta mettere i sorgenti 
nella directory giusta per avere compilazione, test e packaging gratis 
senza dover scrivere niente nel suo pom, basta e avanza per mandare a 
quel paese ant anche solo per scrivere Hello World.
aggiungi poi:
- i repository delle dipendenze esterni al progetto. il fatto di non 
tenere le librerie nel repository dei sorgenti lo reputo *essenziale*
- lo scope delle dipendenze. se una libreria ti serve solo in 
compilazione, oppure solo nei test, oppure se la vuoi includere nel 
packaging
- gli archetipi, fondamentali per lo startup dei progetti e non 
ricominciare tutte le volte dal "c'era una volta, un progetto java...".
- i plugin anch'essi agganciabili per progetto dai repository esterni, 
senza installare nulla
sia chiaro, in definitiva è tutta roba che si può risolvere anche con 
ant. a manella e scrivendo palate di xml...


 
No, sta usando una terminologia Maven.
Maven ha a disposizione moltissimi plugin per fare le cose piu' 
disparate, tutti facilmente installabili: basta definirli nel pom.xml.
Con phases indende le diverse fasi della build del progetto: compile, 
test, package sono solo le piu' comuni.

qualcosa che non va. E se il team � scontento, la produttivit� cala.
Se il team � scontento bisogna spiegargli perch� dovrebbe essere
contento e quindi renderlo contento. Ti assicuro che la perplessit�
generale e il remare contro (che non va mai bene) non sono garanzie
che qualcosa non vada, se non proprio da parte dei perplessi. Quando
da un cliente ci siamo sentiti obbligati ad imporre un sistema di
versioning (prima CVS migrato poi a SVN) ti assicuro che tutti,
abituati al vecchio modus operandi, erano perplessi e tutti avrebbero
volentieri remato contro. Ovviamente quest'ultima cosa non l'hanno
fatta perch� li avremmo prontamente bastonati.


Grazie, anch'io non mastico ancora bene maven.
-- 
Andrea Francia
http://andreafrancia.blogspot.com/2008/07/colinux-linux-dentro-windows.html

 impachettamento, test di integrazione, deploy.
Cosa intendi con test di integrazione?
Cosa fa riguardo ai test di integrazione?


 integrazione?
Da solo quasi nulla. Ha pero' una fase specifica chiamata integration-
tests:
mvn integration-tests
Usando plugin vari è possibile far eseguire i tuoi integration test, per 
esempio con Selenium RC, in questa fase. Questa fase precede 
l'installazione (fase install) dell'artefatto prodotto nel repository 
maven.

 E quali sarebbero, in definitiva, i problemi di Maven?
Il problema e' che in produizione uso seam 1.2 che va con ant.
Quindi studio maven e non lo applico. Questp e' il vero problema. Studiare
senza applicare mi dimentico la roba e non e' incisivo come con le
applicazioni reali.
Ciao Nicola


Sto veramente cercando un parere tecnico.
"Maven does encourage best practices, but we realise that some
projects may not fit with these ideals for historical reasons. While
Maven is designed to be flexible, to an extent, in these situations
and to the needs of different projects, it can not cater to every
situation without making compromises to the integrity of its
objectives".
http://maven.apache.org/what-is-maven.html
Se escludiamo pregiudizi ed ostracismi vari, come mi sembra di capire
da quel che dici, probabilmente i vostri projects sono tra quelli per
i quali Maven may not fit.

Bella discussione



Credo che i progetti per cui "may not fit" sono quelli descritti poco 
dopo:
"If you decide to use Maven, and have an unusual build structure that you 
cannot reorganise, you may have to forgo some features or the use of 
Maven altogether."
Che non dovrebbe essere il suo caso, visto che il tipo ha tranquillamente 
messo mano ai progetti. 
Pare invece di capire, da quel poco che e' trapelato, che si tratta di 
progetti multi modulo, con necessita' di gestire dipendenze interne ed 
esterne. Un ambito in cui Maven va davvero forte.

esterne. Un ambito in cui Maven va davvero forte.
...se Maven, come � vero, va davvero forte in quest'ambito, delle due
l'una: o ha combinato qualcosa chi ha riorganizzato, o stentano a
capire ed utilizzare il sistema gli sviluppatori.
Dando per buona la seconda, ci sarebbe stato bisogno di una
spiegazione a monte dello stravolgimento. Non si stravolge un modo di
lavorare, seppure verso il meglio, per POI spiegare agli sviluppatori
come adeguarsi.

 come adeguarsi.
Ma e' anche vero che l'ultimo arrivato non puo' certo dire "ora vi
faccio il corso" (che in realta' magari non gli dispiacerebbe fare).

faccio il corso" 
Chi l'ha detto? L'ultimo arrivato potrebbe essere pi� esperto degli
altri e proporsi per un corso. Sar� il vertice aziendale a decidere se
debba o meno tenere lezione. E gli altri zitti e mosca. E' cos� che
funziona in un'azienda che si rispetti.


Sto 3d e' carino e sconfina :-)
Riassunto delle puntate precedenti.
1. C'e' una Azienda che lavora su un progetto , che di fatto sono N
sottoprogetti/progetti indipendenti.
2. L'azienda e i suoi devs ci hanno lavorato fino a oggi piu' o meno
serenamente.
3. Un giorno un qualche capoccione che puzza di non essere un architect ma
un dirigente puro, probabilmente consigliato da qualcuno, introduce:
a. Unun nuovo elemento nel team
b. Una serie di nuove metodologie/tecnologie che il Nuovo pare conoscere
abbastanza bene
4. I dev "di getto non gradiscono", pur applicandosi piu' o meno con
decisione, e si pongono la domanda se tutto o una parte delle novita'
fossero addirittura di intralcio alla produzione
Dalla discussione qua sul NG emerge chiaramente che :
a.
Maven non c'entranulla nel senso che maven e' una ottima tecnologia
( non banale ) che di per se e' ampiamente riconosciuta come valida dalla
comunita' internazionale
b.
L'operazione e' comuqnue fatta in modo traumatico e, visto il malumore
generato, qualche errore da qualche parte c'e'
c.
La figura del "Nuovo" e' da "inchiesta aziendale" e probabilmente prima in
hitparade alla macchinetta del caffe :-))
d.
Volendo fare questo "hard upgrade" di processi/tecnologie, ci starebbe una
sorta di corso/aggiornamente ma non si capisce bene chi e come dovrebbe
tenerlo.
Come mie conclusioni personali:
-)
Il commento che ho trovato pi� ragionato e utile e' stato quello di Francia
che dice che l'upgrade si poteva fare "splittato" per step valutando step by
step l'utilita' e l'incisivita' degli step. Magari anche abortendo alcune
novita'. Il tutto diluito in alcuni mesi, visto anche che non sono riforme
da "vivo o morto".
Cosi' le cose sarebbero entrate alla leggera, addirittura magari come
piacevoli novita', e tutti avrebbero vissuto il cambiamento meglio di cosi'.
-)
Maven teniamolo fuori che c'entra poco o nulla a livello qualitativo
-)In un progetto in corsa un corso di aggiornamento al team di una sola
giornata minimo, ma anche di 2 o 3 , perche' no ? Costo irrisorio per una
azienda e umore molto piu' alto di tutto il team.
-)
Il nuovo elemento nel team e' stato introdotto in modo probabilmente errato,
e qua parliamo dei cari soft-skill ( Dim ti ricordano qualcosa ?
buahahhahaha ).
Se la dirigenza vuole introdurlo e poi metterglielo a capo di tutti, forse
era meglio dirlo dall'inizio, via il dente, via il dolore.
-)
Se la dirigenza ha introdotto il nuovo e non vuole farlo Architect/pm o
simile, ha sbagliato di bestia perche' questo e' partito col modo sbagliato
di integrarsi col gruppo.
-)
Un corso effettivamente anche solo di 8-16 ore si dovrebbe fare, meglio se
lo facesse un terzo che non e' il Nuovo , oppure il Nuovo purche siano
chiariti i punti precedenti.
Ciao NIcola


 siano chiariti i punti precedenti.
Io dopo due o tre ore di corso su Maven, non saprei gia' piu' cosa 
dire ;). 

 porting completo o non lo fai, non ci sono vie di mezzo.
qui sul tutto o niente di Maven non mi trovo d'accordo, si può partire
dal minimo sindacale della gestione delle dipendenze - magari anche
via ant usando i maven ant tasks - e poi da lì a salire decidendo del
resto cosa davvero risulti utile...
--m

 --m
Se per quello c'e' anche l'ant plugin per maven, ma fare un misto del 
genere non lo vedo piu' semplice.
Se poi interessano solo le dipendenze c'e' anche Ivy per Ant che fa piu' 
o meno quelle cose.

On Fri, 03 Oct 2008 18:43:09 GMT, 
n....@libero.it
 (n.n) wrote:
<snip>
Quante cazzate! :-)

 --
Salve a tutti.
Frequento da qualche anno questo ng. Qualche volta vi ho fornito anche
contributi utili (spero), a volte ne ho avuti.
Questo è un caso in cui vi chiedo un aiuto per capire.
Non ho mai usato Maven nè lavorato con gente che ci lavorasse. Chi
vuole esprimere in due parole cosa è, risponde "è l'erede di Ant". Nel
post di rootkit c'è qualche interessante dettaglio in più. In effetti
io non ho mai usato nemmeno Ant.
Perchè questo? Perchè uso Eclipse. La compilazione va in automatico,
il check sulle dipendenze anche, JUnit è integrato. Chiaramente
"dietro" immaginoi venganoi sempre lanciati comandi Ant ma io non ho
bisogno di scrivere build.xml, ossia l'uso di Ant a me è trasparente.
Allora delle due l'una.
O sono io che non ho capito ancora i vantaggi aggiuntivi offerti da
Maven a quanto già non fornisca Eclipse (o Netbeans presumo) o in
alcuni gruppi di lavoro si lavora parallelamente con un IDE e con file
di impostazione tipo build.xml.
Quale delle due? E se la risposta è la seconda, perchè c'è chi lavora
così?
Grazie

 così?
Quello che stai chiedendo è se è importante avere un processo di build 
indipendente dall'IDE. Per quanto mi riguarda la domanda è retorica! :)
Tralasciamo le feature specifiche di Maven, tipo la gestione delle 
dipendenze (che non è assolutamente un semplice check), che da sole 
secondo me valgono la pena.
Prova a immaginarti su un'isola deserta e senza il tuo computer, ma solo 
un cellulare, una connessione GPRS e un client SSH (ad esempio Putty 
funziona benissimo sui cellulari). Tu riusciresti a fare un build di un 
progetto, anche molto complesso, in queste condizioni (cioè senza avere 
nessuna possibilità di eseguire Eclipse, o qualunque altro IDE)?
Con un processo di build svincolato dall'IDE, e con la possibilità di 
mandarlo in esecuzione da riga di comando, sì! Maven (come Ant, make, 
ecc.ecc.) permette questo.
Perché farlo? Ad esempio per stare in vacanza e controllare che gli 
sviluppatori stiano continuando a fare il loro lavoro, senza fare danni. 
:) (magari non facendolo a mano col cellulare, ma lasciando fare ad un 
server di continuous integration ;) )
Maven è l'erede di Ant? Boh, io non credo, sono semplicemente due tool 
diversi, a cui si può riuscire a far fare le stesse cose. Personalmente 
preferisco Maven perché, seguendone le convenzioni, si perde molto meno 
tempo a scrivere e manutenere il processo di build.
Se vi interessa una presentazione su Maven e sull'automazione del 
processo di build, ce n'è stata una durante l'ultimo meeting del JUG 
Padova. Qui ne trovate il video e le trasparenze:
http://www.jugevents.org/jugevents/event/show.html?id=7321
Ciao
   Lucio
-- 
Lucio Benfante
JUG Padova           
http://www.parancoe.org
 ...have a look at it!
www.jugpadova.it
 
http://www.jugevents.org



Come dice Lucio, l'indipendeza da IDE è importante ad esempio per il 
continuos integration, e ci sono anche altre valide ragioni per usare Ant 
o Maven. 
Nessun IDE è in grado di raggiungere la completezza e potenza di questi 
strumenti, a meno che non si appoggino ai suddetti (come in effetti 
spesso avviene): 
-test integrati nel processo di build, 
-gestione dei file di properties e risorse varie in base a profili di
 produzione e sviluppo, 
-impacchettamenti complessi (WAR, EAR, JAR)
-deploy/undeploy
-gestione delle dipendenze tra progetto/librerie e progetti/sottoprogetti
-non mi viene in mente altro, per ora ;)

 così?
La seconda che hai detto :)
Il mio metodo di lavoro deriva da semplici considerazioni:
- il build con Ant o Maven è bello perché fa tante cose fichissime; è
in pratica la *scelta obbligata* per creare il pacchetto finale,
grazie appunto a: test, impacchettamnento, automazione, eccetera;
- purtroppo però è un processo molto lungo: per ricompilare una sola
classe bisogna aspettare parecchio;
- di contro, ogni IDE è in grado ricompilare in meno di un secondo un
progetto intero, anzi ricompila le classi mentre le modifico!
Da qui il mio "metodo":
- Maven o Ant per i build "ufficiali";
- creo una "build/classes" dove far "sfogare" Eclipse :)
In questo modo ho il meglio di entrambi i mondi: posso fare un bel
build con tutti i caz.. ehm i crismi, ma posso anche ricompilare al
volo una classe e testarla subito con JUnit/TestNG, posso addirittura
fare un hot-swap mentre sono in debug (quando funziona...).
E poi, ultima considerazione fondamentale, ho visto come ci si riduce
a essere dipendenti dall'IDE... presso un cliente utilizzavano una
versione buggatissima di WSAD, ma era l'unica che funzionava con la
loro versione dell'AS, e l'avevano pure pagata fior di quattrini, ma
non ne avevano altri per l'aggiornamento. Risultato: un lungo papiro
*appeso alla parete* con scritti i passi (clicca qua, clicca là) per
fare un build, per creare un EJB, per creare un WAR... tristissimo...
--
www.megadix.it

 volo una classe e testarla subito con JUnit/TestNG, 
Cos'ha TestNG in più(o in meno) rispetto a JUnit?


 modifica -> cancellazione . In questo modo, se i test di lettura
falliscono non provo nemmeno a far girare quelli di modifica.
Ovviamente tutto ciò ha senso solo per grossi progetti, che hanno
realmente bisogno di tutta questa flessibilità. Per tutto il resto uso
JUnit.
Testo... e sono felice :)
--
www.megadix.it


Il discorso dei test parametrici ti è mai servito?



Uhm, no. Troppo "oscuro"... e poi per la configurazione basta
includere il file giusto con Spring (magari dal classpath) e stai a
posto.
Secondo me i test dovrebbero essere banali nella loro semplicità,
mettersi a fare "acrobazie" e tecnicismi di questo genere... beh il
team tende a scrivere meno test se ogni volta si deve leggere un
manuale così!!
--
www.megadix.it

 1) i gruppi di test.
L'equivalente di una TestSuite in JUnit?

 L'equivalente di una TestSuite in JUnit?
Hai ragione, anche in JUnit si possono raggruppare più test, tramite
appunto le TestSuite.
Volendo si possono anche creare delle dipendenze inventandosi qualche
diavoleria...
Beh diciamo allora che la feature "gold" sono le dipendenze, giusto
perché è facile implementarle ;)
Poi ognuno usa gli strumenti con cui si trova meglio
--
www.megadix.it



Penso intendesse i dataproviders di TestNG: 
http://testng.org/doc/documentation-main.html#parameters-dataproviders
Parlavi della stessa cosa?

 Parlavi della stessa cosa?


 Quante cazzate! :-)
e invece lui e' quello che ha capito piu' di tutti.
TN

 fatta perch li avremmo prontamente bastonati.
Forse questo e' un metodo che puo' funzionare in Cina o nella Russia
di Stalin, ma non puoi applicarlo a un team affiatato di programmatori
skillati. Senno' rischi che siano loro a mandarti a fare in cucco,
come sta ormai succedendo nella mia azienda dove, con alcune decisioni
prese al modo dei fasci, hanno distrutto irrimediabilmente un team
unito, che funzionava. Devi capire che il successo della tua azienda
dipende soprattutto dalle piccole formiche che fanno il lavoro e i
soldi per te. Tutte queste novita' "americane" saranno utili finche
vuoi, ma l'equivoco in cui spesso cadono i signori del management e'
credere che i programmi si scrivano da soli e che introdurre nuove
procedure di business possa risolvere i problemi spesso causati dalla
loro inettitudine.
Nel frattempo mi sono licenziato :) Fan culo loro e il loro Maven di
m..... Mi apro un pub e vado a spinare birre.
TN

 m..... Mi apro un pub e vado a spinare birre.
Ti sei veramente licenziato? Solo per il maven?
E' adesso dove vai a lavorare?



A 'sto punto sento puzza di trollata...
Spero per lui che non abbia gettato al vento la propria carriera per
un capriccio del genere! Beh forse va bene così, se c'è la possibilità
di fare un lavoro più adatto, tanto meglio. Evidentemente fare il
programmatore non è la strada giusta.
Ma scusate una cosa: ho solo io l'impressione che questa professione
abbia bisogno di aggiornamento continuo, comprese cose che non
piacciono? Sapete ci ho provato a scrivere un web-service in GW-BASIC
ma mi sono dovuto riscrivere lo stack tcp-ip, ssl, http, parsing xml,
poi però ho finito le 65535 righe e sono tornato al caro vecchio:
10 PRINT "Pippo"
20 GOTO 10
--
www.megadix.it

 m..... Mi apro un pub e vado a spinare birre.
lo potevi dire subito che non c'eri trombato per quel lavoro, invece di 
metter su tutta quella pantomima assurda del gruppo skillato e produttivo 
che si sfalda per colpa di maven... adesso abbiamo capito, quello che è 
successo è che qualcuno è entrato turbando il vostro equilibrio di 
compagni di merende. 
ah, dimenticavo: nei pub i clienti *ordinano*. no, te lo dico perchè 
potresti rimanerne deluso... 
-- 
++ Fino all'anno scorso avevo un solo difetto. Ero presuntuoso.
http://unopuntozero.wordpress.com/
http://www.flickr.com/photos/marko_po/

 potresti rimanerne deluso...
no, scherzavo, vado a fare ancora il programmatore. Altra azienda
altri problemi, ma almeno per un po' si respira aria nuova...
grazie a tutti,
TN


Dalla versione 4.5 di Junit hanno aggiunto le @Category non so se sono 
una cosa equivalemnte ai gruppi di TestNG.
http://junit.sourceforge.net/doc/ReleaseNotes4.4.html


 campare.
Il capitale umano si concretizza anche in cose come "una corretta 
gestione del progetto (magari usando Maven)".

 
Continuo a non capire cosa c'entri maven in tutta questa storia.
