Nabble - Maven - Users

Re: Building sub projects pom from parent's pom.

2009-11-22T22:54:27Z

projA should not be a war project, it should merely be a aggregation pom.
Move your war project to a sub-project.
Read this:
http://www.sonatype.com/books/maven-book/reference/multimodule.html

/Anders

On Mon, Nov 23, 2009 at 07:45, <pinky.muralidhar@...> wrote:

>
> Hi,
>
> I am new to maven. Anyways I was able to build my war using maven
> build. I wanted to move forward from where I need to call other
> dependent sub project's maven.cmd first from my pom.xml.
>
>
> My project structure looks like this :
>
> projA
> |
> |-subProjA
> | |-pom.xml
> | |- maven.cmd
> |
> |-subProjB
> | |-pom.xml
> | |- maven.cmd
> |
> |-subProjC
> | |-pom.xml
> | |- maven.cmd
> |
> |-pom.xml
> |- maven.cmd
>
> projA's pom.xml must be able to call all subProj's maven.cmd before
> building the projA.war. Please guide me.
>
> Thanks in Advance,
> Pinky Muralidhar.
>
>
>
> Please do not print this email unless it is absolutely necessary.
>
> The information contained in this electronic message and any attachments to
> this message are intended for the exclusive use of the addressee(s) and may
> contain proprietary, confidential or privileged information. If you are not
> the intended recipient, you should not disseminate, distribute or copy this
> e-mail. Please notify the sender immediately and destroy all copies of this
> message and any attachments.
>
> WARNING: Computer viruses can be transmitted via email. The recipient
> should check this email and any attachments for the presence of viruses. The
> company accepts no liability for any damage caused by any virus transmitted
> by this email.
>
> www.wipro.com
>

Building sub projects pom from parent's pom.

2009-11-22T22:45:08Z

Hi,

I am new to maven. Anyways I was able to build my war using maven
build. I wanted to move forward from where I need to call other
dependent sub project's maven.cmd first from my pom.xml.

My project structure looks like this :

projA
|
|-subProjA
| |-pom.xml
| |- maven.cmd
|
|-subProjB
| |-pom.xml
| |- maven.cmd
|
|-subProjC
| |-pom.xml
| |- maven.cmd
|
|-pom.xml
|- maven.cmd

projA's pom.xml must be able to call all subProj's maven.cmd before
building the projA.war. Please guide me.

Thanks in Advance,
Pinky Muralidhar.

Please do not print this email unless it is absolutely necessary.

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.

www.wipro.com

Re: "[WARNING] POM is invalid." error messages in Maven 2.2.1 but not in 2.0.10

2009-11-22T19:17:57Z

On Mon, Nov 23, 2009 at 11:18 AM, Brett Porter <brett@...> wrote:
> Did you also "export WL_HOME"?
>
> I tried something similar here and it works fine in 2.2.1.
>
> - Brett

Hi Brett,

I'd presume the environment variable being there means that's already
happened. =)

This entry is in .bashrc so I'm pretty sure the environment var is
always created.

export WL_HOME=/usr/java/weblogic

I've just created a new session window and see these errors when I run
with "mvn -o -X -e package"

Validation Errors:
[DEBUG] For dependency Dependency {groupId=weblogic,
artifactId=weblogic, version=10.0, type=jar}: system-scoped dependency
must specify an absolute path systemPath.
[DEBUG] For managed dependency Dependency {groupId=weblogic,
artifactId=weblogic, version=10.0, type=jar}: system-scoped dependency
must specify an absolute path systemPath.

Ellecer

>
> On 23/11/2009, at 10:08 AM, Ellecer Valencia wrote:
>
>> But that's exactly the problem - it *is* defined in the environment. :(
>>
>> $ls -l $WL_HOME/server/lib/webservices.jar
>> -rwxr-xr-x. 1 dev dev 1696324 2009-10-30 16:55
>> /usr/java/weblogic/server/lib/webservices.jar
>>
>>
>> $echo $WL_HOME
>> /usr/java/weblogic
>>
>>
>> The Maven project I am trying to build has a pom.xml with a parent pom
>>
>> <parent>
>> <artifactId>super_pom</artifactId>
>> <groupId>mypackage</groupId>
>> <version>1.0.2-SNAPSHOT</version>
>> </parent>
>>
>> and it's in super_pom where the weblogic dependency is declared.
>>
>>
>>
>> On Mon, Nov 23, 2009 at 9:18 AM, Brian Fox <brianf@...> wrote:
>>> Well Maven sees it just like the message:
>>> [DEBUG] For managed dependency Dependency {groupId=weblogic,
>>> artifactId=weblogic, version=10.0, type=jar}: system-scoped dependency
>>> must specify an absolute path systemPath.
>>>
>>>
>>> So since the first one works and the second one doesn't, that leads me
>>> to believe that WL_HOME isn't defined in your environment.
>>>
>>> On Sun, Nov 22, 2009 at 9:06 AM, Ellecer Valencia <ellecer@...> wrote:
>>>> Hi Brian,
>>>>
>>>> Could you please clarify what's actually "plain wrong" about it?
>>>>
>>>> Going back to the example I posted:
>>>>
>>>> <dependency>
>>>> <groupId>com.sun</groupId>
>>>> <artifactId>rt</artifactId>
>>>> <version>1.5.0.11</version>
>>>> <scope>system</scope>
>>>> <systemPath>${java.home}/lib/rt.jar</systemPath>
>>>> </dependency>
>>>> <dependency>
>>>> <groupId>weblogic</groupId>
>>>> <artifactId>weblogic</artifactId>
>>>> <version>10.0</version>
>>>> <scope>system</scope>
>>>> <systemPath>${env.WL_HOME}/server/lib/weblogic.jar</systemPath>
>>>> </dependency>
>>>>
>>>> Do you mean the first one, referencing "${java.home}" is correct and
>>>> the one referencing "${env.WL_HOME}" is wrong? So what should we do to
>>>> make it work?
>>>>
>>>>
>>>> thanks,
>>>>
>>>> Ellecer
>>>>
>>>>
>>>> On Sat, Nov 21, 2009 at 4:33 AM, Brian E. Fox <brianf@...> wrote:
>>>>>>
>>>>>>
>>>>>> Maybe 2.2.2 will fix it. =)
>>>>>
>>>>> Not likely. The pom is plain wrong an it was a bug in 2.x which allowed it
>>>>> to go unnoticed.
>>>>>
>>>>>> On Fri, Nov 20, 2009 at 3:42 PM, Brett Randall <javabrett@...>
>>>>>> wrote:
>>>>>>>
>>>>>>> http://jira.codehaus.org/browse/MNG-4379 ... or did your team log that
>>>>>>> :).
>>>>>>>
>>>>>>> On Fri, Nov 20, 2009 at 2:59 PM, Ellecer Valencia <ellecer@...>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Brett,
>>>>>>>>
>>>>>>>> Thanks for the suggestion. I may have found the issue. Would it be this:
>>>>>>>>
>>>>>>>>
>>>>>>>> Validation Errors:
>>>>>>>> [DEBUG] For dependency Dependency {groupId=weblogic,
>>>>>>>> artifactId=weblogic, version=10.0, type=jar}: system-scoped dependency
>>>>>>>> must specify an absolute path systemPath.
>>>>>>>> [DEBUG] For managed dependency Dependency {groupId=weblogic,
>>>>>>>> artifactId=weblogic, version=10.0, type=jar}: system-scoped dependency
>>>>>>>> must specify an absolute path systemPath.
>>>>>>>> [DEBUG]
>>>>>>>>
>>>>>>>> [DEBUG] mypackage:myartifact:jar:1.0.2:compile (selected for compile)
>>>>>>>> [DEBUG] Skipping disabled repository central
>>>>>>>> [DEBUG] myartifact: using locally installed snapshot
>>>>>>>> [WARNING] POM for 'mypackage:myartifact:pom:1.0.2-SNAPSHOT:test' is
>>>>>>>> invalid.
>>>>>>>>
>>>>>>>> Its dependencies (if any) will NOT be available to the current build.
>>>>>>>> [DEBUG] Reason: Failed to validate POM for project
>>>>>>>> mypackage:myartifact at Artifact
>>>>>>>> [mypackage:myartifact:pom:1.0.2-SNAPSHOT:test]
>>>>>>>> [DEBUG]
>>>>>>>> Validation Errors:
>>>>>>>> [DEBUG] For dependency Dependency {groupId=weblogic,
>>>>>>>> artifactId=weblogic, version=10.0, type=jar}: system-scoped dependency
>>>>>>>> must specify an absolute path systemPath.
>>>>>>>> [DEBUG] For dependency Dependency {groupId=weblogic,
>>>>>>>> artifactId=webservices, version=10.0, type=jar}: system-scoped
>>>>>>>> dependency must specify an absolute path systemPath.
>>>>>>>> [DEBUG] For managed dependency Dependency {groupId=weblogic,
>>>>>>>> artifactId=weblogic, version=10.0, type=jar}: system-scoped dependency
>>>>>>>> must specify an absolute path systemPath.
>>>>>>>> [DEBUG] For managed dependency Dependency {groupId=weblogic,
>>>>>>>> artifactId=webservices, version=10.0, type=jar}: system-scoped
>>>>>>>> dependency must specify an absolute path systemPath.
>>>>>>>> [DEBUG]
>>>>>>>>
>>>>>>>>
>>>>>>>> Now in this project, we are inheriting from a parent POM (standardised
>>>>>>>> for our department) with entries like this:
>>>>>>>> (WL_HOME is Weblogic install directory)
>>>>>>>>
>>>>>>>>
>>>>>>>> <dependency>
>>>>>>>> <groupId>com.sun</groupId>
>>>>>>>> <artifactId>tools</artifactId>
>>>>>>>> <version>1.5.0.11</version>
>>>>>>>> <scope>system</scope>
>>>>>>>> <systemPath>${java.home}/../lib/tools.jar</systemPath>
>>>>>>>> </dependency>
>>>>>>>> <dependency>
>>>>>>>> <groupId>com.sun</groupId>
>>>>>>>> <artifactId>rt</artifactId>
>>>>>>>> <version>1.5.0.11</version>
>>>>>>>> <scope>system</scope>
>>>>>>>> <systemPath>${java.home}/lib/rt.jar</systemPath>
>>>>>>>> </dependency>
>>>>>>>> <dependency>
>>>>>>>> <groupId>weblogic</groupId>
>>>>>>>> <artifactId>weblogic</artifactId>
>>>>>>>> <version>10.0</version>
>>>>>>>> <scope>system</scope>
>>>>>>>> <systemPath>${env.WL_HOME}/server/lib/weblogic.jar</systemPath>
>>>>>>>> </dependency>
>>>>>>>> <dependency>
>>>>>>>> <groupId>weblogic</groupId>
>>>>>>>> <artifactId>webservices</artifactId>
>>>>>>>> <version>10.0</version>
>>>>>>>> <scope>system</scope>
>>>>>>>> <systemPath>${env.WL_HOME}/server/lib/webservices.jar</systemPath>
>>>>>>>> </dependency>
>>>>>>>>
>>>>>>>>
>>>>>>>> Now it only fails on the Weblogic related entries. With the Java
>>>>>>>> system dependencies it seems to do fine.
>>>>>>>>
>>>>>>>> Has the handling of this changed from 2.0.* to 2.2.*?
>>>>>>>>
>>>>>>>> If so, what should we replace it with?
>>>>>>>>
>>>>>>>> And will these settings also work for people still using maven 2.0.10?
>>>>>>>>
>>>>>>>>
>>>>>>>> Ellecer
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Nov 20, 2009 at 1:01 PM, Brett Randall <javabrett@...>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi Ellecer
>>>>>>>>>
>>>>>>>>> What is the output of mvn -e -X ...
>>>>>>>>>
>>>>>>>>> Brett
>>>>>>>>>
>>>>>>>>> On Fri, Nov 20, 2009 at 11:41 AM, Ellecer Valencia <ellecer@...
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> How come when I try a build using Maven 2.2.1 I get multiple messages
>>>>>>>>
>>>>>>>> like
>>>>>>>>>>
>>>>>>>>>> this:
>>>>>>>>>>
>>>>>>>>>> "[WARNING] POM for 'mypackage.artifact:pom:1.0.2-SNAPSHOT:compile' is
>>>>>>>>>> invalid.
>>>>>>>>>>
>>>>>>>>>> Its dependencies (if any) will NOT be available to the current build."
>>>>>>>>>>
>>>>>>>>>> These errors weren't displaying when I was using Maven 2.0.10
>>>>>>>>>>
>>>>>>>>>> I'm trying to use the newer version of Maven but I can't proceed with
>>>>>>>>>> these error messages.
>>>>>>>>>>
>>>>>>>>>> How can I find out what are the actual errors it's referring to? I
>>>>>>>>>> didn't come across any mention of relevant POM format changes going
>>>>>>>>>> from Maven 2.0.* to 2.1.* or 2.2.* - if anyone has any info on this it
>>>>>>>>>> would be a great help! Is there a way to validate the pom and get
>>>>>>>>>> format error details from Maven?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> thanks,
>>>>>>>>>>
>>>>>>>>>> Ellecer
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>>>>>>> For additional commands, e-mail: users-help@...
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>>>>> For additional commands, e-mail: users-help@...
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>>> For additional commands, e-mail: users-help@...
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>> For additional commands, e-mail: users-help@...
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: "[WARNING] POM is invalid." error messages in Maven 2.2.1 but not in 2.0.10

2009-11-22T16:18:53Z

Did you also "export WL_HOME"?

I tried something similar here and it works fine in 2.2.1.

- Brett

On 23/11/2009, at 10:08 AM, Ellecer Valencia wrote:

> But that's exactly the problem - it *is* defined in the environment. :(
>
> $ls -l $WL_HOME/server/lib/webservices.jar
> -rwxr-xr-x. 1 dev dev 1696324 2009-10-30 16:55
> /usr/java/weblogic/server/lib/webservices.jar
>
>
> $echo $WL_HOME
> /usr/java/weblogic
>
>
> The Maven project I am trying to build has a pom.xml with a parent pom
>
> <parent>
> <artifactId>super_pom</artifactId>
> <groupId>mypackage</groupId>
> <version>1.0.2-SNAPSHOT</version>
> </parent>
>
> and it's in super_pom where the weblogic dependency is declared.
>
>
>
> On Mon, Nov 23, 2009 at 9:18 AM, Brian Fox <brianf@...> wrote:
>> Well Maven sees it just like the message:
>> [DEBUG] For managed dependency Dependency {groupId=weblogic,
>> artifactId=weblogic, version=10.0, type=jar}: system-scoped dependency
>> must specify an absolute path systemPath.
>>
>>
>> So since the first one works and the second one doesn't, that leads me
>> to believe that WL_HOME isn't defined in your environment.
>>
>> On Sun, Nov 22, 2009 at 9:06 AM, Ellecer Valencia <ellecer@...> wrote:
>>> Hi Brian,
>>>
>>> Could you please clarify what's actually "plain wrong" about it?
>>>
>>> Going back to the example I posted:
>>>
>>> <dependency>
>>> <groupId>com.sun</groupId>
>>> <artifactId>rt</artifactId>
>>> <version>1.5.0.11</version>
>>> <scope>system</scope>
>>> <systemPath>${java.home}/lib/rt.jar</systemPath>
>>> </dependency>
>>> <dependency>
>>> <groupId>weblogic</groupId>
>>> <artifactId>weblogic</artifactId>
>>> <version>10.0</version>
>>> <scope>system</scope>
>>> <systemPath>${env.WL_HOME}/server/lib/weblogic.jar</systemPath>
>>> </dependency>
>>>
>>> Do you mean the first one, referencing "${java.home}" is correct and
>>> the one referencing "${env.WL_HOME}" is wrong? So what should we do to
>>> make it work?
>>>
>>>
>>> thanks,
>>>
>>> Ellecer
>>>
>>>
>>> On Sat, Nov 21, 2009 at 4:33 AM, Brian E. Fox <brianf@...> wrote:
>>>>>
>>>>>
>>>>> Maybe 2.2.2 will fix it. =)
>>>>
>>>> Not likely. The pom is plain wrong an it was a bug in 2.x which allowed it
>>>> to go unnoticed.
>>>>
>>>>> On Fri, Nov 20, 2009 at 3:42 PM, Brett Randall <javabrett@...>
>>>>> wrote:
>>>>>>
>>>>>> http://jira.codehaus.org/browse/MNG-4379 ... or did your team log that
>>>>>> :).
>>>>>>
>>>>>> On Fri, Nov 20, 2009 at 2:59 PM, Ellecer Valencia <ellecer@...>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Brett,
>>>>>>>
>>>>>>> Thanks for the suggestion. I may have found the issue. Would it be this:
>>>>>>>
>>>>>>>
>>>>>>> Validation Errors:
>>>>>>> [DEBUG] For dependency Dependency {groupId=weblogic,
>>>>>>> artifactId=weblogic, version=10.0, type=jar}: system-scoped dependency
>>>>>>> must specify an absolute path systemPath.
>>>>>>> [DEBUG] For managed dependency Dependency {groupId=weblogic,
>>>>>>> artifactId=weblogic, version=10.0, type=jar}: system-scoped dependency
>>>>>>> must specify an absolute path systemPath.
>>>>>>> [DEBUG]
>>>>>>>
>>>>>>> [DEBUG] mypackage:myartifact:jar:1.0.2:compile (selected for compile)
>>>>>>> [DEBUG] Skipping disabled repository central
>>>>>>> [DEBUG] myartifact: using locally installed snapshot
>>>>>>> [WARNING] POM for 'mypackage:myartifact:pom:1.0.2-SNAPSHOT:test' is
>>>>>>> invalid.
>>>>>>>
>>>>>>> Its dependencies (if any) will NOT be available to the current build.
>>>>>>> [DEBUG] Reason: Failed to validate POM for project
>>>>>>> mypackage:myartifact at Artifact
>>>>>>> [mypackage:myartifact:pom:1.0.2-SNAPSHOT:test]
>>>>>>> [DEBUG]
>>>>>>> Validation Errors:
>>>>>>> [DEBUG] For dependency Dependency {groupId=weblogic,
>>>>>>> artifactId=weblogic, version=10.0, type=jar}: system-scoped dependency
>>>>>>> must specify an absolute path systemPath.
>>>>>>> [DEBUG] For dependency Dependency {groupId=weblogic,
>>>>>>> artifactId=webservices, version=10.0, type=jar}: system-scoped
>>>>>>> dependency must specify an absolute path systemPath.
>>>>>>> [DEBUG] For managed dependency Dependency {groupId=weblogic,
>>>>>>> artifactId=weblogic, version=10.0, type=jar}: system-scoped dependency
>>>>>>> must specify an absolute path systemPath.
>>>>>>> [DEBUG] For managed dependency Dependency {groupId=weblogic,
>>>>>>> artifactId=webservices, version=10.0, type=jar}: system-scoped
>>>>>>> dependency must specify an absolute path systemPath.
>>>>>>> [DEBUG]
>>>>>>>
>>>>>>>
>>>>>>> Now in this project, we are inheriting from a parent POM (standardised
>>>>>>> for our department) with entries like this:
>>>>>>> (WL_HOME is Weblogic install directory)
>>>>>>>
>>>>>>>
>>>>>>> <dependency>
>>>>>>> <groupId>com.sun</groupId>
>>>>>>> <artifactId>tools</artifactId>
>>>>>>> <version>1.5.0.11</version>
>>>>>>> <scope>system</scope>
>>>>>>> <systemPath>${java.home}/../lib/tools.jar</systemPath>
>>>>>>> </dependency>
>>>>>>> <dependency>
>>>>>>> <groupId>com.sun</groupId>
>>>>>>> <artifactId>rt</artifactId>
>>>>>>> <version>1.5.0.11</version>
>>>>>>> <scope>system</scope>
>>>>>>> <systemPath>${java.home}/lib/rt.jar</systemPath>
>>>>>>> </dependency>
>>>>>>> <dependency>
>>>>>>> <groupId>weblogic</groupId>
>>>>>>> <artifactId>weblogic</artifactId>
>>>>>>> <version>10.0</version>
>>>>>>> <scope>system</scope>
>>>>>>> <systemPath>${env.WL_HOME}/server/lib/weblogic.jar</systemPath>
>>>>>>> </dependency>
>>>>>>> <dependency>
>>>>>>> <groupId>weblogic</groupId>
>>>>>>> <artifactId>webservices</artifactId>
>>>>>>> <version>10.0</version>
>>>>>>> <scope>system</scope>
>>>>>>> <systemPath>${env.WL_HOME}/server/lib/webservices.jar</systemPath>
>>>>>>> </dependency>
>>>>>>>
>>>>>>>
>>>>>>> Now it only fails on the Weblogic related entries. With the Java
>>>>>>> system dependencies it seems to do fine.
>>>>>>>
>>>>>>> Has the handling of this changed from 2.0.* to 2.2.*?
>>>>>>>
>>>>>>> If so, what should we replace it with?
>>>>>>>
>>>>>>> And will these settings also work for people still using maven 2.0.10?
>>>>>>>
>>>>>>>
>>>>>>> Ellecer
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Nov 20, 2009 at 1:01 PM, Brett Randall <javabrett@...>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi Ellecer
>>>>>>>>
>>>>>>>> What is the output of mvn -e -X ...
>>>>>>>>
>>>>>>>> Brett
>>>>>>>>
>>>>>>>> On Fri, Nov 20, 2009 at 11:41 AM, Ellecer Valencia <ellecer@...
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> How come when I try a build using Maven 2.2.1 I get multiple messages
>>>>>>>
>>>>>>> like
>>>>>>>>>
>>>>>>>>> this:
>>>>>>>>>
>>>>>>>>> "[WARNING] POM for 'mypackage.artifact:pom:1.0.2-SNAPSHOT:compile' is
>>>>>>>>> invalid.
>>>>>>>>>
>>>>>>>>> Its dependencies (if any) will NOT be available to the current build."
>>>>>>>>>
>>>>>>>>> These errors weren't displaying when I was using Maven 2.0.10
>>>>>>>>>
>>>>>>>>> I'm trying to use the newer version of Maven but I can't proceed with
>>>>>>>>> these error messages.
>>>>>>>>>
>>>>>>>>> How can I find out what are the actual errors it's referring to? I
>>>>>>>>> didn't come across any mention of relevant POM format changes going
>>>>>>>>> from Maven 2.0.* to 2.1.* or 2.2.* - if anyone has any info on this it
>>>>>>>>> would be a great help! Is there a way to validate the pom and get
>>>>>>>>> format error details from Maven?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> thanks,
>>>>>>>>>
>>>>>>>>> Ellecer
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>>>>>> For additional commands, e-mail: users-help@...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>>>> For additional commands, e-mail: users-help@...
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>> For additional commands, e-mail: users-help@...
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: "[WARNING] POM is invalid." error messages in Maven 2.2.1 but not in 2.0.10

2009-11-22T15:08:04Z

But that's exactly the problem - it *is* defined in the environment. :(

$ls -l $WL_HOME/server/lib/webservices.jar
-rwxr-xr-x. 1 dev dev 1696324 2009-10-30 16:55
/usr/java/weblogic/server/lib/webservices.jar

$echo $WL_HOME
/usr/java/weblogic

The Maven project I am trying to build has a pom.xml with a parent pom

<parent>
<artifactId>super_pom</artifactId>
<groupId>mypackage</groupId>
<version>1.0.2-SNAPSHOT</version>
</parent>

and it's in super_pom where the weblogic dependency is declared.

On Mon, Nov 23, 2009 at 9:18 AM, Brian Fox <brianf@...> wrote:

> Well Maven sees it just like the message:
> [DEBUG] For managed dependency Dependency {groupId=weblogic,
> artifactId=weblogic, version=10.0, type=jar}: system-scoped dependency
> must specify an absolute path systemPath.
>
>
> So since the first one works and the second one doesn't, that leads me
> to believe that WL_HOME isn't defined in your environment.
>
> On Sun, Nov 22, 2009 at 9:06 AM, Ellecer Valencia <ellecer@...> wrote:
>> Hi Brian,
>>
>> Could you please clarify what's actually "plain wrong" about it?
>>
>> Going back to the example I posted:
>>
>> <dependency>
>> <groupId>com.sun</groupId>
>> <artifactId>rt</artifactId>
>> <version>1.5.0.11</version>
>> <scope>system</scope>
>> <systemPath>${java.home}/lib/rt.jar</systemPath>
>> </dependency>
>> <dependency>
>> <groupId>weblogic</groupId>
>> <artifactId>weblogic</artifactId>
>> <version>10.0</version>
>> <scope>system</scope>
>> <systemPath>${env.WL_HOME}/server/lib/weblogic.jar</systemPath>
>> </dependency>
>>
>> Do you mean the first one, referencing "${java.home}" is correct and
>> the one referencing "${env.WL_HOME}" is wrong? So what should we do to
>> make it work?
>>
>>
>> thanks,
>>
>> Ellecer
>>
>>
>> On Sat, Nov 21, 2009 at 4:33 AM, Brian E. Fox <brianf@...> wrote:
>>>>
>>>>
>>>> Maybe 2.2.2 will fix it. =)
>>>
>>> Not likely. The pom is plain wrong an it was a bug in 2.x which allowed it
>>> to go unnoticed.
>>>
>>>> On Fri, Nov 20, 2009 at 3:42 PM, Brett Randall <javabrett@...>
>>>> wrote:
>>>>>
>>>>> http://jira.codehaus.org/browse/MNG-4379 ... or did your team log that
>>>>> :).
>>>>>
>>>>> On Fri, Nov 20, 2009 at 2:59 PM, Ellecer Valencia <ellecer@...>
>>>>> wrote:
>>>>>
>>>>>> Hi Brett,
>>>>>>
>>>>>> Thanks for the suggestion. I may have found the issue. Would it be this:
>>>>>>
>>>>>>
>>>>>> Validation Errors:
>>>>>> [DEBUG] For dependency Dependency {groupId=weblogic,
>>>>>> artifactId=weblogic, version=10.0, type=jar}: system-scoped dependency
>>>>>> must specify an absolute path systemPath.
>>>>>> [DEBUG] For managed dependency Dependency {groupId=weblogic,
>>>>>> artifactId=weblogic, version=10.0, type=jar}: system-scoped dependency
>>>>>> must specify an absolute path systemPath.
>>>>>> [DEBUG]
>>>>>>
>>>>>> [DEBUG] mypackage:myartifact:jar:1.0.2:compile (selected for compile)
>>>>>> [DEBUG] Skipping disabled repository central
>>>>>> [DEBUG] myartifact: using locally installed snapshot
>>>>>> [WARNING] POM for 'mypackage:myartifact:pom:1.0.2-SNAPSHOT:test' is
>>>>>> invalid.
>>>>>>
>>>>>> Its dependencies (if any) will NOT be available to the current build.
>>>>>> [DEBUG] Reason: Failed to validate POM for project
>>>>>> mypackage:myartifact at Artifact
>>>>>> [mypackage:myartifact:pom:1.0.2-SNAPSHOT:test]
>>>>>> [DEBUG]
>>>>>> Validation Errors:
>>>>>> [DEBUG] For dependency Dependency {groupId=weblogic,
>>>>>> artifactId=weblogic, version=10.0, type=jar}: system-scoped dependency
>>>>>> must specify an absolute path systemPath.
>>>>>> [DEBUG] For dependency Dependency {groupId=weblogic,
>>>>>> artifactId=webservices, version=10.0, type=jar}: system-scoped
>>>>>> dependency must specify an absolute path systemPath.
>>>>>> [DEBUG] For managed dependency Dependency {groupId=weblogic,
>>>>>> artifactId=weblogic, version=10.0, type=jar}: system-scoped dependency
>>>>>> must specify an absolute path systemPath.
>>>>>> [DEBUG] For managed dependency Dependency {groupId=weblogic,
>>>>>> artifactId=webservices, version=10.0, type=jar}: system-scoped
>>>>>> dependency must specify an absolute path systemPath.
>>>>>> [DEBUG]
>>>>>>
>>>>>>
>>>>>> Now in this project, we are inheriting from a parent POM (standardised
>>>>>> for our department) with entries like this:
>>>>>> (WL_HOME is Weblogic install directory)
>>>>>>
>>>>>>
>>>>>> <dependency>
>>>>>> <groupId>com.sun</groupId>
>>>>>> <artifactId>tools</artifactId>
>>>>>> <version>1.5.0.11</version>
>>>>>> <scope>system</scope>
>>>>>> <systemPath>${java.home}/../lib/tools.jar</systemPath>
>>>>>> </dependency>
>>>>>> <dependency>
>>>>>> <groupId>com.sun</groupId>
>>>>>> <artifactId>rt</artifactId>
>>>>>> <version>1.5.0.11</version>
>>>>>> <scope>system</scope>
>>>>>> <systemPath>${java.home}/lib/rt.jar</systemPath>
>>>>>> </dependency>
>>>>>> <dependency>
>>>>>> <groupId>weblogic</groupId>
>>>>>> <artifactId>weblogic</artifactId>
>>>>>> <version>10.0</version>
>>>>>> <scope>system</scope>
>>>>>> <systemPath>${env.WL_HOME}/server/lib/weblogic.jar</systemPath>
>>>>>> </dependency>
>>>>>> <dependency>
>>>>>> <groupId>weblogic</groupId>
>>>>>> <artifactId>webservices</artifactId>
>>>>>> <version>10.0</version>
>>>>>> <scope>system</scope>
>>>>>> <systemPath>${env.WL_HOME}/server/lib/webservices.jar</systemPath>
>>>>>> </dependency>
>>>>>>
>>>>>>
>>>>>> Now it only fails on the Weblogic related entries. With the Java
>>>>>> system dependencies it seems to do fine.
>>>>>>
>>>>>> Has the handling of this changed from 2.0.* to 2.2.*?
>>>>>>
>>>>>> If so, what should we replace it with?
>>>>>>
>>>>>> And will these settings also work for people still using maven 2.0.10?
>>>>>>
>>>>>>
>>>>>> Ellecer
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Nov 20, 2009 at 1:01 PM, Brett Randall <javabrett@...>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Ellecer
>>>>>>>
>>>>>>> What is the output of mvn -e -X ...
>>>>>>>
>>>>>>> Brett
>>>>>>>
>>>>>>> On Fri, Nov 20, 2009 at 11:41 AM, Ellecer Valencia <ellecer@...
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> How come when I try a build using Maven 2.2.1 I get multiple messages
>>>>>>
>>>>>> like
>>>>>>>>
>>>>>>>> this:
>>>>>>>>
>>>>>>>> "[WARNING] POM for 'mypackage.artifact:pom:1.0.2-SNAPSHOT:compile' is
>>>>>>>> invalid.
>>>>>>>>
>>>>>>>> Its dependencies (if any) will NOT be available to the current build."
>>>>>>>>
>>>>>>>> These errors weren't displaying when I was using Maven 2.0.10
>>>>>>>>
>>>>>>>> I'm trying to use the newer version of Maven but I can't proceed with
>>>>>>>> these error messages.
>>>>>>>>
>>>>>>>> How can I find out what are the actual errors it's referring to? I
>>>>>>>> didn't come across any mention of relevant POM format changes going
>>>>>>>> from Maven 2.0.* to 2.1.* or 2.2.* - if anyone has any info on this it
>>>>>>>> would be a great help! Is there a way to validate the pom and get
>>>>>>>> format error details from Maven?
>>>>>>>>
>>>>>>>>
>>>>>>>> thanks,
>>>>>>>>
>>>>>>>> Ellecer
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>>>>> For additional commands, e-mail: users-help@...
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>>> For additional commands, e-mail: users-help@...
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: "[WARNING] POM is invalid." error messages in Maven 2.2.1 but not in 2.0.10

2009-11-22T14:18:29Z

Well Maven sees it just like the message:
[DEBUG] For managed dependency Dependency {groupId=weblogic,
artifactId=weblogic, version=10.0, type=jar}: system-scoped dependency
must specify an absolute path systemPath.

So since the first one works and the second one doesn't, that leads me
to believe that WL_HOME isn't defined in your environment.

On Sun, Nov 22, 2009 at 9:06 AM, Ellecer Valencia <ellecer@...> wrote:

> Hi Brian,
>
> Could you please clarify what's actually "plain wrong" about it?
>
> Going back to the example I posted:
>
> <dependency>
> <groupId>com.sun</groupId>
> <artifactId>rt</artifactId>
> <version>1.5.0.11</version>
> <scope>system</scope>
> <systemPath>${java.home}/lib/rt.jar</systemPath>
> </dependency>
> <dependency>
> <groupId>weblogic</groupId>
> <artifactId>weblogic</artifactId>
> <version>10.0</version>
> <scope>system</scope>
> <systemPath>${env.WL_HOME}/server/lib/weblogic.jar</systemPath>
> </dependency>
>
> Do you mean the first one, referencing "${java.home}" is correct and
> the one referencing "${env.WL_HOME}" is wrong? So what should we do to
> make it work?
>
>
> thanks,
>
> Ellecer
>
>
> On Sat, Nov 21, 2009 at 4:33 AM, Brian E. Fox <brianf@...> wrote:
>>>
>>>
>>> Maybe 2.2.2 will fix it. =)
>>
>> Not likely. The pom is plain wrong an it was a bug in 2.x which allowed it
>> to go unnoticed.
>>
>>> On Fri, Nov 20, 2009 at 3:42 PM, Brett Randall <javabrett@...>
>>> wrote:
>>>>
>>>> http://jira.codehaus.org/browse/MNG-4379 ... or did your team log that
>>>> :).
>>>>
>>>> On Fri, Nov 20, 2009 at 2:59 PM, Ellecer Valencia <ellecer@...>
>>>> wrote:
>>>>
>>>>> Hi Brett,
>>>>>
>>>>> Thanks for the suggestion. I may have found the issue. Would it be this:
>>>>>
>>>>>
>>>>> Validation Errors:
>>>>> [DEBUG] For dependency Dependency {groupId=weblogic,
>>>>> artifactId=weblogic, version=10.0, type=jar}: system-scoped dependency
>>>>> must specify an absolute path systemPath.
>>>>> [DEBUG] For managed dependency Dependency {groupId=weblogic,
>>>>> artifactId=weblogic, version=10.0, type=jar}: system-scoped dependency
>>>>> must specify an absolute path systemPath.
>>>>> [DEBUG]
>>>>>
>>>>> [DEBUG] mypackage:myartifact:jar:1.0.2:compile (selected for compile)
>>>>> [DEBUG] Skipping disabled repository central
>>>>> [DEBUG] myartifact: using locally installed snapshot
>>>>> [WARNING] POM for 'mypackage:myartifact:pom:1.0.2-SNAPSHOT:test' is
>>>>> invalid.
>>>>>
>>>>> Its dependencies (if any) will NOT be available to the current build.
>>>>> [DEBUG] Reason: Failed to validate POM for project
>>>>> mypackage:myartifact at Artifact
>>>>> [mypackage:myartifact:pom:1.0.2-SNAPSHOT:test]
>>>>> [DEBUG]
>>>>> Validation Errors:
>>>>> [DEBUG] For dependency Dependency {groupId=weblogic,
>>>>> artifactId=weblogic, version=10.0, type=jar}: system-scoped dependency
>>>>> must specify an absolute path systemPath.
>>>>> [DEBUG] For dependency Dependency {groupId=weblogic,
>>>>> artifactId=webservices, version=10.0, type=jar}: system-scoped
>>>>> dependency must specify an absolute path systemPath.
>>>>> [DEBUG] For managed dependency Dependency {groupId=weblogic,
>>>>> artifactId=weblogic, version=10.0, type=jar}: system-scoped dependency
>>>>> must specify an absolute path systemPath.
>>>>> [DEBUG] For managed dependency Dependency {groupId=weblogic,
>>>>> artifactId=webservices, version=10.0, type=jar}: system-scoped
>>>>> dependency must specify an absolute path systemPath.
>>>>> [DEBUG]
>>>>>
>>>>>
>>>>> Now in this project, we are inheriting from a parent POM (standardised
>>>>> for our department) with entries like this:
>>>>> (WL_HOME is Weblogic install directory)
>>>>>
>>>>>
>>>>> <dependency>
>>>>> <groupId>com.sun</groupId>
>>>>> <artifactId>tools</artifactId>
>>>>> <version>1.5.0.11</version>
>>>>> <scope>system</scope>
>>>>> <systemPath>${java.home}/../lib/tools.jar</systemPath>
>>>>> </dependency>
>>>>> <dependency>
>>>>> <groupId>com.sun</groupId>
>>>>> <artifactId>rt</artifactId>
>>>>> <version>1.5.0.11</version>
>>>>> <scope>system</scope>
>>>>> <systemPath>${java.home}/lib/rt.jar</systemPath>
>>>>> </dependency>
>>>>> <dependency>
>>>>> <groupId>weblogic</groupId>
>>>>> <artifactId>weblogic</artifactId>
>>>>> <version>10.0</version>
>>>>> <scope>system</scope>
>>>>> <systemPath>${env.WL_HOME}/server/lib/weblogic.jar</systemPath>
>>>>> </dependency>
>>>>> <dependency>
>>>>> <groupId>weblogic</groupId>
>>>>> <artifactId>webservices</artifactId>
>>>>> <version>10.0</version>
>>>>> <scope>system</scope>
>>>>> <systemPath>${env.WL_HOME}/server/lib/webservices.jar</systemPath>
>>>>> </dependency>
>>>>>
>>>>>
>>>>> Now it only fails on the Weblogic related entries. With the Java
>>>>> system dependencies it seems to do fine.
>>>>>
>>>>> Has the handling of this changed from 2.0.* to 2.2.*?
>>>>>
>>>>> If so, what should we replace it with?
>>>>>
>>>>> And will these settings also work for people still using maven 2.0.10?
>>>>>
>>>>>
>>>>> Ellecer
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Nov 20, 2009 at 1:01 PM, Brett Randall <javabrett@...>
>>>>> wrote:
>>>>>>
>>>>>> Hi Ellecer
>>>>>>
>>>>>> What is the output of mvn -e -X ...
>>>>>>
>>>>>> Brett
>>>>>>
>>>>>> On Fri, Nov 20, 2009 at 11:41 AM, Ellecer Valencia <ellecer@...
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> How come when I try a build using Maven 2.2.1 I get multiple messages
>>>>>
>>>>> like
>>>>>>>
>>>>>>> this:
>>>>>>>
>>>>>>> "[WARNING] POM for 'mypackage.artifact:pom:1.0.2-SNAPSHOT:compile' is
>>>>>>> invalid.
>>>>>>>
>>>>>>> Its dependencies (if any) will NOT be available to the current build."
>>>>>>>
>>>>>>> These errors weren't displaying when I was using Maven 2.0.10
>>>>>>>
>>>>>>> I'm trying to use the newer version of Maven but I can't proceed with
>>>>>>> these error messages.
>>>>>>>
>>>>>>> How can I find out what are the actual errors it's referring to? I
>>>>>>> didn't come across any mention of relevant POM format changes going
>>>>>>> from Maven 2.0.* to 2.1.* or 2.2.* - if anyone has any info on this it
>>>>>>> would be a great help! Is there a way to validate the pom and get
>>>>>>> format error details from Maven?
>>>>>>>
>>>>>>>
>>>>>>> thanks,
>>>>>>>
>>>>>>> Ellecer
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>>>> For additional commands, e-mail: users-help@...
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>> For additional commands, e-mail: users-help@...
>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[ANN] Signatures of Java Runtimes for use with Animal Sniffer released

2009-11-22T06:37:23Z

The Mojo team is pleased to announce the release of a number of
signatures of various versions of the Java Runtime for use with the
Animal Sniffer set of utilities.

The following signatures have been released:

Generic Signatures (only includes public API classes)
* Java 1.3 (http://mojo.codehaus.org/signatures/java13/)

Signatures including Sun implementation classes:
* Sun Java 1.3 (http://mojo.codehaus.org/signatures/java13-sun/)

Signatures including IBM implementation classes:
* IBM Java 1.4 (http://mojo.codehaus.org/signatures/java14-ibm/)

Signatures including Oracle JRockit implementation classes:
* Oracle JRockit Java 1.4
(http://mojo.codehaus.org/signatures/java14-jrockit/)

Animal Sniffer provides three tools that can use these signatures:

* A Maven Plugin
(http://mojo.codehaus.org/animal-sniffer-maven-plugin/index.html)
* ANT Tasks
(http://mojo.codehaus.org/animal-sniffer/animal-sniffer-ant-tasks/index.html)
* A Maven Enforcer Rule
(http://mojo.codehaus.org/animal-sniffer/animal-sniffer-enforcer-rule/index.html)

The artifacts have been deployed to the codehaus repository and have
been/will be mirrored to central.

The Mojo Team.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

http://www.davidkarlsen.com

Re: how to copy jar (also) to target installation dir

2009-11-22T06:21:57Z

It should work with the antrun plugin ( and ant's <copy> task. )

( configure an antrun plugin execution to attach to install phase )

--sony

On Sun, Nov 22, 2009 at 8:43 AM, eyal edri <eyal.edri@...> wrote:

> I want to config the pom project to copy the final jar file to an
> installation dir and bind it to the 'install' phase.
>
> meaning, when i "just" build the project, the jar will be built into the
> default target/project.jar.
>
> but when i "install" it should be also should be copied to
> /usr/local/application/project.jar.
>
> i tried adding "<OutputDirectory> in the 'jar' plugin, but it just changed
> the default target.
>
> --
> Eyal Edri
>

Re: how to copy jar (also) to target installation dir

2009-11-22T06:19:36Z

your best bet is to bind an execution of the antrun plugin to the
install phase and use the ant copy task to copy the file for you

Sent from my [rhymes with tryPod] ;-)

On 22 Nov 2009, at 13:43, eyal edri <eyal.edri@...> wrote:

> I want to config the pom project to copy the final jar file to an
> installation dir and bind it to the 'install' phase.
>
> meaning, when i "just" build the project, the jar will be built into
> the
> default target/project.jar.
>
> but when i "install" it should be also should be copied to
> /usr/local/application/project.jar.
>
> i tried adding "<OutputDirectory> in the 'jar' plugin, but it just
> changed
> the default target.
>
> --
> Eyal Edri

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: Refactoring question

2009-11-22T06:18:10Z

I find intellij has great refactoring support... and there is now a
free (as in apache licensed) version available

in intellij you just go file | open project, point it at your pom.xml
and it will open your project with everything just configured. then
just drag and drop your java sources into the packages you want
committing as you go and you're done

(netbeans and eclipse have similar support, but in my experience
intellij is best for refactoring)

-Stephen

Sent from my [rhymes with tryPod] ;-)

On 22 Nov 2009, at 13:41, neo anderson <javadeveloper999@...>
wrote:

>
> I use maven 2.0.9, jdk 1.6.0_10 to build my project.
>
> Now I encounter a dilemma. I have source code e.g. example/ioc/
> MyIoc.java,
> example/ioc/tapestry5/MyIocWrapper.java and related Test files. They
> are
> located in different folders at the beginning.
>
> Now I want to reorganize/ refactor the source code. So the structure
> may
> become example/ioc/MyIoc.java, example/ioc/MyIocWrapper.java.
> However, there
> are many classes which has similar situation. That means they may
> just be
> located in different folders.
>
> As I understand, in eclipse a developer can simply right-click and
> choose
> refactoring after modifying the source, then related source code in
> other
> classes would be changed as well. So I would like to know is there any
> chance this can be achieve using maven plugin? Or generally people
> who use
> maven (but don't use eclipse) would recommend the best approach?
>
> I appreciate any suggestion.
>
> Thank you very much.
> --
> View this message in context: http://old.nabble.com/Refactoring-question-tp26464173p26464173.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: "[WARNING] POM is invalid." error messages in Maven 2.2.1 but not in 2.0.10

2009-11-22T06:06:53Z

Hi Brian,

Could you please clarify what's actually "plain wrong" about it?

Going back to the example I posted:

<dependency>
<groupId>com.sun</groupId>
<artifactId>rt</artifactId>
<version>1.5.0.11</version>
<scope>system</scope>
<systemPath>${java.home}/lib/rt.jar</systemPath>
</dependency>
<dependency>
<groupId>weblogic</groupId>
<artifactId>weblogic</artifactId>
<version>10.0</version>
<scope>system</scope>
<systemPath>${env.WL_HOME}/server/lib/weblogic.jar</systemPath>
</dependency>

Do you mean the first one, referencing "${java.home}" is correct and
the one referencing "${env.WL_HOME}" is wrong? So what should we do to
make it work?

thanks,

Ellecer

On Sat, Nov 21, 2009 at 4:33 AM, Brian E. Fox <brianf@...> wrote:

>>
>>
>> Maybe 2.2.2 will fix it. =)
>
> Not likely. The pom is plain wrong an it was a bug in 2.x which allowed it
> to go unnoticed.
>
>> On Fri, Nov 20, 2009 at 3:42 PM, Brett Randall <javabrett@...>
>> wrote:
>>>
>>> http://jira.codehaus.org/browse/MNG-4379 ... or did your team log that
>>> :).
>>>
>>> On Fri, Nov 20, 2009 at 2:59 PM, Ellecer Valencia <ellecer@...>
>>> wrote:
>>>
>>>> Hi Brett,
>>>>
>>>> Thanks for the suggestion. I may have found the issue. Would it be this:
>>>>
>>>>
>>>> Validation Errors:
>>>> [DEBUG] For dependency Dependency {groupId=weblogic,
>>>> artifactId=weblogic, version=10.0, type=jar}: system-scoped dependency
>>>> must specify an absolute path systemPath.
>>>> [DEBUG] For managed dependency Dependency {groupId=weblogic,
>>>> artifactId=weblogic, version=10.0, type=jar}: system-scoped dependency
>>>> must specify an absolute path systemPath.
>>>> [DEBUG]
>>>>
>>>> [DEBUG] mypackage:myartifact:jar:1.0.2:compile (selected for compile)
>>>> [DEBUG] Skipping disabled repository central
>>>> [DEBUG] myartifact: using locally installed snapshot
>>>> [WARNING] POM for 'mypackage:myartifact:pom:1.0.2-SNAPSHOT:test' is
>>>> invalid.
>>>>
>>>> Its dependencies (if any) will NOT be available to the current build.
>>>> [DEBUG] Reason: Failed to validate POM for project
>>>> mypackage:myartifact at Artifact
>>>> [mypackage:myartifact:pom:1.0.2-SNAPSHOT:test]
>>>> [DEBUG]
>>>> Validation Errors:
>>>> [DEBUG] For dependency Dependency {groupId=weblogic,
>>>> artifactId=weblogic, version=10.0, type=jar}: system-scoped dependency
>>>> must specify an absolute path systemPath.
>>>> [DEBUG] For dependency Dependency {groupId=weblogic,
>>>> artifactId=webservices, version=10.0, type=jar}: system-scoped
>>>> dependency must specify an absolute path systemPath.
>>>> [DEBUG] For managed dependency Dependency {groupId=weblogic,
>>>> artifactId=weblogic, version=10.0, type=jar}: system-scoped dependency
>>>> must specify an absolute path systemPath.
>>>> [DEBUG] For managed dependency Dependency {groupId=weblogic,
>>>> artifactId=webservices, version=10.0, type=jar}: system-scoped
>>>> dependency must specify an absolute path systemPath.
>>>> [DEBUG]
>>>>
>>>>
>>>> Now in this project, we are inheriting from a parent POM (standardised
>>>> for our department) with entries like this:
>>>> (WL_HOME is Weblogic install directory)
>>>>
>>>>
>>>> <dependency>
>>>> <groupId>com.sun</groupId>
>>>> <artifactId>tools</artifactId>
>>>> <version>1.5.0.11</version>
>>>> <scope>system</scope>
>>>> <systemPath>${java.home}/../lib/tools.jar</systemPath>
>>>> </dependency>
>>>> <dependency>
>>>> <groupId>com.sun</groupId>
>>>> <artifactId>rt</artifactId>
>>>> <version>1.5.0.11</version>
>>>> <scope>system</scope>
>>>> <systemPath>${java.home}/lib/rt.jar</systemPath>
>>>> </dependency>
>>>> <dependency>
>>>> <groupId>weblogic</groupId>
>>>> <artifactId>weblogic</artifactId>
>>>> <version>10.0</version>
>>>> <scope>system</scope>
>>>> <systemPath>${env.WL_HOME}/server/lib/weblogic.jar</systemPath>
>>>> </dependency>
>>>> <dependency>
>>>> <groupId>weblogic</groupId>
>>>> <artifactId>webservices</artifactId>
>>>> <version>10.0</version>
>>>> <scope>system</scope>
>>>> <systemPath>${env.WL_HOME}/server/lib/webservices.jar</systemPath>
>>>> </dependency>
>>>>
>>>>
>>>> Now it only fails on the Weblogic related entries. With the Java
>>>> system dependencies it seems to do fine.
>>>>
>>>> Has the handling of this changed from 2.0.* to 2.2.*?
>>>>
>>>> If so, what should we replace it with?
>>>>
>>>> And will these settings also work for people still using maven 2.0.10?
>>>>
>>>>
>>>> Ellecer
>>>>
>>>>
>>>>
>>>> On Fri, Nov 20, 2009 at 1:01 PM, Brett Randall <javabrett@...>
>>>> wrote:
>>>>>
>>>>> Hi Ellecer
>>>>>
>>>>> What is the output of mvn -e -X ...
>>>>>
>>>>> Brett
>>>>>
>>>>> On Fri, Nov 20, 2009 at 11:41 AM, Ellecer Valencia <ellecer@...
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> How come when I try a build using Maven 2.2.1 I get multiple messages
>>>>
>>>> like
>>>>>>
>>>>>> this:
>>>>>>
>>>>>> "[WARNING] POM for 'mypackage.artifact:pom:1.0.2-SNAPSHOT:compile' is
>>>>>> invalid.
>>>>>>
>>>>>> Its dependencies (if any) will NOT be available to the current build."
>>>>>>
>>>>>> These errors weren't displaying when I was using Maven 2.0.10
>>>>>>
>>>>>> I'm trying to use the newer version of Maven but I can't proceed with
>>>>>> these error messages.
>>>>>>
>>>>>> How can I find out what are the actual errors it's referring to? I
>>>>>> didn't come across any mention of relevant POM format changes going
>>>>>> from Maven 2.0.* to 2.1.* or 2.2.* - if anyone has any info on this it
>>>>>> would be a great help! Is there a way to validate the pom and get
>>>>>> format error details from Maven?
>>>>>>
>>>>>>
>>>>>> thanks,
>>>>>>
>>>>>> Ellecer
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>>> For additional commands, e-mail: users-help@...
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

how to copy jar (also) to target installation dir

2009-11-22T05:43:41Z

I want to config the pom project to copy the final jar file to an
installation dir and bind it to the 'install' phase.

meaning, when i "just" build the project, the jar will be built into the
default target/project.jar.

but when i "install" it should be also should be copied to
/usr/local/application/project.jar.

i tried adding "<OutputDirectory> in the 'jar' plugin, but it just changed
the default target.

--
Eyal Edri

Refactoring question

2009-11-22T05:41:20Z

I use maven 2.0.9, jdk 1.6.0_10 to build my project.

Now I encounter a dilemma. I have source code e.g. example/ioc/MyIoc.java, example/ioc/tapestry5/MyIocWrapper.java and related Test files. They are located in different folders at the beginning.

Now I want to reorganize/ refactor the source code. So the structure may become example/ioc/MyIoc.java, example/ioc/MyIocWrapper.java. However, there are many classes which has similar situation. That means they may just be located in different folders.

As I understand, in eclipse a developer can simply right-click and choose refactoring after modifying the source, then related source code in other classes would be changed as well. So I would like to know is there any chance this can be achieve using maven plugin? Or generally people who use maven (but don't use eclipse) would recommend the best approach?

I appreciate any suggestion.

Thank you very much.

Re: Excluding repositories

2009-11-21T07:44:22Z

2009/11/20 Gajo Csaba <csaba.gajo@...>:
> One of the dependencies is trying to access a repository at
> download.java.net, and this site is blocked by our firewall. Is there a way
> to tell Maven to skip this repository? Either in settings.xml or pom.xml

Best is to use an internal repository manager like Archiva or Nexus.

To keep Maven from trying to contact it, figure out the repository id,
and then re-define that id as a <repository> and <pluginRepository>
with a different url that does work.

I would do this in settings.xml so it only has to be done once rather
than in each project.
http://maven.apache.org/ref/2.0.8/maven-settings/settings.html

--
Wendy

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[ANN] Signature of Apple Java 1.6 Runtime for use with Animal Sniffer released

2009-11-21T05:05:07Z

Hi all,

I just released the signature of Apple Java 1.6 Runtime for use with
Animal Sniffer released.
You'll find documentation about Animal Sniffer here :
http://mojo.codehaus.org/animal-sniffer/
Apple Java 1.6 Signature doc is here :
http://mojo.codehaus.org/signatures/java16-apple/

Cheers,

Arnaud Héritier
Software Factory Manager
eXo platform - http://www.exoplatform.com
---
http://www.aheritier.net

Re: Project Builds

2009-11-21T03:03:25Z

you can use the dependency plugin, the goal
dependency:copy-dependencies<http://maven.apache.org/plugins/maven-dependency-plugin/>may
help you

On Fri, Nov 20, 2009 at 3:05 AM, Joel Schuster <joels@...> wrote:

> It seems that Maven good about particular artifacts, but I can't seem to
> figure out how to do multiple projects into one distribution...
>
> I have various OSGi based applications. The core OSGi framework with all
> the bundles that all our projects use in common are included in one project.
> There are a number of bundles that are 3rd party and a number that are
> internal to our company.
>
> How would I use Maven to not just help me control single projects, but
> rather the entire execution environment including all the runtime
> dependencies, configuration files and even the startup scripts?
>
> Is there a documented example to help me along? I don't see any
> documentation within Maven that would help me wrap this problem.
>
> ________________________________
>
> Joel Schuster
> Senior Software Engineer
> NAVSYS Corporation
> 14960 Woodcarver Road, Colorado Springs, CO 80921
> 719-481-4877
>
>
>
>

--
alien.sulin(苏琳冲)
SuLinchong
Qq 387973308
Msn sulinchong@...

Re: Excluding repositories

2009-11-21T02:56:59Z

Do you user Nexus as your local repo? it can block the repository

2009/11/20 Gajo Csaba <csaba.gajo@...>

> Hello,
>
> One of the dependencies is trying to access a repository at
> download.java.net, and this site is blocked by our firewall. Is there a
> way to tell Maven to skip this repository? Either in settings.xml or pom.xml
>
> Thanks, Csaba
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

--
alien.sulin(苏琳冲)
SuLinchong
Qq 387973308
Msn sulinchong@...

[ANN] Release Maven Findbugs plugin version 2.2

2009-11-20T17:28:02Z

The Findbugs Maven plugin team is pleased to announce the release of
version 2.2.

FindBugs uses static analysis to inspect Java bytecode for occurrences
of bug patterns.

You can see more about the plugin att:

http://mojo.codehaus.org/findbugs-maven-plugin/2.2/

You can find release notes for this version below, or at:

http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11701&version=15548

Release Notes - Maven 2.x FindBugs Plugin - Version 2.2

** Bug
* [MFINDBUGS-81] - Unable to provide references to "resources" in
excludeFilterFile/includeFilterFile configuration parameters in
seperate project
* [MFINDBUGS-82] - findbugs:findbugs fails if the target
directory does not exist
* [MFINDBUGS-86] - Changing project sourceEncoding to UTF-8
causing SAX parse error
* [MFINDBUGS-89] - Dependencies no longer properly passed to
findbugs for analysis
* [MFINDBUGS-91] - Don't remove deprecated fields like
findbugsXmlOutput
* [MFINDBUGS-93] - Unable to parse XML Findbugs report when
errors are reported on java code using generics

** New Feature
* [MFINDBUGS-18] - Allow to fork a VM that runs findbugs
* [MFINDBUGS-45] - Add timeout option
* [MFINDBUGS-46] - Add abilty set memory as an option

** Wish
* [MFINDBUGS-72] - Add option to generate html output for
findbugs:check

Enjoy,

Re: How do I prevent maven from searching my own artifacts in public repositories ?

2009-11-20T15:41:44Z

Yes, Artifactory supports filtering with include/exclude patterns for both
proxied and hosted repositories.

On Fri, Nov 20, 2009 at 12:55 PM, Anders Hammar <anders@...> wrote:

> I think that the battle today is between Nexus and Artifactory. Archiva has
> a few features that Nexus for instance lacks, but the development of
> Archiva
> is slower than Nexus for instance.
> Regarding Nexus or Artifactory you should which one fits your needs the
> best. Nexus supports the "filtering" you're talking about below (it's
> called
> routing rules in Nexus). Not sure about Artifactory.
>
> /Anders
>
> On Fri, Nov 20, 2009 at 09:03, TorstenKarusseit <torsten.karusseit@...
> >wrote:
>
> > Hi all,
> >
> > thank you very mutch.
> > I think Anders is right saying to use a repo manager,
> > wich has to filter the artifact request if it matchs a
> > predefined pattern of my project.
> >
> > Do anyone of you have experience with such a manager ?
> > Nexus or Archiva ?
> >
> > Torsten
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
> >
>

[ANN} Signatures of Java Runtimes for use with Animal Sniffer released

2009-11-20T14:31:51Z

The Mojo team is pleased to announce the release of a number of
signatures of various versions of the Java Runtime for use with the
Animal Sniffer set of utilities.

The following signatures have been released:

Generic Signatures (only includes public API classes)

* Java 1.4 (http://mojo.codehaus.org/signatures/java14/)
* Java 1.5 (http://mojo.codehaus.org/signatures/java15/)
* Java 1.6 (http://mojo.codehaus.org/signatures/java16/)

Signatures including Sun implementation classes:

* Sun Java 1.4 (http://mojo.codehaus.org/signatures/java14-sun/)
* Sun Java 1.5 (http://mojo.codehaus.org/signatures/java15-sun/)
* Sun Java 1.6 (http://mojo.codehaus.org/signatures/java16-sun/)

Signatures including IBM implementation classes:

* IBM Java 1.5 (http://mojo.codehaus.org/signatures/java15-ibm/)
* IBM Java 1.6 (http://mojo.codehaus.org/signatures/java16-ibm/)

Signatures including Oracle JRockit implementation classes:

* Oraacle JRockit Java 1.5 (http://mojo.codehaus.org/signatures/java15-jrockit/)
* Oraacle JRockit Java 1.6 (http://mojo.codehaus.org/signatures/java16-jrockit/)

Signatures including Apache Harmony implementation classes:

* Apache Harmony M11 Java 1.5
(http://mojo.codehaus.org/signatures/java15-harmony/)

Animal Sniffer provides three tools that can use these signatures:

* A Maven Plugin
(http://mojo.codehaus.org/animal-sniffer-maven-plugin/index.html)
* ANT Tasks (http://mojo.codehaus.org/animal-sniffer/animal-sniffer-ant-tasks/index.html)
* A Maven Enforcer Rule
(http://mojo.codehaus.org/animal-sniffer/animal-sniffer-enforcer-rule/index.html)

The artifacts have been deployed to the codehaus repository and have
been/will be mirrored to central.

The Mojo Team.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

RE: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?

2009-11-20T13:42:27Z

Yes, thanks for clarifying Brian.

Jon, I'm still wondering why you're adverse to running mvn clean install?

-----Original Message-----
From: Jonathan Gold [mailto:jgold.bg@...]
Sent: Friday, November 20, 2009 4:26 PM
To: users@...
Subject: Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?

Brian --

Thanks for this. I did run the combo 'mvn compile dependency:tree' as you mention below, and it works. What I'm taking away from this is that dependency:tree will work if it's part of the *same* mvn invocation as something like compile, which forces maven to do the resolution of the local workspace.
Doing 'mvn compile' and then 'mvn dependency:tree' thus does not work.

As a new user, this was (and still is) a bit bizarre, but I'm happy to know how to get it to work.

Thanks!

jon

On Fri, Nov 20, 2009 at 03:54:11PM -0500, Brian Fox wrote:

> This isn't exactly true. First, lets take a look at the stack trace:
>
> ----------
> 1 required artifact is missing.
>
> for artifact:
> com.example:mod_b:jar:1.0
>
> from the specified remote repositories:
> mynexus (http://192.168.101.21:8081/nexus/content/groups/public)
>
>
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra
> nsitively(DefaultArtifactResolver.java:360)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra
> nsitively(DefaultArtifactResolver.java:304)
> at
> org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDepende
> ncies(DefaultPluginManager.java:1499)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
> nManager.java:442)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
> ultLifecycleExecutor.java:694)
> ... 17 more
>
>
> Notice this is all core code. It's trying to resolve the dependencies
> prior to invoking the plugin. As I mentioned earlier in the thread,
> the plugin sets @requiresDependencyResolution test which tells Maven
> to resolve the test scope (which means everything) before invoking the
> plugin.
>
> If you only run "mvn dependency:tree" there are no references to the
> other projects in the reactor for Maven to find and use. Try running
> "mvn compile dependency:tree: and you'll see that it does in fact
> work. This is just a side effect of how maven 2.x does the resolution.
>
> Could we rewrite the dependency tree goal to completely work around
> this? Probably, but it would mean duplicating tons of core logic to
> make the resolution work in all cases and running tree on a not-yet
> compiled or installed project is an edge case imo.
>
>
> 2009/11/19 Jamie Whitehouse <Jamie.Whitehouse@...>:
> > Many of the dependency plugin goals are reactor aware, but dependency:tree isn't. I'm not too sure why, but you could search the issue tracker and if there's no issue for this file one.
> >
> > -----Original Message-----
> > From: Jonathan Gold [mailto:jgold.bg@...]
> > Sent: Thursday, November 19, 2009 3:00 PM
> > To: users@...
> > Subject: Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?
> >
> > Jamie --
> >
> > Thanks for trying it out, and for the explanation. This makes sense in terms of why things are happening, so that's nice.
> >
> > I'm not familiar with the dependency plugin developers (are you one?), and wonder if having the dependency plugin be reactor-aware is something they would consider? Perhaps its an old tired discussion and the decision to build that plugin the way it is is said and done.
> >
> > Thanks for your help!
> >
> > jon
> >
> > On Thu, Nov 19, 2009 at 11:43:33AM -0800, Jamie Whitehouse wrote:
> >> What maven commands did you issue to test this?
> >>
> >> I used the attached project and here's the results.
> >> 1) extract zip
> >> 2) mvn dependency:tree
> >> failed due to dependency resolution
> >> 3) mvn clean install
> >> 4) mvn dependency:tree
> >> see the tree output
> >>
> >> I think you're misunderstanding how the local maven repo is used and the affect reactor builds and plugins that are reactor aware vs not. AFAIK the dependency:tree goal is not reactor aware. It needs to resolve artifacts from the local repo (or download from remote repos if not present locally). Since you haven't mvn installed these into your local repo the tree goal states that the artifact is missing.
> >>
> >> The compile goal is reactor aware, and hence if you invoke mvn compile it determines the correct order in your multi-module build in order for mod_b to resolve the reference to mod_a. To test this reverse the order of the module definitions in the root pom and see that the reactor summary builds mod_a first despite the modules list having mod_b first.
> >>
> >> If you want to simulate what dependency:tree does using the compile goal, just try to compile mod_b on it's own, in it's own sub module (e.g. c:\maven-repro1\mod_b> mvn compile ), you'll get the same error about not being able to resolve dependencies.
> >>
> >> Hope that helps.
> >> Jamie.
> >>
> >> -----Original Message-----
> >> From: Jonathan Gold [mailto:jgold.bg@...]
> >> Sent: Thursday, November 19, 2009 12:52 PM
> >> To: users@...
> >> Subject: Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?
> >>
> >> Brian --
> >>
> >> Thanks for your help so far. I did put together a very small sample project that will repro what I'm seeing (attached as a zip). Just run 'mvn dependency:tree'
> >> in the root of the project and see if you get the same error (mod_a is not found, required by mod_b). It does compile fine.
> >>
> >> I'll be interested to see if you get the same results, or have some insights.
> >> It's totally likely that I'm not setting my poms up correctly.
> >>
> >> Thanks for any help you can give!
> >>
> >> jon
> >>
> >> On Wed, Nov 18, 2009 at 05:53:34PM -0500, Brian Fox wrote:
> >> > This is not related. The dependency plugin has some issues
> >> > resolving things from the reactor and ranges in the following goals only:
> >> > copy
> >> > unpack
> >> > go-offline
> >> > resolve-plugins
> >> >
> >> >
> >> > All the other goals set @requiresDependencyResolution test which
> >> > will cause Maven to resolve all dependencies prior to the plugin running.
> >> > So if you're seeing some error, it's happening in the core.
> >> > Provide a sample project and/or some debug output and we might be
> >> > able to tell what the problem is.
> >> >
> >> >
> >> > On Wed, Nov 18, 2009 at 12:59 PM, Stevo Slavić <sslavic@...> wrote:
> >> > > Likely because dependency plugin has bugs, and I'm suspecting
> >> > > that your issue is similar/related to this
> >> > > <http://jira.codehaus.org/browse/MDEP-204>one already reported.
> >> > >
> >> > > But it's odd that it doesn't fail for you at module mod_c, as
> >> > > build reactor should have ordered mod_c to be built/processed
> >> > > before mod_d. Just guessing, maybe this mojo doesn't use maven
> >> > > reactor at all, and probably mod_c is ordered in list of modules in your parent module after mod_d.
> >> > >
> >> > > Regards,
> >> > > Stevo.
> >> > >
> >> > > On Wed, Nov 18, 2009 at 6:37 PM, Jonathan Gold <jgold.bg@...> wrote:
> >> > >
> >> > >> Hi --
> >> > >>
> >> > >> I'm trying to track down some other depdendency issues in my
> >> > >> project using dependencies:tree, but am getting errors that a module isn't found.
> >> > >>
> >> > >> I have my project set up with a parent pom and a list of
> >> > >> modules, each referencing the parent, etc. Essentially, I have this:
> >> > >>
> >> > >> pom.xml # parent, references mods a, b, c, d in <modules>
> >> > >> mod_a/pom.xml # module, no module dependencies
> >> > >> mod_b/pom.xml # module, no module dependencies
> >> > >> mod_c/pom.xml # module, declared dependency on mod_b
> >> > >> mod_d/pom.xml # module, declared depdenency on mod_a,
> >> > >> mod_b, mod_c
> >> > >>
> >> > >> From the root workspace directory, I can run things like 'compile'
> >> > >> or 'jar:jar'
> >> > >> just fine, but for some reason 'dependencies:tree' is failing
> >> > >> when it gets to mod_d, complaining that it can't find mod_c.
> >> > >>
> >> > >> Any ideas what I'm doing wrong?
> >> > >>
> >> > >> jon
> >> > >>
> >> > >> --------------------------------------------------------------
> >> > >> ---
> >> > >> --
> >> > >> -- To unsubscribe, e-mail: users-unsubscribe@...
> >> > >> For additional commands, e-mail: users-help@...
> >> > >>
> >> > >>
> >> > >
> >> >
> >> > -----------------------------------------------------------------
> >> > ---
> >> > - To unsubscribe, e-mail: users-unsubscribe@...
> >> > For additional commands, e-mail: users-help@...
> >>
> >>
> >> -------------------------------------------------------------------
> >> ---
> >> ---------------------------------------------
> >> CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.
> >>
> >>
> >> -------------------------------------------------------------------
> >> -- To unsubscribe, e-mail: users-unsubscribe@...
> >> For additional commands, e-mail: users-help@...
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
> >
> >
> > --------------------------------------------------------------------
> > -----------------------------------------------
> > CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: Does Maven download jars every time it does any thing?

2009-11-20T13:32:37Z

On Fri, Nov 20, 2009 at 2:26 PM, chicagopooldude
<Seshu.Pitcha@...> wrote:

> Thanks Brian but home i see downloading downloading every time i do some
> thing as this is not the first time i am doing this. is there any way we can
> disable this atleast visually?

Paste a small section of the build log so someone can take a look.
Most likely it's what Brian said, there is a missing pom and it's
looking for that, not the jar.

--
Wendy

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: Does Maven download jars every time it does any thing?

2009-11-20T13:26:52Z

Thanks Brian but home i see downloading downloading every time i do some thing as this is not the first time i am doing this. is there any way we can disable this atleast visually?

Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?

2009-11-20T13:26:25Z

Brian --

Thanks for this. I did run the combo 'mvn compile dependency:tree' as you
mention below, and it works. What I'm taking away from this is that
dependency:tree will work if it's part of the *same* mvn invocation as something
like compile, which forces maven to do the resolution of the local workspace.
Doing 'mvn compile' and then 'mvn dependency:tree' thus does not work.

As a new user, this was (and still is) a bit bizarre, but I'm happy to know how
to get it to work.

Thanks!

jon

On Fri, Nov 20, 2009 at 03:54:11PM -0500, Brian Fox wrote:

> This isn't exactly true. First, lets take a look at the stack trace:
>
> ----------
> 1 required artifact is missing.
>
> for artifact:
> com.example:mod_b:jar:1.0
>
> from the specified remote repositories:
> mynexus (http://192.168.101.21:8081/nexus/content/groups/public)
>
>
> at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra
> nsitively(DefaultArtifactResolver.java:360)
> at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra
> nsitively(DefaultArtifactResolver.java:304)
> at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDepende
> ncies(DefaultPluginManager.java:1499)
> at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
> nManager.java:442)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
> ultLifecycleExecutor.java:694)
> ... 17 more
>
>
> Notice this is all core code. It's trying to resolve the dependencies
> prior to invoking the plugin. As I mentioned earlier in the thread,
> the plugin sets @requiresDependencyResolution test which tells Maven
> to resolve the test scope (which means everything) before invoking the
> plugin.
>
> If you only run "mvn dependency:tree" there are no references to the
> other projects in the reactor for Maven to find and use. Try running
> "mvn compile dependency:tree: and you'll see that it does in fact
> work. This is just a side effect of how maven 2.x does the resolution.
>
> Could we rewrite the dependency tree goal to completely work around
> this? Probably, but it would mean duplicating tons of core logic to
> make the resolution work in all cases and running tree on a not-yet
> compiled or installed project is an edge case imo.
>
>
> 2009/11/19 Jamie Whitehouse <Jamie.Whitehouse@...>:
> > Many of the dependency plugin goals are reactor aware, but dependency:tree isn't. I'm not too sure why, but you could search the issue tracker and if there's no issue for this file one.
> >
> > -----Original Message-----
> > From: Jonathan Gold [mailto:jgold.bg@...]
> > Sent: Thursday, November 19, 2009 3:00 PM
> > To: users@...
> > Subject: Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?
> >
> > Jamie --
> >
> > Thanks for trying it out, and for the explanation. This makes sense in terms of why things are happening, so that's nice.
> >
> > I'm not familiar with the dependency plugin developers (are you one?), and wonder if having the dependency plugin be reactor-aware is something they would consider? Perhaps its an old tired discussion and the decision to build that plugin the way it is is said and done.
> >
> > Thanks for your help!
> >
> > jon
> >
> > On Thu, Nov 19, 2009 at 11:43:33AM -0800, Jamie Whitehouse wrote:
> >> What maven commands did you issue to test this?
> >>
> >> I used the attached project and here's the results.
> >> 1) extract zip
> >> 2) mvn dependency:tree
> >> failed due to dependency resolution
> >> 3) mvn clean install
> >> 4) mvn dependency:tree
> >> see the tree output
> >>
> >> I think you're misunderstanding how the local maven repo is used and the affect reactor builds and plugins that are reactor aware vs not. AFAIK the dependency:tree goal is not reactor aware. It needs to resolve artifacts from the local repo (or download from remote repos if not present locally). Since you haven't mvn installed these into your local repo the tree goal states that the artifact is missing.
> >>
> >> The compile goal is reactor aware, and hence if you invoke mvn compile it determines the correct order in your multi-module build in order for mod_b to resolve the reference to mod_a. To test this reverse the order of the module definitions in the root pom and see that the reactor summary builds mod_a first despite the modules list having mod_b first.
> >>
> >> If you want to simulate what dependency:tree does using the compile goal, just try to compile mod_b on it's own, in it's own sub module (e.g. c:\maven-repro1\mod_b> mvn compile ), you'll get the same error about not being able to resolve dependencies.
> >>
> >> Hope that helps.
> >> Jamie.
> >>
> >> -----Original Message-----
> >> From: Jonathan Gold [mailto:jgold.bg@...]
> >> Sent: Thursday, November 19, 2009 12:52 PM
> >> To: users@...
> >> Subject: Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?
> >>
> >> Brian --
> >>
> >> Thanks for your help so far. I did put together a very small sample project that will repro what I'm seeing (attached as a zip). Just run 'mvn dependency:tree'
> >> in the root of the project and see if you get the same error (mod_a is not found, required by mod_b). It does compile fine.
> >>
> >> I'll be interested to see if you get the same results, or have some insights.
> >> It's totally likely that I'm not setting my poms up correctly.
> >>
> >> Thanks for any help you can give!
> >>
> >> jon
> >>
> >> On Wed, Nov 18, 2009 at 05:53:34PM -0500, Brian Fox wrote:
> >> > This is not related. The dependency plugin has some issues resolving
> >> > things from the reactor and ranges in the following goals only:
> >> > copy
> >> > unpack
> >> > go-offline
> >> > resolve-plugins
> >> >
> >> >
> >> > All the other goals set @requiresDependencyResolution test which
> >> > will cause Maven to resolve all dependencies prior to the plugin running.
> >> > So if you're seeing some error, it's happening in the core. Provide
> >> > a sample project and/or some debug output and we might be able to
> >> > tell what the problem is.
> >> >
> >> >
> >> > On Wed, Nov 18, 2009 at 12:59 PM, Stevo Slavić <sslavic@...> wrote:
> >> > > Likely because dependency plugin has bugs, and I'm suspecting that
> >> > > your issue is similar/related to this
> >> > > <http://jira.codehaus.org/browse/MDEP-204>one already reported.
> >> > >
> >> > > But it's odd that it doesn't fail for you at module mod_c, as
> >> > > build reactor should have ordered mod_c to be built/processed
> >> > > before mod_d. Just guessing, maybe this mojo doesn't use maven
> >> > > reactor at all, and probably mod_c is ordered in list of modules in your parent module after mod_d.
> >> > >
> >> > > Regards,
> >> > > Stevo.
> >> > >
> >> > > On Wed, Nov 18, 2009 at 6:37 PM, Jonathan Gold <jgold.bg@...> wrote:
> >> > >
> >> > >> Hi --
> >> > >>
> >> > >> I'm trying to track down some other depdendency issues in my
> >> > >> project using dependencies:tree, but am getting errors that a module isn't found.
> >> > >>
> >> > >> I have my project set up with a parent pom and a list of modules,
> >> > >> each referencing the parent, etc. Essentially, I have this:
> >> > >>
> >> > >> pom.xml # parent, references mods a, b, c, d in <modules>
> >> > >> mod_a/pom.xml # module, no module dependencies
> >> > >> mod_b/pom.xml # module, no module dependencies
> >> > >> mod_c/pom.xml # module, declared dependency on mod_b
> >> > >> mod_d/pom.xml # module, declared depdenency on mod_a, mod_b,
> >> > >> mod_c
> >> > >>
> >> > >> From the root workspace directory, I can run things like 'compile'
> >> > >> or 'jar:jar'
> >> > >> just fine, but for some reason 'dependencies:tree' is failing
> >> > >> when it gets to mod_d, complaining that it can't find mod_c.
> >> > >>
> >> > >> Any ideas what I'm doing wrong?
> >> > >>
> >> > >> jon
> >> > >>
> >> > >> -----------------------------------------------------------------
> >> > >> --
> >> > >> -- To unsubscribe, e-mail: users-unsubscribe@...
> >> > >> For additional commands, e-mail: users-help@...
> >> > >>
> >> > >>
> >> > >
> >> >
> >> > --------------------------------------------------------------------
> >> > - To unsubscribe, e-mail: users-unsubscribe@...
> >> > For additional commands, e-mail: users-help@...
> >>
> >>
> >> ----------------------------------------------------------------------
> >> ---------------------------------------------
> >> CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@...
> >> For additional commands, e-mail: users-help@...
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
> >
> >
> > -------------------------------------------------------------------------------------------------------------------
> > CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: ejb-jar plug-in - Can we add dependency jars to ejb-jar.jar

2009-11-20T13:01:56Z

In my current project, they use ant and pack all the jars inside the ejb-jar.jar.
Now, they are thinking of migrating to maven from ant, but still want to pack the jars inside ejb-jar.jar.

Is there anyway to do this without exploding the dependencies into my jar.

Other way is to keep the jars in ear lib directory. But I don't want to do this because these jars are being used only by one ejb project and other ejb and web modules doesn't need these jars.

Stephen Connolly-2 wrote:

the jar spec does not support jar files within jar files (technically
Java's URL support only goes one level deep: eg jar:url/to/file!path/
in/jar is allowed, but jar:jar:url/to/file!path/in/jar!path/in/jar is
not) so while you could copy the jar files inside your ejb jar,
nothing will be loaded from it

what you can do is explode your dependencies into your jar. there are
two tools you can use for this: dependency:unpack-dependencies or the
maven-shade-plugin

Sent from my [rhymes with tryPod] ;-)

On 19 Nov 2009, at 19:00, "Medishetty, Rajendar" <Rajendar.Medishetty@gs.com
> wrote:

> Hi,
>
> I'm using ejb-jar plugin to generate the ejb-jar.jar.
>
> I have some library jars, which are only used by this ejbModule. So
> I want them to be packaged inside ejb-jar.jar file only and I don't
> want them to place them in ear lib directory.
> I couldn't find anything with ejb-jar plug-in to package these jars
> into ejb-jar.jar file.
>
> Is there any way to do that.
>
> Thanks,
> Rajendar
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Putting a Release in the Repository

2009-11-20T12:56:25Z

Sounds like your scm urls aren't right and the perform goal is
checking out the wrong folder. There should be a pom.xml for the thing
you're trying to release in /target/checkout/

On Thu, Nov 19, 2009 at 2:43 PM, Neil Chaudhuri
<nchaudhuri@...> wrote:

> I have done those things, but I get the following error:
>
> [INFO] [INFO] Cannot execute mojo: clean. It requires a project with an existing pom.xml, but the build is not using one.
>
> I thought that error only occurred when the URL to the repo was incorrect. Since I am able to do a release:prepare and see the project tagged in SVN, I imagine that isn't the case.
>
> It occurred to me that this could be a flatness issue. My release in SVN looks like this:
>
> myapp-0.8.1
> --parent
> --persistence
> --services
>
> Each of these represents a module with its own pom. Shockingly, parent is the parent module for the others. There is no pom at the myapp-0.8.1 level, so that would explain the error.
>
> Because of the flatness issue, I had to add configure the release plugin in the following fashion for it to work:
>
> <configuration>
> <tagWorkingDirectory>${basedir}/..</tagWorkingDirectory>
> <updateWorkingCopyVersions>false</updateWorkingCopyVersions>
> <preparationGoals>clean install</preparationGoals>
> <goals>clean install</goals>
> <arguments>-Dmaven.test.skip</arguments>
> <tagBase>svn://<url>/data/svn/project/tags</tagBase>
> <autoVersionSubmodules>true</autoVersionSubmodules>
> </configuration>
>
>
> Given this setup, how can I do the release? Any insight is appreciated.
>
> Thanks.
>
>
>
> -----Original Message-----
> From: Stevo Slavić [mailto:sslavic@...]
> Sent: Thursday, November 19, 2009 2:22 PM
> To: Maven Users List
> Subject: Re: Putting a Release in the Repository
>
> http://weblogs.java.net/blog/2008/08/31/using-maven-release-plugin
>
> http://www.vineetmanohar.com/2009/10/23/how-to-automate-project-versioning-and-release-with-maven/
>
> Regards,
> Stevo.
>
> On Thu, Nov 19, 2009 at 8:19 PM, Stephen Connolly <
> stephen.alan.connolly@...> wrote:
>
>> mvn release:perform
>> after the prepare
>>
>> Sent from my [rhymes with tryPod] ;-)
>>
>>
>> On 19 Nov 2009, at 19:11, "Neil Chaudhuri" <nchaudhuri@...>
>> wrote:
>>
>> I am using the prepare goal of the Maven Release Plugin to publish a
>>> release in SVN. The result of course is that the poms in the trunk and
>>> in my local copy are updated to the next version snapshot. What I want
>>> to do is to take the release in SVN and publish it to my local Nexus
>>> repository in the releases portion of the site. I am doing the same for
>>> snapshots by using the Maven Deploy Plugin.
>>>
>>>
>>>
>>> I suppose my question is how can I get the Maven Release and Deploy
>>> Plugins to work in tandem so that I can release something to SVN and
>>> then have it be deployed to my local Nexus repository.
>>>
>>>
>>>
>>> Thanks.
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: Does Maven download jars every time it does any thing?

2009-11-20T12:55:11Z

No it doesn't. They are stored in your local repo. Snapshots are
checked once a day for updates. If however you are using something
that doesn't have a pom, then it will try everytime looking for it.

On Fri, Nov 20, 2009 at 3:52 PM, chicagopooldude
<Seshu.Pitcha@...> wrote:

>
> I understand that local repos need to have all the dependency jars first time
> but does maven really download jars every time I do compile,install etc.
> Cause the info messages seem to suggest some thing like that?
> --
> View this message in context: http://old.nabble.com/Does-Maven-download-jars-every-time-it-does-any-thing--tp26448882p26448882.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: Does Maven download jars every time it does any thing?

2009-11-20T12:54:50Z

No, if it's already in your local repo it will not download it again.

-Dave

On Fri, Nov 20, 2009 at 1:52 PM, chicagopooldude
<Seshu.Pitcha@...>wrote:

>
> I understand that local repos need to have all the dependency jars first
> time
> but does maven really download jars every time I do compile,install etc.
> Cause the info messages seem to suggest some thing like that?
> --
> View this message in context:
> http://old.nabble.com/Does-Maven-download-jars-every-time-it-does-any-thing--tp26448882p26448882.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?

2009-11-20T12:54:11Z

This isn't exactly true. First, lets take a look at the stack trace:

----------
1 required artifact is missing.

for artifact:
com.example:mod_b:jar:1.0

from the specified remote repositories:
mynexus (http://192.168.101.21:8081/nexus/content/groups/public)

at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra
nsitively(DefaultArtifactResolver.java:360)
at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra
nsitively(DefaultArtifactResolver.java:304)
at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDepende
ncies(DefaultPluginManager.java:1499)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:442)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:694)
... 17 more

Notice this is all core code. It's trying to resolve the dependencies
prior to invoking the plugin. As I mentioned earlier in the thread,
the plugin sets @requiresDependencyResolution test which tells Maven
to resolve the test scope (which means everything) before invoking the
plugin.

If you only run "mvn dependency:tree" there are no references to the
other projects in the reactor for Maven to find and use. Try running
"mvn compile dependency:tree: and you'll see that it does in fact
work. This is just a side effect of how maven 2.x does the resolution.

Could we rewrite the dependency tree goal to completely work around
this? Probably, but it would mean duplicating tons of core logic to
make the resolution work in all cases and running tree on a not-yet
compiled or installed project is an edge case imo.

2009/11/19 Jamie Whitehouse <Jamie.Whitehouse@...>:

> Many of the dependency plugin goals are reactor aware, but dependency:tree isn't. I'm not too sure why, but you could search the issue tracker and if there's no issue for this file one.
>
> -----Original Message-----
> From: Jonathan Gold [mailto:jgold.bg@...]
> Sent: Thursday, November 19, 2009 3:00 PM
> To: users@...
> Subject: Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?
>
> Jamie --
>
> Thanks for trying it out, and for the explanation. This makes sense in terms of why things are happening, so that's nice.
>
> I'm not familiar with the dependency plugin developers (are you one?), and wonder if having the dependency plugin be reactor-aware is something they would consider? Perhaps its an old tired discussion and the decision to build that plugin the way it is is said and done.
>
> Thanks for your help!
>
> jon
>
> On Thu, Nov 19, 2009 at 11:43:33AM -0800, Jamie Whitehouse wrote:
>> What maven commands did you issue to test this?
>>
>> I used the attached project and here's the results.
>> 1) extract zip
>> 2) mvn dependency:tree
>> failed due to dependency resolution
>> 3) mvn clean install
>> 4) mvn dependency:tree
>> see the tree output
>>
>> I think you're misunderstanding how the local maven repo is used and the affect reactor builds and plugins that are reactor aware vs not. AFAIK the dependency:tree goal is not reactor aware. It needs to resolve artifacts from the local repo (or download from remote repos if not present locally). Since you haven't mvn installed these into your local repo the tree goal states that the artifact is missing.
>>
>> The compile goal is reactor aware, and hence if you invoke mvn compile it determines the correct order in your multi-module build in order for mod_b to resolve the reference to mod_a. To test this reverse the order of the module definitions in the root pom and see that the reactor summary builds mod_a first despite the modules list having mod_b first.
>>
>> If you want to simulate what dependency:tree does using the compile goal, just try to compile mod_b on it's own, in it's own sub module (e.g. c:\maven-repro1\mod_b> mvn compile ), you'll get the same error about not being able to resolve dependencies.
>>
>> Hope that helps.
>> Jamie.
>>
>> -----Original Message-----
>> From: Jonathan Gold [mailto:jgold.bg@...]
>> Sent: Thursday, November 19, 2009 12:52 PM
>> To: users@...
>> Subject: Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?
>>
>> Brian --
>>
>> Thanks for your help so far. I did put together a very small sample project that will repro what I'm seeing (attached as a zip). Just run 'mvn dependency:tree'
>> in the root of the project and see if you get the same error (mod_a is not found, required by mod_b). It does compile fine.
>>
>> I'll be interested to see if you get the same results, or have some insights.
>> It's totally likely that I'm not setting my poms up correctly.
>>
>> Thanks for any help you can give!
>>
>> jon
>>
>> On Wed, Nov 18, 2009 at 05:53:34PM -0500, Brian Fox wrote:
>> > This is not related. The dependency plugin has some issues resolving
>> > things from the reactor and ranges in the following goals only:
>> > copy
>> > unpack
>> > go-offline
>> > resolve-plugins
>> >
>> >
>> > All the other goals set @requiresDependencyResolution test which
>> > will cause Maven to resolve all dependencies prior to the plugin running.
>> > So if you're seeing some error, it's happening in the core. Provide
>> > a sample project and/or some debug output and we might be able to
>> > tell what the problem is.
>> >
>> >
>> > On Wed, Nov 18, 2009 at 12:59 PM, Stevo Slavić <sslavic@...> wrote:
>> > > Likely because dependency plugin has bugs, and I'm suspecting that
>> > > your issue is similar/related to this
>> > > <http://jira.codehaus.org/browse/MDEP-204>one already reported.
>> > >
>> > > But it's odd that it doesn't fail for you at module mod_c, as
>> > > build reactor should have ordered mod_c to be built/processed
>> > > before mod_d. Just guessing, maybe this mojo doesn't use maven
>> > > reactor at all, and probably mod_c is ordered in list of modules in your parent module after mod_d.
>> > >
>> > > Regards,
>> > > Stevo.
>> > >
>> > > On Wed, Nov 18, 2009 at 6:37 PM, Jonathan Gold <jgold.bg@...> wrote:
>> > >
>> > >> Hi --
>> > >>
>> > >> I'm trying to track down some other depdendency issues in my
>> > >> project using dependencies:tree, but am getting errors that a module isn't found.
>> > >>
>> > >> I have my project set up with a parent pom and a list of modules,
>> > >> each referencing the parent, etc. Essentially, I have this:
>> > >>
>> > >> pom.xml # parent, references mods a, b, c, d in <modules>
>> > >> mod_a/pom.xml # module, no module dependencies
>> > >> mod_b/pom.xml # module, no module dependencies
>> > >> mod_c/pom.xml # module, declared dependency on mod_b
>> > >> mod_d/pom.xml # module, declared depdenency on mod_a, mod_b,
>> > >> mod_c
>> > >>
>> > >> From the root workspace directory, I can run things like 'compile'
>> > >> or 'jar:jar'
>> > >> just fine, but for some reason 'dependencies:tree' is failing
>> > >> when it gets to mod_d, complaining that it can't find mod_c.
>> > >>
>> > >> Any ideas what I'm doing wrong?
>> > >>
>> > >> jon
>> > >>
>> > >> -----------------------------------------------------------------
>> > >> --
>> > >> -- To unsubscribe, e-mail: users-unsubscribe@...
>> > >> For additional commands, e-mail: users-help@...
>> > >>
>> > >>
>> > >
>> >
>> > --------------------------------------------------------------------
>> > - To unsubscribe, e-mail: users-unsubscribe@...
>> > For additional commands, e-mail: users-help@...
>>
>>
>> ----------------------------------------------------------------------
>> ---------------------------------------------
>> CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
>
> -------------------------------------------------------------------------------------------------------------------
> CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Does Maven download jars every time it does any thing?

2009-11-20T12:52:49Z

I understand that local repos need to have all the dependency jars first time but does maven really download jars every time I do compile,install etc. Cause the info messages seem to suggest some thing like that?

RE: [WAR-plugin] Can I put my resources in their original folder?

2009-11-20T12:48:38Z

Great!
It works now.
Thanks very much, I was worried there for a while =)
/Ludwig

-----Original Message-----
From: Joe Hindsley [mailto:jhindsley@...]
Sent: den 20 november 2009 20:57
To: Ludwig Magnusson
Cc: 'Maven Users List'
Subject: Re: [WAR-plugin] Can I put my resources in their original folder?

Ludwig,

I think I misunderstood what you were asking in the original email. Let
me try again...

If I understand correctly, you want to keep the 'external' resource
directory name in the root of the war instead of copying it's contents
to the root of the war. This can be accomplished by adding a
<targetPath> element to the resource definition. My example below
assumes you are renaming the resource2 directory to myTarget in the war.

In your case, with a webResource definition like:

<configuration>
<webResources>
<resource>
<directory>resource2</directory>
<targetPath>myTarget</targetPath>
</resource>
</webResources>
</configuration>

Applied to a project layout like:

pom.xml
resource2/external-resource.jpg
resource2/image2/external-resource2.jpg
src/main/webapp/WEB-INF/web.xml
...

Would produce a war layout like:

myTarget/external-resource.jpg
myTarget/image2/external-resource2.jpg
WEB-INF/web.xml

Hopefully this is the answer you're looking for.

Joe Hindsley

Ludwig Magnusson wrote:

<http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering-
>> webresources.html>
>>
>
http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering-w
>> ebresources.html says that resources outside the src folder will be
placed

>> in the root of the war
>>
>>
>>
>> Ex, with this filestructure:
>>
>> |-- pom.xml
>>
>> |-- resource2
>>
>> | |-- external-resource.jpg
>>
>> | `-- image2
>>
>> | `-- external-resource2.jpg
>>
>> //more structure
>>
>>
>>
>> And this configuration of the war-plugin
>>
>> <configuration>
>> <webResources>
>> <resource>
>> 
>> <directory>resource2</directory>
>> </resource>
>> </webResources>
>> </configuration>
>>
>>
>>
>> The war file will be structured like this:
>>
>>
>>
>> //more structure
>>
>> |-- external-resource.jpg
>> |-- image2
>> | `-- external-resource2.jpg
>>
>>
>>
>> Is it possible to structure the war-file like the original filestructure?
>>
>> I.e having all the extra resources in the resource2-folder, and that
> folder
>> in the root of the war-file?
>>
>> /Ludwig
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: [WAR-plugin] Can I put my resources in their original folder?

2009-11-20T11:57:17Z

Ludwig,

I think I misunderstood what you were asking in the original email. Let
me try again...

If I understand correctly, you want to keep the 'external' resource
directory name in the root of the war instead of copying it's contents
to the root of the war. This can be accomplished by adding a
<targetPath> element to the resource definition. My example below
assumes you are renaming the resource2 directory to myTarget in the war.

In your case, with a webResource definition like:

<configuration>
<webResources>
<resource>
<directory>resource2</directory>
<targetPath>myTarget</targetPath>
</resource>
</webResources>
</configuration>

Applied to a project layout like:

pom.xml
resource2/external-resource.jpg
resource2/image2/external-resource2.jpg
src/main/webapp/WEB-INF/web.xml
...

Would produce a war layout like:

myTarget/external-resource.jpg
myTarget/image2/external-resource2.jpg
WEB-INF/web.xml

Hopefully this is the answer you're looking for.

Joe Hindsley

Ludwig Magnusson wrote:

> But the problem is that I configure my webapp with property files. Some
> properties point to other files. Won't those links be wrong in any case
> since the files will be in a new directory?
> I suppose I could use separate configurations for development and live but
> it seems like a lot of work.
> I don't really understand why the structure needs to be different.
> /Ludwig
>
> -----Original Message-----
> From: Joe Hindsley [mailto:jhindsley@...]
> Sent: den 20 november 2009 17:02
> To: Maven Users List
> Subject: Re: [WAR-plugin] Can I put my resources in their original folder?
>
> Hi Ludwig,
>
> I would recommend putting those directories and files in the
> src/main/webapp directory. The maven war plugin puts everything under
> src/main/webapp into the base of the war.
>
> In your case:
>
> src/main/webapp/external-resource.jpg
> src/main/webapp/image2/external-resource2.jpg
>
> would give you the war layout:
>
> ./external-resource.jpg
> ./image2/external-resource2.jpg
>
> Hope this helps,
>
> Joe Hindsley
>
>
> Ludwig Magnusson wrote:
>> The first example on this page
>>
> <http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering-
>> webresources.html>
>>
> http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering-w
>> ebresources.html says that resources outside the src folder will be placed
>> in the root of the war
>>
>>
>>
>> Ex, with this filestructure:
>>
>> |-- pom.xml
>>
>> |-- resource2
>>
>> | |-- external-resource.jpg
>>
>> | `-- image2
>>
>> | `-- external-resource2.jpg
>>
>> //more structure
>>
>>
>>
>> And this configuration of the war-plugin
>>
>> <configuration>
>> <webResources>
>> <resource>
>> 
>> <directory>resource2</directory>
>> </resource>
>> </webResources>
>> </configuration>
>>
>>
>>
>> The war file will be structured like this:
>>
>>
>>
>> //more structure
>>
>> |-- external-resource.jpg
>> |-- image2
>> | `-- external-resource2.jpg
>>
>>
>>
>> Is it possible to structure the war-file like the original filestructure?
>>
>> I.e having all the extra resources in the resource2-folder, and that
> folder
>> in the root of the war-file?
>>
>> /Ludwig
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

RE: [WAR-plugin] Can I put my resources in their original folder?

2009-11-20T10:37:46Z

But the problem is that I configure my webapp with property files. Some
properties point to other files. Won't those links be wrong in any case
since the files will be in a new directory?
I suppose I could use separate configurations for development and live but
it seems like a lot of work.
I don't really understand why the structure needs to be different.
/Ludwig

-----Original Message-----
From: Joe Hindsley [mailto:jhindsley@...]
Sent: den 20 november 2009 17:02
To: Maven Users List
Subject: Re: [WAR-plugin] Can I put my resources in their original folder?

Hi Ludwig,

I would recommend putting those directories and files in the
src/main/webapp directory. The maven war plugin puts everything under
src/main/webapp into the base of the war.

In your case:

src/main/webapp/external-resource.jpg
src/main/webapp/image2/external-resource2.jpg

would give you the war layout:

./external-resource.jpg
./image2/external-resource2.jpg

Hope this helps,

Joe Hindsley

Ludwig Magnusson wrote:
> The first example on this page
>
<http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering-
> webresources.html>
>
http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering-w

> ebresources.html says that resources outside the src folder will be placed
> in the root of the war
>
>
>
> Ex, with this filestructure:
>
> |-- pom.xml
>
> |-- resource2
>
> | |-- external-resource.jpg
>
> | `-- image2
>
> | `-- external-resource2.jpg
>
> //more structure
>
>
>
> And this configuration of the war-plugin
>
> <configuration>
> <webResources>
> <resource>
> 
> <directory>resource2</directory>
> </resource>
> </webResources>
> </configuration>
>
>
>
> The war file will be structured like this:
>
>
>
> //more structure
>
> |-- external-resource.jpg
> |-- image2
> | `-- external-resource2.jpg
>
>
>
> Is it possible to structure the war-file like the original filestructure?
>
> I.e having all the extra resources in the resource2-folder, and that

folder
> in the root of the war-file?
>
> /Ludwig
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: "[WARNING] POM is invalid." error messages in Maven 2.2.1 but not in 2.0.10

2009-11-20T09:33:20Z

>
>
> Maybe 2.2.2 will fix it. =)

Not likely. The pom is plain wrong an it was a bug in 2.x which
allowed it to go unnoticed.

> On Fri, Nov 20, 2009 at 3:42 PM, Brett Randall <javabrett@...>
> wrote:
>> http://jira.codehaus.org/browse/MNG-4379 ... or did your team log
>> that :).
>>
>> On Fri, Nov 20, 2009 at 2:59 PM, Ellecer Valencia
>> <ellecer@...> wrote:
>>
>>> Hi Brett,
>>>
>>> Thanks for the suggestion. I may have found the issue. Would it be
>>> this:
>>>
>>>
>>> Validation Errors:
>>> [DEBUG] For dependency Dependency {groupId=weblogic,
>>> artifactId=weblogic, version=10.0, type=jar}: system-scoped
>>> dependency
>>> must specify an absolute path systemPath.
>>> [DEBUG] For managed dependency Dependency {groupId=weblogic,
>>> artifactId=weblogic, version=10.0, type=jar}: system-scoped
>>> dependency
>>> must specify an absolute path systemPath.
>>> [DEBUG]
>>>
>>> [DEBUG] mypackage:myartifact:jar:1.0.2:compile (selected for
>>> compile)
>>> [DEBUG] Skipping disabled repository central
>>> [DEBUG] myartifact: using locally installed snapshot
>>> [WARNING] POM for 'mypackage:myartifact:pom:1.0.2-SNAPSHOT:test' is
>>> invalid.
>>>
>>> Its dependencies (if any) will NOT be available to the current
>>> build.
>>> [DEBUG] Reason: Failed to validate POM for project
>>> mypackage:myartifact at Artifact
>>> [mypackage:myartifact:pom:1.0.2-SNAPSHOT:test]
>>> [DEBUG]
>>> Validation Errors:
>>> [DEBUG] For dependency Dependency {groupId=weblogic,
>>> artifactId=weblogic, version=10.0, type=jar}: system-scoped
>>> dependency
>>> must specify an absolute path systemPath.
>>> [DEBUG] For dependency Dependency {groupId=weblogic,
>>> artifactId=webservices, version=10.0, type=jar}: system-scoped
>>> dependency must specify an absolute path systemPath.
>>> [DEBUG] For managed dependency Dependency {groupId=weblogic,
>>> artifactId=weblogic, version=10.0, type=jar}: system-scoped
>>> dependency
>>> must specify an absolute path systemPath.
>>> [DEBUG] For managed dependency Dependency {groupId=weblogic,
>>> artifactId=webservices, version=10.0, type=jar}: system-scoped
>>> dependency must specify an absolute path systemPath.
>>> [DEBUG]
>>>
>>>
>>> Now in this project, we are inheriting from a parent POM
>>> (standardised
>>> for our department) with entries like this:
>>> (WL_HOME is Weblogic install directory)
>>>
>>>
>>> <dependency>
>>> <groupId>com.sun</groupId>
>>> <artifactId>tools</artifactId>
>>> <version>1.5.0.11</version>
>>> <scope>system</scope>
>>> <systemPath>${java.home}/../lib/tools.jar</systemPath>
>>> </dependency>
>>> <dependency>
>>> <groupId>com.sun</groupId>
>>> <artifactId>rt</artifactId>
>>> <version>1.5.0.11</version>
>>> <scope>system</scope>
>>> <systemPath>${java.home}/lib/rt.jar</systemPath>
>>> </dependency>
>>> <dependency>
>>> <groupId>weblogic</groupId>
>>> <artifactId>weblogic</artifactId>
>>> <version>10.0</version>
>>> <scope>system</scope>
>>> <systemPath>${env.WL_HOME}/server/lib/weblogic.jar</
>>> systemPath>
>>> </dependency>
>>> <dependency>
>>> <groupId>weblogic</groupId>
>>> <artifactId>webservices</artifactId>
>>> <version>10.0</version>
>>> <scope>system</scope>
>>> <systemPath>${env.WL_HOME}/server/lib/webservices.jar</
>>> systemPath>
>>> </dependency>
>>>
>>>
>>> Now it only fails on the Weblogic related entries. With the Java
>>> system dependencies it seems to do fine.
>>>
>>> Has the handling of this changed from 2.0.* to 2.2.*?
>>>
>>> If so, what should we replace it with?
>>>
>>> And will these settings also work for people still using maven
>>> 2.0.10?
>>>
>>>
>>> Ellecer
>>>
>>>
>>>
>>> On Fri, Nov 20, 2009 at 1:01 PM, Brett Randall <javabrett@...>
>>> wrote:
>>>> Hi Ellecer
>>>>
>>>> What is the output of mvn -e -X ...
>>>>
>>>> Brett
>>>>
>>>> On Fri, Nov 20, 2009 at 11:41 AM, Ellecer Valencia <ellecer@...
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> How come when I try a build using Maven 2.2.1 I get multiple
>>>>> messages
>>> like
>>>>> this:
>>>>>
>>>>> "[WARNING] POM for 'mypackage.artifact:pom:1.0.2-
>>>>> SNAPSHOT:compile' is
>>>>> invalid.
>>>>>
>>>>> Its dependencies (if any) will NOT be available to the current
>>>>> build."
>>>>>
>>>>> These errors weren't displaying when I was using Maven 2.0.10
>>>>>
>>>>> I'm trying to use the newer version of Maven but I can't proceed
>>>>> with
>>>>> these error messages.
>>>>>
>>>>> How can I find out what are the actual errors it's referring to? I
>>>>> didn't come across any mention of relevant POM format changes
>>>>> going
>>>>> from Maven 2.0.* to 2.1.* or 2.2.* - if anyone has any info on
>>>>> this it
>>>>> would be a great help! Is there a way to validate the pom and get
>>>>> format error details from Maven?
>>>>>
>>>>>
>>>>> thanks,
>>>>>
>>>>> Ellecer
>>>>>
>>>>> ---
>>>>> ------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>> For additional commands, e-mail: users-help@...
>>>>>
>>>>>
>>>>
>>>
>>> ---
>>> ------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

Re: Custom Archetypes: Creating empty directories

2009-11-20T09:05:16Z

http://jira.codehaus.org/browse/ARCHETYPE-57 gives an example of how to do this.

Thanks for your time!

Matthew Runo
Software Engineer, Zappos.com
mruno@... - 702-943-7833

On Nov 19, 2009, at 11:37 PM, Richard Hauswald wrote:

> Hello list,
> I'm trying to create a custom archetype. All is working fine except
> that I can't create empty directories. Is this impossible or do miss
> something?
> Thanks,
> Richard
> --
> Richard Hauswald
> Blog: http://tnfstacc.blogspot.com/
> LinkedIn: http://www.linkedin.com/in/richardhauswald
> Xing: http://www.xing.com/profile/Richard_Hauswald
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...