On 21/12/2010 4:06 AM, Hauschel Fred Robert wrote:
Hi Ron,
thank you very much for your hint!
We are actual converting a "historical" ant builded project to maven.
Profiles are really a bad way to solve our problems, but in the moment it is "a 
way" to get the whole stuff running and be able to provide a release.

Providing configuration is just one problem, that we actually solve with 
profiles!
The major problem is to provide separate different dependencies for m2Eclipse 
and tomcat in the webapps.
We solve this with profiles and properties:

parentPom:

        <profiles>
                <profile>
                        <id>container</id>
                        <properties>
                                <scope>provided</scope>
                        </properties>
                </profile>
                <profile>
                        <id>eclipse</id>
                        <activation>
                                <activeByDefault>true</activeByDefault>
                        </activation>
                        <properties>
                                <scope>compile</scope>
                        </properties>
                </profile>
        </profiles>

ModulePom:
        <profiles>
                <profile>
                        <id>dependencies</id>
                        <activation>
                                <activeByDefault>true</activeByDefault>
                        </activation>
                        <dependencies>
                                <dependency>
                                        <groupId>commons-logging</groupId>
                                        <artifactId>commons-logging</artifactId>
                                        <scope>${scope}</scope>
                                </dependency>
                                <dependency>
                                        <groupId>xyz<groupId>
                                        <artifactId>xyz_common</artifactId>
                                        <scope>${scope}</scope>
                                </dependency>
                        </dependencies>
                </profile>
        </profiles>


That works for now, but we are not really happy yet!
We will provide all dependencies in tomcat/lib so we actual have all dependencies 
"provided" in our libraries.
We did the same thing.
I have described the process that we used rather often in the forum so everyone else can ignore this post.:-) We created a series of libraries containing the "authorized" dependencies - hibernate-spring-mysql-tomcat, jsf, jasperreports, apachecommons, CXF, our_utilities, etc. (about 10 in total). The modules (about 60-70) just have the dependency scopes on these as "provided" (usually 4 or 5 are all that is required) with the version specified in the parent pom that corresponds to the version that they are building. Once the module POM is set up the only the only change that regularly happens is to the parent version.

On the deployment side, set up the JNDI for the environment, copy the correct libraries into tomcat/lib and load up the war files.
So each webApp have to define it's dependencies (again), transitive dependencies are 
"switched off".
Yes. That is what scope "provided" means - Need the dependency for compile but do not include the classes in the artifact being built.

The other way would be to use the default (compile) dependencies in the 
libraries and exclude all transitive dependencies for production build.

The libraries manage all of the exclusions to remove redundant libraries and ensure that the "right" versions of common libraries(log4j and all the handy apache and ORACLE/Sun stuff) are used without the module developers having to worry about it.
The war files are very small.
Any better idea ?

We think so.

Ron
Fredy

-----Ursprüngliche Nachricht-----
Von: Ron Wheeler [mailto:[email protected]]
Gesendet: Montag, 20. Dezember 2010 16:33
An: [email protected]
Betreff: Re: AW: releas:perform with profiles fails

On 20/12/2010 10:20 AM, Hauschel Fred Robert wrote:
Found a workarround:

http://www.tutorials.de/java/347377-maven-release-plugin-und-profile-activation.html

Fredy
You will be back.
Search this forum for discussions of profiles and environments.
The road to Maven hell is paved with profiles.

Just as "good intentions" are wonderful on their own, profiles can lead
you to do things that will get you into bad situations.
Not to say that they are evil in themselves and do not have good uses.
This is not one of them.

Ron
-----Ursprüngliche Nachricht-----
Von: Hauschel Fred Robert [mailto:[email protected]]
Gesendet: Montag, 20. Dezember 2010 15:23
An: Maven Users List
Betreff: releas:perform with profiles fails

Hi list,
I've a multi module with differences between the prod and dev
environment. Threfor I've defined some profiles.
"mvn clean install -P devContainerSettings,dependencies,!eclipse" works
fine!

but  "mvn --batch-mode release:prepare -P
devContainerSettings,dependencies,!eclipse" fails with compilations
errors!

Any idea??

Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
Java version: 1.6.0_21
Java home: C:\Program Files\Java\jdk1.6.0_21\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"

Fredy

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]




---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to