Newsgroup: it.comp.java
Titolo: Maven profile

Scusate di punto in bianco Maven non mi carica più il profili che
indico ma solo l'ultimo inserito, ed è molto strano perché prima è
sempre andato.
i miei profili sono:
<profiles>
	<profile>
		<id>prod</id>
		<properties>
			<jdbc.url><![CDATA[jdbc:oracle:thin:@URL-PROD]]></jdbc.url>
			<jdbc.username>USER-PROD</jdbc.username>
			<jdbc.password>PW-PROD</jdbc.password>
		</properties>
	</profile>
	<profile>
		<id>dev</id>
		<properties>
			<jdbc.url><![CDATA[jdbc:oracle:thin:@URL-DEV]]></jdbc.url>
			<jdbc.username>USER-DEV</jdbc.username>
			<jdbc.password>PW-DEV</jdbc.password>
		</properties>
	</profile>
	<profile>
		<id>local</id>
		<properties>
			<jdbc.url><![CDATA[jdbc:oracle:thin:@URL-LOCAL]]></jdbc.url>
			<jdbc.username>USER-LOCAL</jdbc.username>
			<jdbc.password>PW-LOCAL</jdbc.password>
		</properties>
	</profile>
</profiles>
ed ovviamente ho in un file di properties:
jdbcdburl = ${jdbc.url}
schema = ${jdbc.username}
password = ${jdbc.password}
prima quando eseguivo un qualsiasi comando maven, per sempio la
compilazione:
mvn clean compile -Pdev
nel file di properties venivano inseriti i valori corretti presenti
nel profile
ora invece inserisce sempre quelli di local (perché è l'ultimo della
lista) come se eseguissi sempre:
mvn clean compile -Plocal
Qualcuno può dirmi cosa può essere successo?
Ho semplicemente cambiato delle dependencies nel fiel di pom, ma anche
tornando alla situazione precedente da questo problema, cosa potrei
fare?
ovviamente nel file di pom è presente:
	<build>
		<resources>
			<resource>
				<filtering>true</filtering>
				<directory>src/main/resources</directory>
			</resource>
		</resources>
<!-- ... -->
	</build>
grazie

Il problema sembra essere dato dal fatto che uso il file esterno
profiles.xml e pare essere un bug:
http://jira.codehaus.org/browse/MNG-3788
al momento sono obbligato ad includere tutto nel pom, ma la cosa
strana è che prima il profiles.xml funzionava, qualsiasi idea di come
poter tornare ad utilizzare il comodissimo profiles.xml è  ben
accetta ;-)


 accetta ;-)
Io lo uso regolarmente e funziona!
Non è che stai usando in un modulo un profiles.xml definito nel padre?
Lucio
-- 
Lucio Benfante
JUG Padova           
http://www.parancoe.org
 ...have a look at it!
www.jugpadova.it
 
http://www.jugevents.org


Esatto, probabilmente il bug deriva da quello, ma è così comodo avere
un pom padre dove definire le dipendenze comuni :-P
Spero che lo mettano a posto nelle future versioni.

 Spero che lo mettano a posto nelle future versioni.
Non penso che lo metteranno a posto, dato che è frutto di una scelta 
progettuale (abbastanza) precisa: i profili non vengono ereditati dai 
sottomoduli, ma solo i loro effetti.
Dalle mie prove questo ha conseguenze principalmente sulle regole di 
attivazione, che io ho aggirato rendendole esplicite usando 
activeByDefault true o false (a seconda che un profile debba essere 
sempre attivato o meno), e aggiungendo una lista di active profiles per 
quelli che a volte devono essere attivati o no.
Ad esempio:
<?xml version="1.0" encoding="UTF-8"?>
<profilesXml xmlns="
http://maven.apache.org/POM/4.0.0
" 
xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance
"
   xsi:schemaLocation="
http://maven.apache.org/POM/4.0.0
 
http://maven.apache.org/xsd/profiles-1.0.0.xsd
">
    <profiles>
        <profile>
            <id>p1</id>
            <activation>
                <activeByDefault>true</activeByDefault>
            </activation>
            <properties>
              <prop1>val1</prop1>
            </properties>
        </profile>
        <profile>
            <id>p2</id>
            <activation>
                <activeByDefault>false</activeByDefault>
            </activation>
            <properties>
              <prop2>val2</prop2>
            </properties>
        </profile>
        <profile>
            <id>p3</id>
            <activation>
                <activeByDefault>false</activeByDefault>
            </activation>
            <properties>
              <prop2>val3</prop2>
            </properties>
        </profile>
    </profiles>
    <activeProfiles>
        <activeProfile>p2</activeProfile>
    </activeProfiles>
</profilesXml>
Il profilo p1 è sempre attivo. I profili p2 e p3 invece sono alternativi 
(a volte voglio p2 e a volte p3...ad esempio se faccio un build sotto 
Linux o sotto Windows) e attivo esplicitamente l'uno o l'altro nella 
lista degli activeProfiles.
Non c'entra molto con questo. Tu hai detto che è "comodo avere un pom 
padre dove definire le dipendenze comuni". Secondo me invece, per quanto 
riguarda le dipendenze, non va fatto (definire le dipendenze nel pom 
padre). Sono veramente rare le dipendenze comuni a tutti i moduli (una 
potrebbe essere la libreria di test, ma non me ne vengono in mente 
altre). Con l'evoluzione del progetto ti capiterà sicuramente un modulo 
che non ha certe dipendenze, e invece te le ritrovi nel padre. Molto 
meglio sfruttare invece la transitività delle dipendenze dagli altri 
moduli. IMHO
Ciao


    xsi:schemaLocation="
http://maven.apache.org/POM/4.0.0http://maven.apache.org/xsd/profiles-1.0.0.xsd
">

Concordo con Lucio, ovviamente.
Per quanto riguarda la dipendenze comuni c'e' comunque la possibilità
di definire nel padre delle dipendenze specificando groupId,
artifactId, e version (mi sembra  con il tag dependencyManagement).
I figli, poi, possono riferirsi a queste tramite groupId, artifactId,
*mentre possono omettere il version*! Cosa piuttosto comoda per poter
cambiare in un colpo solo la *versione* di alcune delle tue
dipendenze.

 altre).
In effetti non mi riferivo alle librerie (a parte junit), ma per
dipendenze comuni intendevo cose del tipo jdk di compilazione,
filtering dei file di properties, un file dist unico, team di
sviluppo ... ;-)

 dipendenze.
Strano a dire il vero nel pom padre (all'interno di
"dependencyManagement") ho dovuto mettere il numero di versione per
ogni modulo, il che non è particolarmente gravoso visto che basta
mettere "<version>${version}</version>".
Però nei pom figli all'interno del tag "parent" il tag "version" deve
avere il numero di versione esplicito (per esempio "1.0.0") altrimenti
non va.

 non va.
Ovviamente hai la comodità di non dover mettere esplicitamente il
numero di versione del modulo, ma devi comunque mettere esplicitare
quello del padre ;-)

 quello del padre ;-)
Ma che problemi ti da il dover specificare la versione del padre? Lo
devi fare una volta sola e poi basta.


Lo devo specificare una volta nel pom figlio.
Se metto:
<project>
	<parent>
		<groupId>my.pac</groupId>
		<artifactId>my-app</artifactId>
		<version>1.0.0</version>
	</parent>
	<modelVersion>4.0.0</modelVersion>
	<artifactId>my-child</artifactId>
	<name>My Child App</name>
	<build>
...
</project>
tutto OK
Se metto:
<project>
	<parent>
		<groupId>my.pac</groupId>
		<artifactId>my-app</artifactId>
	</parent>
	<modelVersion>4.0.0</modelVersion>
	<artifactId>my-child</artifactId>
	<name>My Child App</name>
	<build>
...
</project>
Mi da:
C:\workspace\my-app>mvn clean compile
[INFO] Scanning for projects...
[INFO]
------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).
Project ID: unknown:my-child
Reason: Missing version element from parent element for project
unknown:my-child
[INFO]
------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.reactor.MavenExecutionException: Missing version
element from parent element for project unknown:my-child
        at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:
378)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:
292)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:
129)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:302)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
57)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
43)
        at java.lang.reflect.Method.invoke(Method.java:623)
        at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
        at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
        at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
        at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.project.ProjectBuildingException: Missing
version element from parent element for project unknown:my-child
        at
org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:
1251)
        at
org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:
824)
        at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:
509)
        at
org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:
201)
        at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:
578)
        at
org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:461)
        at
org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:534)
        at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:
365)
        ... 11 more
[INFO]
------------------------------------------------------------------------
[INFO] Total time: < 1 second
[INFO] Finished at: Tue Nov 11 17:31:01 CET 2008
[INFO] Final Memory: 1M/4M
[INFO]
------------------------------------------------------------------------
C:\workspace\my-app>



Intendevo, lo devi specificare una volta nel tempo, per ogni pom.xml. Ma 
solo una volta, e quindi non crea alcun problema di manutenzione.