You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Piotr Skawinski <pi...@gmail.com> on 2010/12/20 14:50:21 UTC
release:prepare does not inherit plugins from the parent project?
Hi,
I'm having problems using release:prepare plugin on a project that inherits
from a parent project. It seems that it cannot see the plugins from the
parent project and fails on compiling java vesion 1.6 classes claiming that
1.3 version does not support annotations. It works fine with clean install.
The maven-compiler-plugin is defined in the parent project. What can be the
problem?
thanks in advance,
Piotr
Re: AW: AW: AW: AW: releas:perform with profiles fails
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 22/12/2010 3:58 AM, Hauschel Fred Robert wrote:
> Hi Ron,
> so we are now speaking about a m2Eclipse problem, and that is the wrong list!
>
> Example: You have a webApp<packaging>war</packaging> and in it a dependency to (for example) commons-logging with scope provided.
> If you now use commons-logging in a servlet, and run your webapp in eclipse (WTP - run on srever), so the classpath will not contain
> commons-logging.
>
> Can you conform that ??
>
Since it is scope "provided", you must provide provide it. Your server
must be set up to have commons-logging in its classpath.
We have aggregation projects that create jars that combine many
artifacts so that we only have to install a few jars (10) in the server
(tomcat/lib in our case) to get the 70+ 3rd party libraries that we need.
This means that in order to set up a test or production environment for
a release, we have to install the aggregation JARs and set up the JNDI
on the server.
This is only done once.
Ron
> Fredy
>
>
> -----Ursprüngliche Nachricht-----
> Von: Ron Wheeler [mailto:rwheeler@artifact-software.com]
> Gesendet: Mittwoch, 22. Dezember 2010 09:35
> An: users@maven.apache.org
> Betreff: Re: AW: AW: AW: releas:perform with profiles fails
>
> On 22/12/2010 2:56 AM, Hauschel Fred Robert wrote:
>> See inline...
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Ron Wheeler [mailto:rwheeler@artifact-software.com]
>> Gesendet: Dienstag, 21. Dezember 2010 17:17
>> An: users@maven.apache.org
>> Betreff: Re: AW: AW: releas:perform with profiles fails
>>
>> On 21/12/2010 4:28 AM, Hauschel Fred Robert wrote:
>>> Ok, maybe "<packagingExcludes>WEB-INF/lib/*.jar</packagingExcludes>"
>>> Explained in http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html is a better way ;-)
>>>
>> Sounds like too much work to copy a bunch of libraries into each project
>> and then exclude them when maven already has a transitive dependency
>> mechanism that supports scope "provided".
>>
>> [HF:] Maybe! But m2Eclipse plugin does not use provided libraries in it's classpath for wtp projects.
> Are you sure?
> It seems to work for us with no problems but perhaps I don't understand
> where you ran into the problems.
> With Eclipse/STS we are also insulated from plug-ins since they all come
> pre-installed.
>> And our goal is to make it as simple as possible for the developers. Maybe this is the problem ,-)
> That is what we did as well. Simple parent POM, small set of
> dependencies. 3rd party dependencies all neatly packaged up when a new
> release is planned.
> Modules are easy to construct and the Maven tasks are just a click on a
> menu.
> No profiles, no custom plug-ins only 3 or 4 standard Maven plug-in are
> used to build a portal that has over 60 Web services, JSF, portlets,
> servlets and batch jobs.
> Libraries are very stable and we know exactly what versions of 3rd party
> software are included in any version of the application.
>
>> Thanks for your help, we will see, how to solve the "thing".
>>
> You are quite welcome.
> Good luck with getting this setup.
>
> Ron
>
>>> Fredy
>>>
>>>
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Hauschel Fred Robert [mailto:FredRobert.Hauschel@Cirquent.de]
>>> Gesendet: Dienstag, 21. Dezember 2010 10:06
>>> An: Maven Users List
>>> Betreff: AW: AW: releas:perform with profiles fails
>>>
>>> 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.
>>> So each webApp have to define it's dependencies (again), transitive dependencies are "switched off".
>>> The other way would be to use the default (compile) dependencies in the libraries and exclude all transitive dependencies for production build.
>>>
>>> Any better idea ?
>>>
>>> Fredy
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Ron Wheeler [mailto:rwheeler@artifact-software.com]
>>> Gesendet: Montag, 20. Dezember 2010 16:33
>>> An: users@maven.apache.org
>>> 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:FredRobert.Hauschel@Cirquent.de]
>>>> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
AW: AW: AW: AW: releas:perform with profiles fails
Posted by Hauschel Fred Robert <Fr...@Cirquent.de>.
Hi Ron,
so we are now speaking about a m2Eclipse problem, and that is the wrong list!
Example: You have a webApp <packaging>war</packaging> and in it a dependency to (for example) commons-logging with scope provided.
If you now use commons-logging in a servlet, and run your webapp in eclipse (WTP - run on srever), so the classpath will not contain
commons-logging.
Can you conform that ??
Fredy
-----Ursprüngliche Nachricht-----
Von: Ron Wheeler [mailto:rwheeler@artifact-software.com]
Gesendet: Mittwoch, 22. Dezember 2010 09:35
An: users@maven.apache.org
Betreff: Re: AW: AW: AW: releas:perform with profiles fails
On 22/12/2010 2:56 AM, Hauschel Fred Robert wrote:
> See inline...
>
> -----Ursprüngliche Nachricht-----
> Von: Ron Wheeler [mailto:rwheeler@artifact-software.com]
> Gesendet: Dienstag, 21. Dezember 2010 17:17
> An: users@maven.apache.org
> Betreff: Re: AW: AW: releas:perform with profiles fails
>
> On 21/12/2010 4:28 AM, Hauschel Fred Robert wrote:
>> Ok, maybe "<packagingExcludes>WEB-INF/lib/*.jar</packagingExcludes>"
>> Explained in http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html is a better way ;-)
>>
> Sounds like too much work to copy a bunch of libraries into each project
> and then exclude them when maven already has a transitive dependency
> mechanism that supports scope "provided".
>
> [HF:] Maybe! But m2Eclipse plugin does not use provided libraries in it's classpath for wtp projects.
Are you sure?
It seems to work for us with no problems but perhaps I don't understand
where you ran into the problems.
With Eclipse/STS we are also insulated from plug-ins since they all come
pre-installed.
> And our goal is to make it as simple as possible for the developers. Maybe this is the problem ,-)
That is what we did as well. Simple parent POM, small set of
dependencies. 3rd party dependencies all neatly packaged up when a new
release is planned.
Modules are easy to construct and the Maven tasks are just a click on a
menu.
No profiles, no custom plug-ins only 3 or 4 standard Maven plug-in are
used to build a portal that has over 60 Web services, JSF, portlets,
servlets and batch jobs.
Libraries are very stable and we know exactly what versions of 3rd party
software are included in any version of the application.
> Thanks for your help, we will see, how to solve the "thing".
>
You are quite welcome.
Good luck with getting this setup.
Ron
>> Fredy
>>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Hauschel Fred Robert [mailto:FredRobert.Hauschel@Cirquent.de]
>> Gesendet: Dienstag, 21. Dezember 2010 10:06
>> An: Maven Users List
>> Betreff: AW: AW: releas:perform with profiles fails
>>
>> 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.
>> So each webApp have to define it's dependencies (again), transitive dependencies are "switched off".
>> The other way would be to use the default (compile) dependencies in the libraries and exclude all transitive dependencies for production build.
>>
>> Any better idea ?
>>
>> Fredy
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Ron Wheeler [mailto:rwheeler@artifact-software.com]
>> Gesendet: Montag, 20. Dezember 2010 16:33
>> An: users@maven.apache.org
>> 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:FredRobert.Hauschel@Cirquent.de]
>>> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: AW: AW: AW: releas:perform with profiles fails
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 22/12/2010 2:56 AM, Hauschel Fred Robert wrote:
> See inline...
>
> -----Ursprüngliche Nachricht-----
> Von: Ron Wheeler [mailto:rwheeler@artifact-software.com]
> Gesendet: Dienstag, 21. Dezember 2010 17:17
> An: users@maven.apache.org
> Betreff: Re: AW: AW: releas:perform with profiles fails
>
> On 21/12/2010 4:28 AM, Hauschel Fred Robert wrote:
>> Ok, maybe "<packagingExcludes>WEB-INF/lib/*.jar</packagingExcludes>"
>> Explained in http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html is a better way ;-)
>>
> Sounds like too much work to copy a bunch of libraries into each project
> and then exclude them when maven already has a transitive dependency
> mechanism that supports scope "provided".
>
> [HF:] Maybe! But m2Eclipse plugin does not use provided libraries in it's classpath for wtp projects.
Are you sure?
It seems to work for us with no problems but perhaps I don't understand
where you ran into the problems.
With Eclipse/STS we are also insulated from plug-ins since they all come
pre-installed.
> And our goal is to make it as simple as possible for the developers. Maybe this is the problem ,-)
That is what we did as well. Simple parent POM, small set of
dependencies. 3rd party dependencies all neatly packaged up when a new
release is planned.
Modules are easy to construct and the Maven tasks are just a click on a
menu.
No profiles, no custom plug-ins only 3 or 4 standard Maven plug-in are
used to build a portal that has over 60 Web services, JSF, portlets,
servlets and batch jobs.
Libraries are very stable and we know exactly what versions of 3rd party
software are included in any version of the application.
> Thanks for your help, we will see, how to solve the "thing".
>
You are quite welcome.
Good luck with getting this setup.
Ron
>> Fredy
>>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Hauschel Fred Robert [mailto:FredRobert.Hauschel@Cirquent.de]
>> Gesendet: Dienstag, 21. Dezember 2010 10:06
>> An: Maven Users List
>> Betreff: AW: AW: releas:perform with profiles fails
>>
>> 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.
>> So each webApp have to define it's dependencies (again), transitive dependencies are "switched off".
>> The other way would be to use the default (compile) dependencies in the libraries and exclude all transitive dependencies for production build.
>>
>> Any better idea ?
>>
>> Fredy
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Ron Wheeler [mailto:rwheeler@artifact-software.com]
>> Gesendet: Montag, 20. Dezember 2010 16:33
>> An: users@maven.apache.org
>> 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:FredRobert.Hauschel@Cirquent.de]
>>> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
AW: AW: AW: releas:perform with profiles fails
Posted by Hauschel Fred Robert <Fr...@Cirquent.de>.
See inline...
-----Ursprüngliche Nachricht-----
Von: Ron Wheeler [mailto:rwheeler@artifact-software.com]
Gesendet: Dienstag, 21. Dezember 2010 17:17
An: users@maven.apache.org
Betreff: Re: AW: AW: releas:perform with profiles fails
On 21/12/2010 4:28 AM, Hauschel Fred Robert wrote:
> Ok, maybe "<packagingExcludes>WEB-INF/lib/*.jar</packagingExcludes>"
> Explained in http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html is a better way ;-)
>
Sounds like too much work to copy a bunch of libraries into each project
and then exclude them when maven already has a transitive dependency
mechanism that supports scope "provided".
[HF:] Maybe! But m2Eclipse plugin does not use provided libraries in it's classpath for wtp projects. And our goal is to make it as simple as possible for the developers. Maybe this is the problem ,-) Thanks for your help, we will see, how to solve the "thing".
> Fredy
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Hauschel Fred Robert [mailto:FredRobert.Hauschel@Cirquent.de]
> Gesendet: Dienstag, 21. Dezember 2010 10:06
> An: Maven Users List
> Betreff: AW: AW: releas:perform with profiles fails
>
> 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.
> So each webApp have to define it's dependencies (again), transitive dependencies are "switched off".
> The other way would be to use the default (compile) dependencies in the libraries and exclude all transitive dependencies for production build.
>
> Any better idea ?
>
> Fredy
>
> -----Ursprüngliche Nachricht-----
> Von: Ron Wheeler [mailto:rwheeler@artifact-software.com]
> Gesendet: Montag, 20. Dezember 2010 16:33
> An: users@maven.apache.org
> 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:FredRobert.Hauschel@Cirquent.de]
>> 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: AW: AW: releas:perform with profiles fails
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 21/12/2010 4:28 AM, Hauschel Fred Robert wrote:
> Ok, maybe "<packagingExcludes>WEB-INF/lib/*.jar</packagingExcludes>"
> Explained in http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html is a better way ;-)
>
Sounds like too much work to copy a bunch of libraries into each project
and then exclude them when maven already has a transitive dependency
mechanism that supports scope "provided".
> Fredy
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Hauschel Fred Robert [mailto:FredRobert.Hauschel@Cirquent.de]
> Gesendet: Dienstag, 21. Dezember 2010 10:06
> An: Maven Users List
> Betreff: AW: AW: releas:perform with profiles fails
>
> 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.
> So each webApp have to define it's dependencies (again), transitive dependencies are "switched off".
> The other way would be to use the default (compile) dependencies in the libraries and exclude all transitive dependencies for production build.
>
> Any better idea ?
>
> Fredy
>
> -----Ursprüngliche Nachricht-----
> Von: Ron Wheeler [mailto:rwheeler@artifact-software.com]
> Gesendet: Montag, 20. Dezember 2010 16:33
> An: users@maven.apache.org
> 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:FredRobert.Hauschel@Cirquent.de]
>> 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
AW: AW: releas:perform with profiles fails
Posted by Hauschel Fred Robert <Fr...@Cirquent.de>.
Ok, maybe "<packagingExcludes>WEB-INF/lib/*.jar</packagingExcludes>"
Explained in http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html is a better way ;-)
Fredy
-----Ursprüngliche Nachricht-----
Von: Hauschel Fred Robert [mailto:FredRobert.Hauschel@Cirquent.de]
Gesendet: Dienstag, 21. Dezember 2010 10:06
An: Maven Users List
Betreff: AW: AW: releas:perform with profiles fails
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.
So each webApp have to define it's dependencies (again), transitive dependencies are "switched off".
The other way would be to use the default (compile) dependencies in the libraries and exclude all transitive dependencies for production build.
Any better idea ?
Fredy
-----Ursprüngliche Nachricht-----
Von: Ron Wheeler [mailto:rwheeler@artifact-software.com]
Gesendet: Montag, 20. Dezember 2010 16:33
An: users@maven.apache.org
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:FredRobert.Hauschel@Cirquent.de]
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: AW: AW: releas:perform with profiles fails
Posted by Ron Wheeler <rw...@artifact-software.com>.
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:rwheeler@artifact-software.com]
> Gesendet: Montag, 20. Dezember 2010 16:33
> An: users@maven.apache.org
> 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:FredRobert.Hauschel@Cirquent.de]
>> 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
AW: AW: releas:perform with profiles fails
Posted by Hauschel Fred Robert <Fr...@Cirquent.de>.
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.
So each webApp have to define it's dependencies (again), transitive dependencies are "switched off".
The other way would be to use the default (compile) dependencies in the libraries and exclude all transitive dependencies for production build.
Any better idea ?
Fredy
-----Ursprüngliche Nachricht-----
Von: Ron Wheeler [mailto:rwheeler@artifact-software.com]
Gesendet: Montag, 20. Dezember 2010 16:33
An: users@maven.apache.org
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:FredRobert.Hauschel@Cirquent.de]
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: AW: releas:perform with profiles fails
Posted by Ron Wheeler <rw...@artifact-software.com>.
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:FredRobert.Hauschel@Cirquent.de]
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
AW: releas:perform with profiles fails
Posted by Hauschel Fred Robert <Fr...@Cirquent.de>.
Found a workarround:
http://www.tutorials.de/java/347377-maven-release-plugin-und-profile-activation.html
Fredy
-----Ursprüngliche Nachricht-----
Von: Hauschel Fred Robert [mailto:FredRobert.Hauschel@Cirquent.de]
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: releas:perform with profiles fails
Posted by Ron Wheeler <rw...@artifact-software.com>.
http://blog.artifact-software.com/tech/ includes a blog entry on using
JNDI to get environment stuff out of projects.
Got tired of writing it every week here.
Putting environmental stuff inside your modules is a recipe for long
frustrating Maven discussions and hours of fruitless screwing about.
If you want anyone to guess as to what causes a compilation error, you
will have to give us some hints about it.
What error?
What does Maven say is happening?
Separation of concerns between development and deployment will make both
sides of the job much easier and much less prone to run-time screw-ups
in production.
As you get further into the process, you will likely get a lot more
environments to support - current production, customer acceptance
testing, pre-release testing, integration testing, localhost testing,
etc. If you have customization for customers or multiple releases in
production, your problems multiply.
Get the deployment stuff out of your codebase ASAP.
Ron
On 20/12/2010 9:23 AM, Hauschel Fred Robert wrote:
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
releas:perform with profiles fails
Posted by Hauschel Fred Robert <Fr...@Cirquent.de>.
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: release:prepare does not inherit plugins from the parent project?
Posted by Anders Hammar <an...@hammar.net>.
Analyzing the debug and error output should also give a clue. Maybe focus on
that and ignore the effective pom for now.
/Anders (mobile)
Den 20 dec 2010 17.05 skrev "Ron Wheeler" <rw...@artifact-software.com>:
> Where is the reference to 1.3 coming from?
> I think that was what the effective-pom was for, not to see if the
> plug-ins were there but to find out who is asking for 1.3.
>
> Ron
>
>
> On 20/12/2010 10:05 AM, Piotr Skawinski wrote:
>> Hi again,
>>
>> Actually when running mvn help:effective-pom I can see all plugins from
the
>> parent as expected, but when running it after release:prepare (which
>> actually faills) they are not there anymore. It seems that
release:prepare
>> ignores the parent's plugins for the project it runs the release for.
>> Though, when plugins are defined in the project's scope and not the
parent's
>> the release:prepare works as expected. The plugin in the parent is
defines
>> parent as follows:
>>
>> <project>
>> .
>> .
>> .
>> <build>
>> <plugins>
>> <plugin>
>> <groupId>org.apache.maven.plugins</groupId>
>> <artifactId>maven-compiler-plugin</artifactId>
>> <version>2.0.2</version>
>> <configuration>
>> <source>1.6</source>
>> <target>1.6</target>
>> <encoding>UTF-8</encoding>
>> </configuration>
>> </plugin>
>> <plugins>
>> <build>
>> <project>
>>
>>
>> Piotr
>>
>>
>>
>> On Mon, Dec 20, 2010 at 2:57 PM, Anders Hammar<an...@hammar.net> wrote:
>>
>>> Check the project's effective pom.
>>> mvn help:effective-pom
>>>
>>> Most likely what you think should be inherited isn't. How is
m-compiler-p
>>> declared in the parent?
>>>
>>> /Anders
>>>
>>> On Mon, Dec 20, 2010 at 14:50, Piotr Skawinski<
>>> piotr.skawinski.maven@gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm having problems using release:prepare plugin on a project that
>>> inherits
>>>> from a parent project. It seems that it cannot see the plugins from the
>>>> parent project and fails on compiling java vesion 1.6 classes claiming
>>> that
>>>> 1.3 version does not support annotations. It works fine with clean
>>> install.
>>>> The maven-compiler-plugin is defined in the parent project. What can be
>>> the
>>>> problem?
>>>>
>>>> thanks in advance,
>>>>
>>>> Piotr
>>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Re: release:prepare does not inherit plugins from the parent project?
Posted by Anders Hammar <an...@hammar.net>.
Possibly generateReleasePoms=true could be the problem. It is now
deprecated, so I wouldn't be surprised if not too many people use it and/or
it's not tested fully.
I suggest that you stop using it. There's a separate goal for that if you
really need it.
Btw, I assume you have tried upgrading to the latest version of the plugin?
/Anders
On Wed, Dec 22, 2010 at 09:53, Piotr Skawinski <
piotr.skawinski.maven@gmail.com> wrote:
> The error occurs while using generateReleasePoms=true as configuration
> within maven-release-plugin. The maven-release-plugin will generate a
> release-pom.xml for the release and it is being used by maven for the
> build.
> Looking into release-pom.xml I dont see any reference to java 1.6 version
> which is defined within the plugins part in the parent project, so it is
> not
> strange why it fails on building java code with annotations, since maven
> uses java 1.3 version as default. My question is why release-pom.xml is not
> getting plugins from the parent project? Could it be that this is a bug
> inside maven-release-plugin? The release works fine with
> generateReleasePoms=false.
>
> Piotr
>
> On Tue, Dec 21, 2010 at 5:31 PM, Ron Wheeler <
> rwheeler@artifact-software.com
> > wrote:
>
> > On 21/12/2010 6:40 AM, Piotr Skawinski wrote:
> >
> >> Hi Ron,
> >>
> >> There's actually no reference to 1.3, that is what what makes it strange
> >> :)
> >> The m-compiler-p is defined in the parent pom to use version 1.6, but
> >> somehow seems to be ignored by release:prepare. Maven is using version
> 1.3
> >> to compile with per default, unless you define the java version through
> >> m-compiler-p, which I actually do. Though, it seems to be ignored by
> >> release:prepare. When running clean install it works fine. I don't quite
> >> understand what you mean by using effective-pom. I thought it was
> intented
> >> to be used especially in this cas to see the real pom seen by maven :)
> >>
> > Never seen any reference to 1.3 in anything that we have done with Maven
> > over the last 3 years.
> > We use Eclipse/STS as our IDE so we have GUI controls to set to control
> > Maven and it is pretty easy to see what compiler is being requested, what
> > JRE is being used for Maven tasks, etc.
> >
> > What IDE are you using and how do you build with Maven?
> >
> > I really like the Eclipse/STS from Springsource and everyone in the forum
> > is probably tired of hearing me mention it but it makes Eclipse a
> pleasure
> > to install (biggest reason we moved from standard eclipse) and it makes
> > Maven very easy to use.
> >
> > I am also a big fan of Sonotype's Nexus and really recommend getting a
> repo
> > as quickly as possible if you are going to use Maven.
> > Other repos also exist but I only know Nexus.
> >
> > Ron
> >
> >
> >
> > Piotr
> >>
> >> On Mon, Dec 20, 2010 at 5:04 PM, Ron Wheeler<
> >> rwheeler@artifact-software.com
> >>
> >>> wrote:
> >>> Where is the reference to 1.3 coming from?
> >>> I think that was what the effective-pom was for, not to see if the
> >>> plug-ins
> >>> were there but to find out who is asking for 1.3.
> >>>
> >>> Ron
> >>>
> >>>
> >>>
> >>> On 20/12/2010 10:05 AM, Piotr Skawinski wrote:
> >>>
> >>> Hi again,
> >>>>
> >>>> Actually when running mvn help:effective-pom I can see all plugins
> from
> >>>> the
> >>>> parent as expected, but when running it after release:prepare (which
> >>>> actually faills) they are not there anymore. It seems that
> >>>> release:prepare
> >>>> ignores the parent's plugins for the project it runs the release for.
> >>>> Though, when plugins are defined in the project's scope and not the
> >>>> parent's
> >>>> the release:prepare works as expected. The plugin in the parent is
> >>>> defines
> >>>> parent as follows:
> >>>>
> >>>> <project>
> >>>> .
> >>>> .
> >>>> .
> >>>> <build>
> >>>> <plugins>
> >>>> <plugin>
> >>>> <groupId>org.apache.maven.plugins</groupId>
> >>>> <artifactId>maven-compiler-plugin</artifactId>
> >>>> <version>2.0.2</version>
> >>>> <configuration>
> >>>> <source>1.6</source>
> >>>> <target>1.6</target>
> >>>> <encoding>UTF-8</encoding>
> >>>> </configuration>
> >>>> </plugin>
> >>>> <plugins>
> >>>> <build>
> >>>> <project>
> >>>>
> >>>>
> >>>> Piotr
> >>>>
> >>>>
> >>>>
> >>>> On Mon, Dec 20, 2010 at 2:57 PM, Anders Hammar<an...@hammar.net>
> >>>> wrote:
> >>>>
> >>>> Check the project's effective pom.
> >>>>
> >>>>> mvn help:effective-pom
> >>>>>
> >>>>> Most likely what you think should be inherited isn't. How is
> >>>>> m-compiler-p
> >>>>> declared in the parent?
> >>>>>
> >>>>> /Anders
> >>>>>
> >>>>> On Mon, Dec 20, 2010 at 14:50, Piotr Skawinski<
> >>>>> piotr.skawinski.maven@gmail.com> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>>> I'm having problems using release:prepare plugin on a project that
> >>>>>>
> >>>>>> inherits
> >>>>>
> >>>>> from a parent project. It seems that it cannot see the plugins from
> >>>>>> the
> >>>>>> parent project and fails on compiling java vesion 1.6 classes
> claiming
> >>>>>>
> >>>>>> that
> >>>>>
> >>>>> 1.3 version does not support annotations. It works fine with clean
> >>>>>>
> >>>>>> install.
> >>>>>
> >>>>> The maven-compiler-plugin is defined in the parent project. What can
> >>>>>> be
> >>>>>>
> >>>>>> the
> >>>>>
> >>>>> problem?
> >>>>>>
> >>>>>> thanks in advance,
> >>>>>>
> >>>>>> Piotr
> >>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: users-help@maven.apache.org
> >>>
> >>>
> >>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
Re: release:prepare does not inherit plugins from the parent project?
Posted by Piotr Skawinski <pi...@gmail.com>.
The error occurs while using generateReleasePoms=true as configuration
within maven-release-plugin. The maven-release-plugin will generate a
release-pom.xml for the release and it is being used by maven for the build.
Looking into release-pom.xml I dont see any reference to java 1.6 version
which is defined within the plugins part in the parent project, so it is not
strange why it fails on building java code with annotations, since maven
uses java 1.3 version as default. My question is why release-pom.xml is not
getting plugins from the parent project? Could it be that this is a bug
inside maven-release-plugin? The release works fine with
generateReleasePoms=false.
Piotr
On Tue, Dec 21, 2010 at 5:31 PM, Ron Wheeler <rwheeler@artifact-software.com
> wrote:
> On 21/12/2010 6:40 AM, Piotr Skawinski wrote:
>
>> Hi Ron,
>>
>> There's actually no reference to 1.3, that is what what makes it strange
>> :)
>> The m-compiler-p is defined in the parent pom to use version 1.6, but
>> somehow seems to be ignored by release:prepare. Maven is using version 1.3
>> to compile with per default, unless you define the java version through
>> m-compiler-p, which I actually do. Though, it seems to be ignored by
>> release:prepare. When running clean install it works fine. I don't quite
>> understand what you mean by using effective-pom. I thought it was intented
>> to be used especially in this cas to see the real pom seen by maven :)
>>
> Never seen any reference to 1.3 in anything that we have done with Maven
> over the last 3 years.
> We use Eclipse/STS as our IDE so we have GUI controls to set to control
> Maven and it is pretty easy to see what compiler is being requested, what
> JRE is being used for Maven tasks, etc.
>
> What IDE are you using and how do you build with Maven?
>
> I really like the Eclipse/STS from Springsource and everyone in the forum
> is probably tired of hearing me mention it but it makes Eclipse a pleasure
> to install (biggest reason we moved from standard eclipse) and it makes
> Maven very easy to use.
>
> I am also a big fan of Sonotype's Nexus and really recommend getting a repo
> as quickly as possible if you are going to use Maven.
> Other repos also exist but I only know Nexus.
>
> Ron
>
>
>
> Piotr
>>
>> On Mon, Dec 20, 2010 at 5:04 PM, Ron Wheeler<
>> rwheeler@artifact-software.com
>>
>>> wrote:
>>> Where is the reference to 1.3 coming from?
>>> I think that was what the effective-pom was for, not to see if the
>>> plug-ins
>>> were there but to find out who is asking for 1.3.
>>>
>>> Ron
>>>
>>>
>>>
>>> On 20/12/2010 10:05 AM, Piotr Skawinski wrote:
>>>
>>> Hi again,
>>>>
>>>> Actually when running mvn help:effective-pom I can see all plugins from
>>>> the
>>>> parent as expected, but when running it after release:prepare (which
>>>> actually faills) they are not there anymore. It seems that
>>>> release:prepare
>>>> ignores the parent's plugins for the project it runs the release for.
>>>> Though, when plugins are defined in the project's scope and not the
>>>> parent's
>>>> the release:prepare works as expected. The plugin in the parent is
>>>> defines
>>>> parent as follows:
>>>>
>>>> <project>
>>>> .
>>>> .
>>>> .
>>>> <build>
>>>> <plugins>
>>>> <plugin>
>>>> <groupId>org.apache.maven.plugins</groupId>
>>>> <artifactId>maven-compiler-plugin</artifactId>
>>>> <version>2.0.2</version>
>>>> <configuration>
>>>> <source>1.6</source>
>>>> <target>1.6</target>
>>>> <encoding>UTF-8</encoding>
>>>> </configuration>
>>>> </plugin>
>>>> <plugins>
>>>> <build>
>>>> <project>
>>>>
>>>>
>>>> Piotr
>>>>
>>>>
>>>>
>>>> On Mon, Dec 20, 2010 at 2:57 PM, Anders Hammar<an...@hammar.net>
>>>> wrote:
>>>>
>>>> Check the project's effective pom.
>>>>
>>>>> mvn help:effective-pom
>>>>>
>>>>> Most likely what you think should be inherited isn't. How is
>>>>> m-compiler-p
>>>>> declared in the parent?
>>>>>
>>>>> /Anders
>>>>>
>>>>> On Mon, Dec 20, 2010 at 14:50, Piotr Skawinski<
>>>>> piotr.skawinski.maven@gmail.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>> I'm having problems using release:prepare plugin on a project that
>>>>>>
>>>>>> inherits
>>>>>
>>>>> from a parent project. It seems that it cannot see the plugins from
>>>>>> the
>>>>>> parent project and fails on compiling java vesion 1.6 classes claiming
>>>>>>
>>>>>> that
>>>>>
>>>>> 1.3 version does not support annotations. It works fine with clean
>>>>>>
>>>>>> install.
>>>>>
>>>>> The maven-compiler-plugin is defined in the parent project. What can
>>>>>> be
>>>>>>
>>>>>> the
>>>>>
>>>>> problem?
>>>>>>
>>>>>> thanks in advance,
>>>>>>
>>>>>> Piotr
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: release:prepare does not inherit plugins from the parent project?
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 21/12/2010 6:40 AM, Piotr Skawinski wrote:
> Hi Ron,
>
> There's actually no reference to 1.3, that is what what makes it strange :)
> The m-compiler-p is defined in the parent pom to use version 1.6, but
> somehow seems to be ignored by release:prepare. Maven is using version 1.3
> to compile with per default, unless you define the java version through
> m-compiler-p, which I actually do. Though, it seems to be ignored by
> release:prepare. When running clean install it works fine. I don't quite
> understand what you mean by using effective-pom. I thought it was intented
> to be used especially in this cas to see the real pom seen by maven :)
Never seen any reference to 1.3 in anything that we have done with Maven
over the last 3 years.
We use Eclipse/STS as our IDE so we have GUI controls to set to control
Maven and it is pretty easy to see what compiler is being requested,
what JRE is being used for Maven tasks, etc.
What IDE are you using and how do you build with Maven?
I really like the Eclipse/STS from Springsource and everyone in the
forum is probably tired of hearing me mention it but it makes Eclipse a
pleasure to install (biggest reason we moved from standard eclipse) and
it makes Maven very easy to use.
I am also a big fan of Sonotype's Nexus and really recommend getting a
repo as quickly as possible if you are going to use Maven.
Other repos also exist but I only know Nexus.
Ron
> Piotr
>
> On Mon, Dec 20, 2010 at 5:04 PM, Ron Wheeler<rwheeler@artifact-software.com
>> wrote:
>> Where is the reference to 1.3 coming from?
>> I think that was what the effective-pom was for, not to see if the plug-ins
>> were there but to find out who is asking for 1.3.
>>
>> Ron
>>
>>
>>
>> On 20/12/2010 10:05 AM, Piotr Skawinski wrote:
>>
>>> Hi again,
>>>
>>> Actually when running mvn help:effective-pom I can see all plugins from
>>> the
>>> parent as expected, but when running it after release:prepare (which
>>> actually faills) they are not there anymore. It seems that release:prepare
>>> ignores the parent's plugins for the project it runs the release for.
>>> Though, when plugins are defined in the project's scope and not the
>>> parent's
>>> the release:prepare works as expected. The plugin in the parent is defines
>>> parent as follows:
>>>
>>> <project>
>>> .
>>> .
>>> .
>>> <build>
>>> <plugins>
>>> <plugin>
>>> <groupId>org.apache.maven.plugins</groupId>
>>> <artifactId>maven-compiler-plugin</artifactId>
>>> <version>2.0.2</version>
>>> <configuration>
>>> <source>1.6</source>
>>> <target>1.6</target>
>>> <encoding>UTF-8</encoding>
>>> </configuration>
>>> </plugin>
>>> <plugins>
>>> <build>
>>> <project>
>>>
>>>
>>> Piotr
>>>
>>>
>>>
>>> On Mon, Dec 20, 2010 at 2:57 PM, Anders Hammar<an...@hammar.net> wrote:
>>>
>>> Check the project's effective pom.
>>>> mvn help:effective-pom
>>>>
>>>> Most likely what you think should be inherited isn't. How is m-compiler-p
>>>> declared in the parent?
>>>>
>>>> /Anders
>>>>
>>>> On Mon, Dec 20, 2010 at 14:50, Piotr Skawinski<
>>>> piotr.skawinski.maven@gmail.com> wrote:
>>>>
>>>> Hi,
>>>>> I'm having problems using release:prepare plugin on a project that
>>>>>
>>>> inherits
>>>>
>>>>> from a parent project. It seems that it cannot see the plugins from the
>>>>> parent project and fails on compiling java vesion 1.6 classes claiming
>>>>>
>>>> that
>>>>
>>>>> 1.3 version does not support annotations. It works fine with clean
>>>>>
>>>> install.
>>>>
>>>>> The maven-compiler-plugin is defined in the parent project. What can be
>>>>>
>>>> the
>>>>
>>>>> problem?
>>>>>
>>>>> thanks in advance,
>>>>>
>>>>> Piotr
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: release:prepare does not inherit plugins from the parent project?
Posted by Piotr Skawinski <pi...@gmail.com>.
Hi Ron,
There's actually no reference to 1.3, that is what what makes it strange :)
The m-compiler-p is defined in the parent pom to use version 1.6, but
somehow seems to be ignored by release:prepare. Maven is using version 1.3
to compile with per default, unless you define the java version through
m-compiler-p, which I actually do. Though, it seems to be ignored by
release:prepare. When running clean install it works fine. I don't quite
understand what you mean by using effective-pom. I thought it was intented
to be used especially in this cas to see the real pom seen by maven :)
Piotr
On Mon, Dec 20, 2010 at 5:04 PM, Ron Wheeler <rwheeler@artifact-software.com
> wrote:
> Where is the reference to 1.3 coming from?
> I think that was what the effective-pom was for, not to see if the plug-ins
> were there but to find out who is asking for 1.3.
>
> Ron
>
>
>
> On 20/12/2010 10:05 AM, Piotr Skawinski wrote:
>
>> Hi again,
>>
>> Actually when running mvn help:effective-pom I can see all plugins from
>> the
>> parent as expected, but when running it after release:prepare (which
>> actually faills) they are not there anymore. It seems that release:prepare
>> ignores the parent's plugins for the project it runs the release for.
>> Though, when plugins are defined in the project's scope and not the
>> parent's
>> the release:prepare works as expected. The plugin in the parent is defines
>> parent as follows:
>>
>> <project>
>> .
>> .
>> .
>> <build>
>> <plugins>
>> <plugin>
>> <groupId>org.apache.maven.plugins</groupId>
>> <artifactId>maven-compiler-plugin</artifactId>
>> <version>2.0.2</version>
>> <configuration>
>> <source>1.6</source>
>> <target>1.6</target>
>> <encoding>UTF-8</encoding>
>> </configuration>
>> </plugin>
>> <plugins>
>> <build>
>> <project>
>>
>>
>> Piotr
>>
>>
>>
>> On Mon, Dec 20, 2010 at 2:57 PM, Anders Hammar<an...@hammar.net> wrote:
>>
>> Check the project's effective pom.
>>> mvn help:effective-pom
>>>
>>> Most likely what you think should be inherited isn't. How is m-compiler-p
>>> declared in the parent?
>>>
>>> /Anders
>>>
>>> On Mon, Dec 20, 2010 at 14:50, Piotr Skawinski<
>>> piotr.skawinski.maven@gmail.com> wrote:
>>>
>>> Hi,
>>>>
>>>> I'm having problems using release:prepare plugin on a project that
>>>>
>>> inherits
>>>
>>>> from a parent project. It seems that it cannot see the plugins from the
>>>> parent project and fails on compiling java vesion 1.6 classes claiming
>>>>
>>> that
>>>
>>>> 1.3 version does not support annotations. It works fine with clean
>>>>
>>> install.
>>>
>>>> The maven-compiler-plugin is defined in the parent project. What can be
>>>>
>>> the
>>>
>>>> problem?
>>>>
>>>> thanks in advance,
>>>>
>>>> Piotr
>>>>
>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: release:prepare does not inherit plugins from the parent project?
Posted by Ron Wheeler <rw...@artifact-software.com>.
Where is the reference to 1.3 coming from?
I think that was what the effective-pom was for, not to see if the
plug-ins were there but to find out who is asking for 1.3.
Ron
On 20/12/2010 10:05 AM, Piotr Skawinski wrote:
> Hi again,
>
> Actually when running mvn help:effective-pom I can see all plugins from the
> parent as expected, but when running it after release:prepare (which
> actually faills) they are not there anymore. It seems that release:prepare
> ignores the parent's plugins for the project it runs the release for.
> Though, when plugins are defined in the project's scope and not the parent's
> the release:prepare works as expected. The plugin in the parent is defines
> parent as follows:
>
> <project>
> .
> .
> .
> <build>
> <plugins>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-compiler-plugin</artifactId>
> <version>2.0.2</version>
> <configuration>
> <source>1.6</source>
> <target>1.6</target>
> <encoding>UTF-8</encoding>
> </configuration>
> </plugin>
> <plugins>
> <build>
> <project>
>
>
> Piotr
>
>
>
> On Mon, Dec 20, 2010 at 2:57 PM, Anders Hammar<an...@hammar.net> wrote:
>
>> Check the project's effective pom.
>> mvn help:effective-pom
>>
>> Most likely what you think should be inherited isn't. How is m-compiler-p
>> declared in the parent?
>>
>> /Anders
>>
>> On Mon, Dec 20, 2010 at 14:50, Piotr Skawinski<
>> piotr.skawinski.maven@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I'm having problems using release:prepare plugin on a project that
>> inherits
>>> from a parent project. It seems that it cannot see the plugins from the
>>> parent project and fails on compiling java vesion 1.6 classes claiming
>> that
>>> 1.3 version does not support annotations. It works fine with clean
>> install.
>>> The maven-compiler-plugin is defined in the parent project. What can be
>> the
>>> problem?
>>>
>>> thanks in advance,
>>>
>>> Piotr
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: release:prepare does not inherit plugins from the parent project?
Posted by Piotr Skawinski <pi...@gmail.com>.
Hi again,
Actually when running mvn help:effective-pom I can see all plugins from the
parent as expected, but when running it after release:prepare (which
actually faills) they are not there anymore. It seems that release:prepare
ignores the parent's plugins for the project it runs the release for.
Though, when plugins are defined in the project's scope and not the parent's
the release:prepare works as expected. The plugin in the parent is defines
parent as follows:
<project>
.
.
.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.0.2</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
<encoding>UTF-8</encoding>
</configuration>
</plugin>
<plugins>
<build>
<project>
Piotr
On Mon, Dec 20, 2010 at 2:57 PM, Anders Hammar <an...@hammar.net> wrote:
> Check the project's effective pom.
> mvn help:effective-pom
>
> Most likely what you think should be inherited isn't. How is m-compiler-p
> declared in the parent?
>
> /Anders
>
> On Mon, Dec 20, 2010 at 14:50, Piotr Skawinski <
> piotr.skawinski.maven@gmail.com> wrote:
>
> > Hi,
> >
> > I'm having problems using release:prepare plugin on a project that
> inherits
> > from a parent project. It seems that it cannot see the plugins from the
> > parent project and fails on compiling java vesion 1.6 classes claiming
> that
> > 1.3 version does not support annotations. It works fine with clean
> install.
> > The maven-compiler-plugin is defined in the parent project. What can be
> the
> > problem?
> >
> > thanks in advance,
> >
> > Piotr
> >
>
Re: release:prepare does not inherit plugins from the parent project?
Posted by Anders Hammar <an...@hammar.net>.
Check the project's effective pom.
mvn help:effective-pom
Most likely what you think should be inherited isn't. How is m-compiler-p
declared in the parent?
/Anders
On Mon, Dec 20, 2010 at 14:50, Piotr Skawinski <
piotr.skawinski.maven@gmail.com> wrote:
> Hi,
>
> I'm having problems using release:prepare plugin on a project that inherits
> from a parent project. It seems that it cannot see the plugins from the
> parent project and fails on compiling java vesion 1.6 classes claiming that
> 1.3 version does not support annotations. It works fine with clean install.
> The maven-compiler-plugin is defined in the parent project. What can be the
> problem?
>
> thanks in advance,
>
> Piotr
>