Re: Seeking Maven Way advice: repos in project profile?

[Brian Topping]

Laird, any environment with multiple developers and multiple repositories is 
Exhibit 1 for using a repository manager like Nexus.  

Once you have that running, one proxies remote repositories from central 
administration, not rely on users having the latest information or some 
combination of the latest information.

Developers do need to have a reference to the repository you set up, how that's 
configured (either as a replacement for central or as an additional repository) 
IMHO depends a lot on who you have working on the project.  If everyone is 
using machines that are owned by the company (meaning they are not a bunch of 
contractors that may have other projects going on), setting up their machines 
to treat your repository as central makes a lot the most sense.  

If you do have such contractors, it's presumed you only have them because they 
are A-team players that can manage their own settings.xml with aplomb.

Brian

On Oct 22, 2012, at 5:37 PM, Laird Nelson  wrote:

> I know that it is a Bad Thing to add a repository to your pom.xml.
> 
> Is it regarded by the Great Maven Hivemind :-) to be a Bad Thing if you put
> a repository in your pom.xml as an (unactivated by default) profile?
> 
> I'm sick and tired of having to tell users to put repository X or
> repository Y in their .m2/settings.xml file; the whole point of the pom.xml
> is: download the stuff, tell Maven to build it.  :-)
> 
> Best,
> Laird
> 
> -- 
> http://about.me/lairdnelson


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

Re: Problem with release:perform step: target/check/pom.xml not found?

[Brian Topping]

Oh, and to be sure, once you edit those entries, you either need to also edit 
them in the pom.xml of the tag and run perform *or* delete the tag and and 
re-run both prepare and preform.  

On Oct 21, 2012, at 9:49 PM, Brian Topping  wrote:

> Try adding "/trunk" after the  and  entries. 
>  
> 
> On Oct 21, 2012, at 9:36 PM, Russell Gold  wrote:
> 
>> This is my first time releasing this project via maven, and I am presumably 
>> doing something wrong.
>> 
>> The release:prepare step seems to work just fine, ending with:
>> 
>>[INFO] Building jar: 
>> /Users/rgold/projects/httpunit/httpunit/target/httpunit-1.7.2-javadoc.jar
>>[INFO] 
>>[INFO] --- maven-gpg-plugin:1.1:sign (sign-artifacts) @ httpunit ---
>>GPG Passphrase: ***
>> *[INFO] 
>> 
>>[INFO] BUILD SUCCESS
>>[INFO] 
>> 
>>[INFO] Total time: 56.441s
>>[INFO] Finished at: Sun Oct 21 21:23:40 EDT 2012
>>[INFO] Final Memory: 15M/81M
>>[INFO] 
>> 
>> [INFO] Checking in modified POMs...
>> [INFO] Executing: /bin/sh -c cd /Users/rgold/projects/httpunit/httpunit && 
>> svn --non-interactive commit --file 
>> /var/folders/t5/whm3w7t93l521hxh3cn_v2rwgn/T/maven-scm-1558011316.commit 
>> --targets 
>> /var/folders/t5/whm3w7t93l521hxh3cn_v2rwgn/T/maven-scm-6609960458242262828-targets
>> [INFO] Working directory: /Users/rgold/projects/httpunit/httpunit
>> [INFO] Tagging release with the label httpunit-1.7.2...
>> [INFO] Executing: /bin/sh -c cd /Users/rgold/projects/httpunit/httpunit && 
>> svn --non-interactive copy --file 
>> /var/folders/t5/whm3w7t93l521hxh3cn_v2rwgn/T/maven-scm-1454972466.commit 
>> --revision  
>> https://httpunit.svn.sourceforge.net/svnroot/httpunit/trunk/httpunit 
>> https://httpunit.svn.sourceforge.net/svnroot/httpunit/tags/httpunit-1.7.2
>> [INFO] Working directory: /Users/rgold/projects/httpunit/httpunit
>> [INFO] Transforming 'HttpUnit'...
>> [INFO] Not removing release POMs
>> [INFO] Checking in modified POMs...
>> [INFO] Executing: /bin/sh -c cd /Users/rgold/projects/httpunit/httpunit && 
>> svn --non-interactive commit --file 
>> /var/folders/t5/whm3w7t93l521hxh3cn_v2rwgn/T/maven-scm-946716656.commit 
>> --targets 
>> /var/folders/t5/whm3w7t93l521hxh3cn_v2rwgn/T/maven-scm-2228214041112649129-targets
>> [INFO] Working directory: /Users/rgold/projects/httpunit/httpunit
>> [INFO] Release preparation complete.
>> [INFO] 
>> 
>> [INFO] BUILD SUCCESS
>> [INFO] 
>> 
>> [INFO] Total time: 1:21.002s
>> [INFO] Finished at: Sun Oct 21 21:23:57 EDT 2012
>> [INFO] Final Memory: 6M/81M
>> [INFO] 
>> 
>> 
>> but when I try release:perform, I get
>> 
>> /Users/rgold/projects/httpunit/httpunit> mvn release:perform
>> [INFO] Scanning for projects...
>> [INFO]   
>>   
>> [INFO] 
>> 
>> [INFO] Building HttpUnit 1.7.3-SNAPSHOT
>> [INFO] 
>> 
>> [INFO] 
>> [INFO] --- maven-release-plugin:2.1:perform (default-cli) @ httpunit ---
>> [INFO] Checking out the project to perform the release ...
>> [INFO] Executing: /bin/sh -c cd 
>> /Users/rgold/projects/httpunit/httpunit/target && svn --non-interactive 
>> checkout 
>> https://httpunit.svn.sourceforge.net/svnroot/httpunit/tags/httpunit-1.7.2 
>> /Users/rgold/projects/httpunit/httpunit/target/checkout
>> [INFO] Working directory: /Users/rgold/projects/httpunit/httpunit/target
>> [INFO] Executing goals 'deploy'...
>> [INFO] Executing: /bin/sh -c cd 
>> /Users/rgold/projects/httpunit/httpunit/target/checkout && 
>> /opt/local/share/java/maven3/bin/mvn deploy --no-plugin-updates 
>> -Psonatype-oss-release -f pom.xml
>>[WARNING] Command line option -npu is deprecated and will be removed in 
>> future Maven versions.
>>[INFO] Scanning for projects...
>>[ERROR] The build could not read 1 project -> [Help

Re: Problem with release:perform step: target/check/pom.xml not found?

[Brian Topping]

Try adding "/trunk" after the  and  entries.  

On Oct 21, 2012, at 9:36 PM, Russell Gold  wrote:

> This is my first time releasing this project via maven, and I am presumably 
> doing something wrong.
> 
> The release:prepare step seems to work just fine, ending with:
> 
> [INFO] Building jar: 
> /Users/rgold/projects/httpunit/httpunit/target/httpunit-1.7.2-javadoc.jar
> [INFO] 
> [INFO] --- maven-gpg-plugin:1.1:sign (sign-artifacts) @ httpunit ---
> GPG Passphrase: ***
> *[INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 56.441s
> [INFO] Finished at: Sun Oct 21 21:23:40 EDT 2012
> [INFO] Final Memory: 15M/81M
> [INFO] 
> 
> [INFO] Checking in modified POMs...
> [INFO] Executing: /bin/sh -c cd /Users/rgold/projects/httpunit/httpunit && 
> svn --non-interactive commit --file 
> /var/folders/t5/whm3w7t93l521hxh3cn_v2rwgn/T/maven-scm-1558011316.commit 
> --targets 
> /var/folders/t5/whm3w7t93l521hxh3cn_v2rwgn/T/maven-scm-6609960458242262828-targets
> [INFO] Working directory: /Users/rgold/projects/httpunit/httpunit
> [INFO] Tagging release with the label httpunit-1.7.2...
> [INFO] Executing: /bin/sh -c cd /Users/rgold/projects/httpunit/httpunit && 
> svn --non-interactive copy --file 
> /var/folders/t5/whm3w7t93l521hxh3cn_v2rwgn/T/maven-scm-1454972466.commit 
> --revision  
> https://httpunit.svn.sourceforge.net/svnroot/httpunit/trunk/httpunit 
> https://httpunit.svn.sourceforge.net/svnroot/httpunit/tags/httpunit-1.7.2
> [INFO] Working directory: /Users/rgold/projects/httpunit/httpunit
> [INFO] Transforming 'HttpUnit'...
> [INFO] Not removing release POMs
> [INFO] Checking in modified POMs...
> [INFO] Executing: /bin/sh -c cd /Users/rgold/projects/httpunit/httpunit && 
> svn --non-interactive commit --file 
> /var/folders/t5/whm3w7t93l521hxh3cn_v2rwgn/T/maven-scm-946716656.commit 
> --targets 
> /var/folders/t5/whm3w7t93l521hxh3cn_v2rwgn/T/maven-scm-2228214041112649129-targets
> [INFO] Working directory: /Users/rgold/projects/httpunit/httpunit
> [INFO] Release preparation complete.
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 1:21.002s
> [INFO] Finished at: Sun Oct 21 21:23:57 EDT 2012
> [INFO] Final Memory: 6M/81M
> [INFO] 
> 
> 
> but when I try release:perform, I get
> 
> /Users/rgold/projects/httpunit/httpunit> mvn release:perform
> [INFO] Scanning for projects...
> [INFO]
>  
> [INFO] 
> 
> [INFO] Building HttpUnit 1.7.3-SNAPSHOT
> [INFO] 
> 
> [INFO] 
> [INFO] --- maven-release-plugin:2.1:perform (default-cli) @ httpunit ---
> [INFO] Checking out the project to perform the release ...
> [INFO] Executing: /bin/sh -c cd 
> /Users/rgold/projects/httpunit/httpunit/target && svn --non-interactive 
> checkout 
> https://httpunit.svn.sourceforge.net/svnroot/httpunit/tags/httpunit-1.7.2 
> /Users/rgold/projects/httpunit/httpunit/target/checkout
> [INFO] Working directory: /Users/rgold/projects/httpunit/httpunit/target
> [INFO] Executing goals 'deploy'...
> [INFO] Executing: /bin/sh -c cd 
> /Users/rgold/projects/httpunit/httpunit/target/checkout && 
> /opt/local/share/java/maven3/bin/mvn deploy --no-plugin-updates 
> -Psonatype-oss-release -f pom.xml
> [WARNING] Command line option -npu is deprecated and will be removed in 
> future Maven versions.
> [INFO] Scanning for projects...
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]   
> [ERROR]   The project  
> (/Users/rgold/projects/httpunit/httpunit/target/checkout/pom.xml) has 1 error
> [ERROR] Non-readable POM 
> /Users/rgold/projects/httpunit/httpunit/target/checkout/pom.xml: 
> /Users/rgold/projects/httpunit/httpunit/target/checkout/pom.xml (No such file 
> or directory)
> [ERROR] 
> [ERROR] To see the full stack trace of the errors, re-run Maven with the 
> -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] 
> [ERROR] For more information about the errors and possible solutions, 
> please read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> --

Re: xdoclet plugin for maven - custom tag handlers

[Brian Topping]

If you aren't getting a stack trace with the error, run 'mvn -X install' to get 
one.  There will be a lot more information to wade through, but it will be in 
there.

Once you find it, download the sources for the version of XDoclet you are using 
and take a look at where it's getting caught up.  If you want to debug into 
XDoclet, there is a version of Maven that is installed called "mvndebug" (i.e. 
"mvndebug install" which will allow you to set breakpoints in XDoclet and debug 
it.

I'm sure you know this already, but it's been several years since XDoclet has 
been actively developed or supported, and you'd really be better off moving to 
JSR-175 annotations. 

Brian


On Oct 11, 2012, at 11:52 AM, Abitfarago Cini  wrote:

> Hi,
> 
> I try to port an old Ant based build to Maven. It contains multiple xdoclet
> generations, of them (for XML files) uses home brewed tag handlers. These
> handlers are built separately and the artifact is installed in my local
> repository.
> 
> When I run the *mvn install* it complains saying:
> 
> [ERROR] Failed to execute goal
> org.codehaus.mojo:xdoclet-maven-plugin:1.0:xdoclet (default) on project
> pcm-services-model: Error executing ant tasks: Unexpected error: XDoclet
> failed. xdoclet.template.TemplateException: Could not find tag handler for
> prefix: 'xdclDum' -> [Help 1]
> 
> What I am missing?
> 
> Abitfarago


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

Re: Maven release plugin failure

[Brian Topping]

This is more of a Java question than a Maven question at this point.  Maven 
uses Java to validate certificates as a part of channel security.  If you don't 
want channel security, don't use SSL ;)

I don't have enough Windoze foo to help you past this point, maybe someone else 
on the list does.  But you shouldn't have had these problems if you read those 
google results closely enough and I bet you can solve it yourself before 
someone else were to respond...

Good luck!

On Sep 22, 2012, at 9:12 PM, David Hoffer  wrote:

> Thanks, I thought sure that was going to fix it...but after that change I
> still get this:
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare (default-cli)
> on project dhs-commons: Unable to tag SCM
> [ERROR] Provider message:
> [ERROR] The svn tag command failed.
> [ERROR] Command output:
> [ERROR] svn: E175002: Unable to connect to a repository at URL '
> https://server1/svn/app-commons/trunk'
> [ERROR] svn: E175002: OPTIONS of 'https://server1/svn/app-commons/trunk':
> Server certificate verification failed: issuer is not trusted (
> https://server1)
> [ERROR] -> [Help 1]
> 
> Where I have put server1 in my hosts file to point to the actual IP on the
> LAN, e.g 192.168.0.xxx.  Now the error message seems to indicate it found
> the cert...but it's not considered valid??
> 
> I use TortiseSVN to connect to this same SVN all day long...why can't maven?
> 
> -Dave
> 
> 
> 
> 
> 
> On Sat, Sep 22, 2012 at 6:50 PM, Brian Topping  wrote:
> 
>> Ah.  The -keystore parameter should point to your cacerts file that is
>> buried somewhere in C:\Program Files\Java\jdk1.7.0_06\jre.
>> 
>> On Sep 22, 2012, at 8:34 PM, David Hoffer  wrote:
>> 
>>> Yeah, I had done the mvn -version to find what Java to add it to but that
>>> didn't work so I added it to others too.  Here is the results of that:
>>> 
>>> Apache Maven 3.0.4 (r1232337; 2012-01-17 01:44:56-0700)
>>> Maven home: C:\Program Files (x86)\Maven\apache-maven-3.0.4
>>> Java version: 1.7.0_06, vendor: Oracle Corporation
>>> Java home: C:\Program Files\Java\jdk1.7.0_06\jre
>>> Default locale: en_US, platform encoding: Cp1252
>>> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>>> 
>>> And here is my command line to add the cert:
>>> C:\Program Files\Java\jdk1.7.0_06\jre\bin>keytool -import -keystore
>>> server1cert -file c:/server1cert.cer
>>> 
>>> What I'm I missing here?
>>> 
>>> -Dave
>>> 
>>> 
>>> On Sat, Sep 22, 2012 at 6:15 PM, Brian Topping 
>> wrote:
>>> 
>>>> Dave, I think I'd attack the latter issue first.  You have to know which
>>>> cacerts file is getting hit, otherwise it's no different than not
>> adding it
>>>> at all.  "mvn -version" will tell you what Java home it's using, that
>>>> should help you find the proper cacerts file.  Be careful to add it to
>> the
>>>> JRE and not the JDK version of cacerts.
>>>> 
>>>> I have no ideas about anything from Redmond, but if it's PEM-encoded, it
>>>> should slurp right in.  IIRC, naming the alias of the cert to your FQDN
>>>> really only helps with wetware management.
>>>> 
>>>> On Sep 22, 2012, at 7:53 PM, David Hoffer  wrote:
>>>> 
>>>>> Hum, I'm having trouble getting this to work.  I generated the self
>>>> signed
>>>>> cert on the server using IIS and then on the client ran this command:
>>>>> 
>>>>> keytool -import -keystore server1cert -file c:/server1cert.cer
>>>>> 
>>>>> It says it imported it fine but I still get the same error using the
>>>> maven
>>>>> release plugin.  I thought it might be because the cert has the server
>>>> name
>>>>> not the IP as the CN entry so I changed the maven pom to use the server
>>>>> name (in the SCM URL) instead but that didn't fix the problem not just
>>>>> complains using the server name instead of the IP in the connection
>> URL.
>>>>> 
>>>>> Also I do have lots of Java versions (jre & jdk) and wasn't positive
>>>> which
>>>>> was used by maven so I added it to several...didn't help.
>>>>> 
>>>>> What am I missing?
>>>>> 
>>>>> -Dave
>>&

Re: Maven release plugin failure

[Brian Topping]

Ah.  The -keystore parameter should point to your cacerts file that is buried 
somewhere in C:\Program Files\Java\jdk1.7.0_06\jre.

On Sep 22, 2012, at 8:34 PM, David Hoffer  wrote:

> Yeah, I had done the mvn -version to find what Java to add it to but that
> didn't work so I added it to others too.  Here is the results of that:
> 
> Apache Maven 3.0.4 (r1232337; 2012-01-17 01:44:56-0700)
> Maven home: C:\Program Files (x86)\Maven\apache-maven-3.0.4
> Java version: 1.7.0_06, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_06\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
> 
> And here is my command line to add the cert:
> C:\Program Files\Java\jdk1.7.0_06\jre\bin>keytool -import -keystore
> server1cert -file c:/server1cert.cer
> 
> What I'm I missing here?
> 
> -Dave
> 
> 
> On Sat, Sep 22, 2012 at 6:15 PM, Brian Topping  wrote:
> 
>> Dave, I think I'd attack the latter issue first.  You have to know which
>> cacerts file is getting hit, otherwise it's no different than not adding it
>> at all.  "mvn -version" will tell you what Java home it's using, that
>> should help you find the proper cacerts file.  Be careful to add it to the
>> JRE and not the JDK version of cacerts.
>> 
>> I have no ideas about anything from Redmond, but if it's PEM-encoded, it
>> should slurp right in.  IIRC, naming the alias of the cert to your FQDN
>> really only helps with wetware management.
>> 
>> On Sep 22, 2012, at 7:53 PM, David Hoffer  wrote:
>> 
>>> Hum, I'm having trouble getting this to work.  I generated the self
>> signed
>>> cert on the server using IIS and then on the client ran this command:
>>> 
>>> keytool -import -keystore server1cert -file c:/server1cert.cer
>>> 
>>> It says it imported it fine but I still get the same error using the
>> maven
>>> release plugin.  I thought it might be because the cert has the server
>> name
>>> not the IP as the CN entry so I changed the maven pom to use the server
>>> name (in the SCM URL) instead but that didn't fix the problem not just
>>> complains using the server name instead of the IP in the connection URL.
>>> 
>>> Also I do have lots of Java versions (jre & jdk) and wasn't positive
>> which
>>> was used by maven so I added it to several...didn't help.
>>> 
>>> What am I missing?
>>> 
>>> -Dave
>>> 
>>> On Sat, Sep 22, 2012 at 3:53 PM, Brian Topping 
>> wrote:
>>> 
>>>> Hi David,
>>>> 
>>>> It looks like you have an unsigned SSL certificate on your SVN server.
>> So
>>>> you need to install the certificate in the Java keystore of hosts that
>> need
>>>> to run the release plugin.  There are a lot of examples of this on the
>> net
>>>> already, just google for "install unsigned cert java" or whatnot.
>>>> 
>>>> Cheers, Brian
>>>> 
>>>> On Sep 22, 2012, at 5:19 PM, David Hoffer  wrote:
>>>> 
>>>>> I'm getting the following error while performing the release:prepare
>>>> goal.
>>>>> 
>>>>> [ERROR] Failed to execute goal
>>>>> org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare
>>>>> (default-cli) on project app-commons: Unable to tag SCM
>>>>> [ERROR] Provider message:
>>>>> [ERROR] The svn tag command failed.
>>>>> [ERROR] Command output:
>>>>> [ERROR] svn: E175002: Unable to connect to a repository at URL
>>>>> 'https://hostname/svn/app-commons/trunk'
>>>>> [ERROR] svn: E175002: OPTIONS of
>>>>> 'https://hostname/svn/app-commons/trunk': Server certificate
>>>>> verification failed: certificate issued for a different hostname,
>>>>> issuer is not trusted (https://hostname)
>>>>> [ERROR] -> [Help 1]
>>>>> 
>>>>> I'm on Windows, local network, Maven 3.0.4.  How can I resolve this?
>>>>> 
>>>>> Thanks,
>>>>> -Dave
>>>>> 
>>>>> -
>>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>>> 
>>>> 
>>>> 
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>> 
>>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 
>> 


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

Re: Maven release plugin failure

[Brian Topping]

Dave, I think I'd attack the latter issue first.  You have to know which 
cacerts file is getting hit, otherwise it's no different than not adding it at 
all.  "mvn -version" will tell you what Java home it's using, that should help 
you find the proper cacerts file.  Be careful to add it to the JRE and not the 
JDK version of cacerts.

I have no ideas about anything from Redmond, but if it's PEM-encoded, it should 
slurp right in.  IIRC, naming the alias of the cert to your FQDN really only 
helps with wetware management.  

On Sep 22, 2012, at 7:53 PM, David Hoffer  wrote:

> Hum, I'm having trouble getting this to work.  I generated the self signed
> cert on the server using IIS and then on the client ran this command:
> 
> keytool -import -keystore server1cert -file c:/server1cert.cer
> 
> It says it imported it fine but I still get the same error using the maven
> release plugin.  I thought it might be because the cert has the server name
> not the IP as the CN entry so I changed the maven pom to use the server
> name (in the SCM URL) instead but that didn't fix the problem not just
> complains using the server name instead of the IP in the connection URL.
> 
> Also I do have lots of Java versions (jre & jdk) and wasn't positive which
> was used by maven so I added it to several...didn't help.
> 
> What am I missing?
> 
> -Dave
> 
> On Sat, Sep 22, 2012 at 3:53 PM, Brian Topping  wrote:
> 
>> Hi David,
>> 
>> It looks like you have an unsigned SSL certificate on your SVN server.  So
>> you need to install the certificate in the Java keystore of hosts that need
>> to run the release plugin.  There are a lot of examples of this on the net
>> already, just google for "install unsigned cert java" or whatnot.
>> 
>> Cheers, Brian
>> 
>> On Sep 22, 2012, at 5:19 PM, David Hoffer  wrote:
>> 
>>> I'm getting the following error while performing the release:prepare
>> goal.
>>> 
>>> [ERROR] Failed to execute goal
>>> org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare
>>> (default-cli) on project app-commons: Unable to tag SCM
>>> [ERROR] Provider message:
>>> [ERROR] The svn tag command failed.
>>> [ERROR] Command output:
>>> [ERROR] svn: E175002: Unable to connect to a repository at URL
>>> 'https://hostname/svn/app-commons/trunk'
>>> [ERROR] svn: E175002: OPTIONS of
>>> 'https://hostname/svn/app-commons/trunk': Server certificate
>>> verification failed: certificate issued for a different hostname,
>>> issuer is not trusted (https://hostname)
>>> [ERROR] -> [Help 1]
>>> 
>>> I'm on Windows, local network, Maven 3.0.4.  How can I resolve this?
>>> 
>>> Thanks,
>>> -Dave
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 
>> 


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

Re: Maven release plugin failure

[Brian Topping]

Hi David, 

It looks like you have an unsigned SSL certificate on your SVN server.  So you 
need to install the certificate in the Java keystore of hosts that need to run 
the release plugin.  There are a lot of examples of this on the net already, 
just google for "install unsigned cert java" or whatnot.

Cheers, Brian

On Sep 22, 2012, at 5:19 PM, David Hoffer  wrote:

> I'm getting the following error while performing the release:prepare goal.
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare
> (default-cli) on project app-commons: Unable to tag SCM
> [ERROR] Provider message:
> [ERROR] The svn tag command failed.
> [ERROR] Command output:
> [ERROR] svn: E175002: Unable to connect to a repository at URL
> 'https://hostname/svn/app-commons/trunk'
> [ERROR] svn: E175002: OPTIONS of
> 'https://hostname/svn/app-commons/trunk': Server certificate
> verification failed: certificate issued for a different hostname,
> issuer is not trusted (https://hostname)
> [ERROR] -> [Help 1]
> 
> I'm on Windows, local network, Maven 3.0.4.  How can I resolve this?
> 
> Thanks,
> -Dave
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


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

Re: Arguments for Maven vs. Gradle

[Brian Topping]

On Sep 11, 2012, at 8:22 PM, Curtis Rueden  wrote:

> I'm not advocating that junior developers not be allowed to touch the
> build—otherwise how will they learn?—but I strongly recommend code review
> of any changes a junior developer makes to a build system.

Kind of roaming away from Maven v. Gradle, but a process that I've grown 
comfortable with in large groups is a) locking all the POMs for anyone who's 
not a "POM mentor", b) buddying everyone else with a mentor to submit their 
changes, and c) anyone starting a new subproject project gets full access to 
their own POM for the life of their project.

This tends to lessen POM damage as mentors take responsibility for their 
mentees, causes mentees to think harder about whether they really need a POM 
change to move forward (they learn it's certainly more expedient if they 
don't!), but still allows folks entrusted to create new modules the freedom to 
roam, make mistakes with projects that are not part of the mainline build yet, 
and generally get experience with POMs that they wouldn't get with patches 
alone.  

Other tweaks are possible, such as having mentors being required to talk to 
architects for certain classes of changes (such as dependency changes).  Note 
that dependency changes can also be managed by locking down a repository 
manager and disabling auto downloading.

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

Re: Is the release plugin intended to be run manually?

[Brian Topping]

On Sep 11, 2012, at 7:02 PM, "KARR, DAVID"  wrote:

> I noticed a comment in 
> http://www.dzone.com/links/r/continuous_delivery_using_maven_3.html about not 
> using the release plugin because it checks in POMs after updating versions, 
> which isn't suited to a continuous delivery pipeline.  Is the release plugin 
> intended to be run manually, and not part of an automated build?
> 

> The documentation for the plugin doesn't really address this question.

The deploy phase is typically used for CI.  See 
http://www.sonatype.com/books/mvnref-book/reference/lifecycle-sect-common-goals.html#lifecycle-sect-deploy-phase.
  

Release is different, it's what you do when you want to update the version 
numbers and have a concrete reproducible point in the source tree.  Most orgs 
do this manually because of the care that is required, but I've set it up as a 
pushbutton on CI servers for folks that don't have a lot at stake.

They are both supported by plugins with those names, but they are very distinct 
in the project lifecycle.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: configuring jars dependencies in pom

[Brian Topping]

On Sep 11, 2012, at 2:54 PM, Ron Wheeler  wrote:

> Using Maven without your own Repo is a horrible waste of time.
> Get one of the repos (We use Nexus) installed and configured and you life 
> will get a lot simpler.

Really?  It's that bad?  Why doesn't it say this in the Maven documentation 
then?

A lack of understanding of repositories will just kick the can upstream to 
where repositories and groups now need to be configured.  If the OP still 
doesn't the nuances of repositories, now he has to learn them in the context of 
how to configure Nexus.  Knowledge that might help him solve this problem 
without a repository in the first place.

I'm not advocating that one runs a build for a team without a copy of Nexus, I 
agree it is worth the investment to learn, but Maven is not a "waste of time" 
without it.  

Please don't take this the wrong way, Ron, but these kinds of statements are 
sensationalistic and false.  We all got by for years without repositories and 
Maven hasn't substantially changed anything such that they are a requirement 
now.

To the original poster:

You need to study more about repositories and understand which artifacts need 
to come from where.  If a repository has the wrong version of an artifact, do 
not include it in your list of repositories or it will be downloaded.  Further, 
there is a difference between  and , and you 
should not need the latter unless there is a Maven plugin that is not being 
found.  

When you have artifact dependencies that are *not* a part of your build *and 
not* a part of any repository, *then* you cannot get by without a repository of 
some sort.  It *is* possible to host a repository on a plain HTTP server and 
"deploy" to file: URLs, but it is a bit masochistic to do so.  In that case, it 
is easiest to bite the bullet and just deploy Nexus to start with.

I hope this helps without being incendiary.  I care about you guys more than 
that. :-)

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

Re: Arguments for Maven vs. Gradle

[Brian Topping]

On Sep 10, 2012, at 4:15 AM, Graham Leggett  wrote:

> On 9 Sep 2012, at 22:20, "KARR, DAVID"  wrote:
> 
>> One of the disadvantages of Gradle is the same as Ant, which is that it's 
>> very easy to have two people do similar things in a completely different way.
> 
> This to me is the fatal flaw in ant and all tools like it. Ant allows the 
> developer to do whatever they like, and so they do, unnecessarily different 
> to everyone else, and this difference must be debugged, documented and 
> learned, over and over again, wasting countless hours and money.
> 
> In contrast, Maven represents discipline.
> 
> To understand maven one first has to understand discipline in software 
> engineering, why there is no value in solving a solved problem in a way that 
> is different but no better than solutions that have gone before. Why the best 
> documentation is simply no documentation at all. Why the gift of a repeatable 
> build is priceless to the person who has to fix a bug under stressful 
> conditions.

Well said by Ron and Graham. 

With the knowledge as the person that wrote the "associated Maven build" 
(shameless plug ;) and without disclosing anything, I think you can see based 
on it's dependencies that it's not going away anytime soon.  There was a lot of 
resistance to it in the first place, to the point that I was seriously asked a 
few times why the build couldn't be ported to Ant.  

What that says to me is there is a lot of organizational inertia around not 
doing the same thing multiple ways.  In interviewing stakeholders, nobody was 
attached to Ant, they just knew it's warts and how to get around.  It was a 
sunk cost.  Totally reasonable.  

Gradle not only allows the same thing to be done multiple ways (like Ant), but 
now you would be introducing all of Gradle's multiple ways in it's own 
different way.  You'll have one paradigm that is "hard" but can't and won't be 
removed, one that is almost universally deprecated (I can't remember the last 
time I've seen a new project using it), and another that is some hybrid of the 
two, but with completely different syntactic sugar.  Given the resistance to 
adding one new build tool, adding a second for a total of three doesn't sound 
likely.

Also do not forget about plugin support necessary for target environments.  I 
did do the thought experiment at the time why the build could (or should) not 
be rewritten in Ant (welcome to the world of being a good contractor!), and the 
final reason Ant couldn't be used was target product plugin support for Ant 
wasn't there.  If you dig into the plugin context that is available when a 
plugin runs, one wouldn't seriously attempt to run Maven plugins in an Ant 
build.  I theoretically could have ported the plugin(s) to Ant task(s), but one 
key vendor plugin was proprietary.  This same problems will haunt you in Gradle 
until all vendors have equal support for Gradle as they do for Maven.  

While I think I only wrote one plugin for that build, such internal plugins can 
be used in builds across the company.  This is another reason to standardize on 
a single build environment.

This isn't to say that you won't need to do some plugin work to get your new 
build in robust working order.  When I did the (now apparently missing) POC of 
it, I remember that there was some issues that were not solvable with five 
minutes of Maven foo (and why I stopped working on it).  But it wasn't weeks of 
work either.  

HTH, Brian



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

Re: How to Sign a .par file through Maven

[Brian Topping]

These things don't happen at the same time.  

Have you looked at 
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html 
yet?  

Plugins are attached to the lifecycle, plugins are the only thing that can do 
work in a maven build.  The jar plugin expects that the folder structure is 
complete by the time it is run.  So you need to add another plugin EARLIER in 
the lifecycle in order to add the XML files you speak of.  Then when the jar 
plugin gets there, everything is ready for it.


On Aug 29, 2012, at 11:36 AM, TarunKhandelwal  
wrote:

> I am having problem with maven plugin.
> How to add external files while creating par file.
> I have read somewhere that with maven you can only add jar files through
> dependencies.
> So how to do that and another question how can i sign that par file through
> Maven.
> 
> Feel free to clear doubts.
> 
> Thanks,
> Tarun Khandelwal
> 
> 
> 
> --
> View this message in context: 
> http://maven.40175.n5.nabble.com/How-to-Sign-a-par-file-through-Maven-tp5718722p5718727.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


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

Re: How to Sign a .par file through Maven

[Brian Topping]

What specific problems did you have?

This is not a tech support line.  If you need paid support, you might want to 
contact Sonatype.  

On Aug 29, 2012, at 11:29 AM, TarunKhandelwal wrote:

> Hello Brian,
> 
> Yes I have tried all of that.
> 
> Here is the sample pom.
> 
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>  http://maven.apache.org/xsd/maven-4.0.0.xsd";>
>   4.0.0
>   com.Testing.maven
>   sampleapp
>   par
>   1.0-SNAPSHOT
>   Embedded Solution
>   http://google.com
>   
>   
>   Test
>   Test
>   0.0.1
>   
>   
>   
>   
>   com.springsource.repository.bundles.milestone
>   SpringSource Enterprise Bundle Repository - 
> SpringSource Bundle
> Milestones
>   
> http://repository.springsource.com/maven/bundles/milestone 
>   
>   
>   
>   
>   
>   .
>   
>   app.xml
>   
>   
>   
>   
>   
>   org.apache.maven.plugins
>   maven-par-plugin
>   1.0.0.M1
>   
>   Testing 
> Sample
>   
>   
>   
>   org.apache.maven.plugins
>   maven-jarsigner-plugin
>   1.2
>   
>   
>   sign
>   
>   sign
>   
>   
>   
>   
>   [path]
>   Alias
>   storepass
>   keypass
>   
>   
>   
>   
> 
> 
> 
> Please let me know if there is any confusion in getting my requirement.
> 
> Thanks,
> Tarun Khandelwal
> 
> 
> 
> --
> View this message in context: 
> http://maven.40175.n5.nabble.com/How-to-Sign-a-par-file-through-Maven-tp5718722p5718725.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: How to Sign a .par file through Maven

[Brian Topping]

Have you tried following the directions for signing a jar?  What problems are 
occurring?

If you want to add XML files, add them to the resources folder or add 
additional resources folders where the XML files are located.

On Aug 29, 2012, at 11:06 AM, TarunKhandelwal  
wrote:

> Hello Everyone,
> 
> I am developing an application through Spring DM.
> So i have to create a package with .par extension. And for build automation
> i am using Maven.
> I am done with creating par file packaged with jar file but now i have to
> sign that .par file.
> I have tried with jarsigner plugin, but nothing is happening.
> Can anyone please suggest how could i accomplish it..
> 
> I am having one more query.
> I want to include some external .xml files also with jar file in .par file.
> Is there any way we can do that or we can create our own file.
> 
> Thanks,
> Tarun Khandelwal
> 
> 
> 
> --
> View this message in context: 
> http://maven.40175.n5.nabble.com/How-to-Sign-a-par-file-through-Maven-tp5718722.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


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

Re: classes developed in a sub-modules does not see packages defined in other ones

[Brian Topping]

Hi Mauro,

You are very close, just need one dependency defined in the POM for module_2 to 
module_1.  So assuming you created everything with the Maven project 
archetypes, you'll have some examples of dependencies in your POMs for jUnit, 
just duplicate one of those in module_2 and change the GAV (group, artifact, 
version) to the GAV of module_1 (defined at the top of that file). 

What you call the main_module is really just a means of project inheritance and 
containment, it has no artifacts other than the POM itself.  POM packaging 
projects such as this are called "aggregator" projects in the documentation.

Hope that helps, welcome to Maven!

Brian

On Aug 20, 2012, at 10:19 PM, Mauro Dragoni  wrote:

> Good morning to everyone.
> I am quite new to Maven and I have a problem that I am not able to solve.
> I have my project structured in this way:
> 
> main_module
> |--- module_1
> |--- module_2
> |--- module_3
> 
> and for each module I have created its pom.xml file.
> I have the following questions:
> 1) I saw that in the main_module there is not any folder for putting
> the source code file, but from the manual I read that it is right
> because it has been created as main project. Is it right?
> 2) I have defined a package in "module_1" that I would like to re-use
> in "module_2", but it does not see it. How can I do this?
> 
> Thanks in advance for any help.
> Have a nice day.
> 
> Mauro.
> 
> -- 
> Dr. Mauro Dragoni
> Ph.D. in Computer Science.
> Post-Doc Researcher at Fondazione Bruno Kessler (FBK-IRST), Trento, Italy.
> 
> My Research Site: https://dkm.fbk.eu/index.php/Mauro_Dragoni
> My Business Site: http://www.dragotechpro.com
> My News-Project Site: http://www.dragotimes.com
> 
> 
> Confidentially Notice. This electronic mail transmission may contain
> legally privileged and/or confidential information. Do not read this,
> if you are not the person named to.
> Any use, distribution, copying or disclosure by any other person is
> strictly prohibited.
> If you received this transmission in error, please notify the sender
> and delete the original transmission and its attachments without
> reading or saving it in any manner.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


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

Re: Executing a goal *after* install

[Brian Topping]

Mirko,

The best way to accomplish this in a plugin you control the source for is to 
create a custom lifecycle.

See 
http://www.sonatype.com/books/mvnref-book/reference/writing-plugins-sect-plugins-lifecycle.html.

Brian

On Jul 25, 2012, at 12:08 AM, Mirko Friedenhagen wrote:

> Hello,
> 
> in a multi-module project, I want to create a sha1 list of all
> artifacts created. For that I created a Mojo which collects all
> artifacts as well as attachedArtifacts from the executionRoot as well
> as the invoking parent. Now I probably need a way to execute a plugin
> *after* install ran in all projects. Is there a way to define that I
> want to run the mojo "post-install"?
> 
> Regards Mirko
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

OT: Re: Issue-wise Crowdfunding platform for Maven

[Brian Topping]

Tony, 

I hate to rain on your parade because it's a very good idea, but isn't this 
something that the Apache Foundation should also be collecting at least as much 
as you are collecting (3%) for the service?  

To keep things honest and since 3% is barely more than Paypal charges to 
intermediate the funds in the first place, I'd alternately suggest a Jira 
plugin project that Apache could use to manage this through Apache Jira itself. 
 Because Apache is a large non-profit, it may be able to negotiate better terms 
with services like Paypal such that more of the money stays "in the family".

While this may not sound as glorious as running this yourself, as eventual 
founder and PMC of the project, you'll still get all the recognition for 
changing the world of OSS for the better and will never have to worry about 
someone else getting a lead on your idea (nobody will be able to give more to 
developers than a non-profit with 0% holdback will).

$0.02...

On Jul 13, 2012, at 11:38 PM, tony Tony wrote:

> Hi all,
> 
> I have set up a website where people can place small money bounties for
> open issues on Maven JIRA  (or
> Jenkins, or Hibernate, or whatever).
> 
> So far it's only got two real offers - and one of them I placed myself
> (JENKINS-9216:
> Make OpenID work with Google Apps
> accounts
> ),
> but I really think that as it gets more popular, such a tool can have a big
> positive impact on a lot of open source projects, especially popular ones
> like Maven.
> If you think so too, I welcome you to use it --> www.freedomsponsors.com :-)
> 
> Cheers
> Tony Lâmpada


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

Re: any public nexus repo manager I can use for my project

[Brian Topping]

On Jun 20, 2012, at 4:30 PM, Laird Nelson wrote:

> No.  This is an undeveloped market with a clear need that has not yet been
> met.  The first company to come out with cheap, hosted Nexus support is
> going to make a fair amount of money.

Therein lies many rubs:

1) Most companies do not want their sekrit sauce floating around someone else's 
servers
2) A major benefit of a repo manager is improving performance for colocated 
teams.  Doesn't happen over a WAN.
3) "Cheap" doesn't leave a lot of incentive to build and staff a highly secure 
and available solution.

I suppose it will happen anyway, the cloud is UNSTOPPABLE (lulz...)
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Can't figure out how to filter resources

[Brian Topping]

On Jun 10, 2012, at 11:57 AM, Patrick wrote:

> Now, how would I go about trying to improve the documentation?  I thought 
> that it should either have a note explicitly mentioning that the resources 
> section does not go in a plugin block, or the first pom.xml should have the 
> ellipses removes, and it should be listed as a complete example.

Good sentiments, but the ellipses convention is used elsewhere around teh 
internets as well.  Further, basic knowledge of XML tree structure precludes 
having both data and other elements as children of an element, something this 
documentation convention clearly violates.  In other words, it should stand out 
as something obviously used for illustration.

As far as complete examples, your contributions might be useful in 
http://maven.apache.org/plugins/maven-resources-plugin/usage.html, but one of 
the benefits of the current documentation format is people can find what they 
need fast, without the clutter of having to wade through complete examples in 
every situation.  It may not suit your taste, but work with it for a while and 
you'll get used to it.

Finally, don't forget how important it is to search projects that successfully 
use Maven for example code.  Even the resources plugin source itself has 
integration tests that demonstrate the different features and how to configure 
for them.

Hope that helps!

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

Re: Can't figure out how to filter resources

[Brian Topping]

On Jun 9, 2012, at 9:53 PM, Jason van Zyl wrote:

> Note that filtering resources is one of the special plugins that is 
> configured in the POM itself. 

As an academic question, what is the reason for the "special plugins" like 
this?  I was teaching a 3-day Maven class a few weeks ago and I couldn't 
explain why it was this way other than some kind of hangover from m1 (but 
couldn't remember my m1 well enough to say authoritatively).  

Cheers, Brian
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: command to build the project using maven 1.1

[Brian Topping]

On May 25, 2012, at 12:58 AM, Barrie Treloar wrote:

> On Fri, May 25, 2012 at 2:23 PM, Gunachandra  wrote:
>> Thanks Ron Wheeler for replying. I am new to maven, they developed this
>> project around 10 years back. Now the requirement comes for this project.
>> can you please tell me how to upgrade this to latest version of maven.
> 
> As others have said the Maven 1 knowledge is pretty thin.
> 
> Your best bet is to start reading the freely available books at
> http://maven.apache.org/articles.html
> 
> Then writing your pom.xml from the knowledge contained in your Maven 1 files.

Because your project is very small, I would suggest not trying to "upgrade" it 
as much as start over on the build with a new project.  

What would be easiest for you is probably to start with a top-level POM 
project, then use the EJB, WAR and EAR archetypes to generate a new skeleton 
framework within that directory.  You'll need to read up how to do that, but 
it's not hard.  http://www.xinotes.org/notes/note/586/ looks like a good place 
to start.  Do all this with Maven 3.0.4, not earlier versions.

Once you have that building and a simple web page calling a simple EJB, copy 
your files from the old project into the new one and get the old application 
running in the new build.

Success with new systems is about starting with smaller successes and building 
upwards to your goal.  It sounds like you should plan a few days to a week to 
get things resolved but you should not have problems.

Hope that helps, Brian
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: [maven] Re: Mirroring repo1.maven.apache.org

[Brian Topping]

On Apr 23, 2012, at 9:23 PM, Andrew Hughes wrote:

>   2. Nexus will allow you to proxy/mirror a lot more than one repository,
>   it will also allow you to place rules on repositories and additional
>   configuration.

This is worth noting in a large / paranoid corporate environment from a couple 
of different perspectives:  

a) Without rules in place, it's possible to see what artifacts are being used 
throughout the company just by looking at the downloaded artifacts.  (The 
results may surprise you!)

b) With rules in place, it's easy to do things like limit any new artifacts 
from being used that are not approved.  Developers can't be stopped from 
downloading artifacts from around the interwebs, but if they can't add them to 
the repository you control, they will break the build by changing POMs to 
reference them.

For the ultra-paranoid, putting the POMs under 24x7 change control keeps any 
changes to the repositories from being checked in.  I did this on a job at a 
big phone company last year.

Alternatively, Maven has a unique HTTP User-Agent, and it would be easy for 
corporate security to configure firewalls to reject any outside access to the 
Maven UA except via Nexus.  This would allow the POMs to remain unlocked, but 
any references to new repositories from the corporate LAN would be rejected 
(regardless of the source of the project or whether the POM was under change 
control).  Again, it's not that you are trying to stop one person from changing 
their UA, but stop the majority of people from accidentally downloading malware 
from a rogue repo after they check out tainted source.

It's hard to know what "other concerns" the original poster had, but maybe this 
provides some ideas if it is about security.

HTH, B
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: [maven] Re: Mirroring repo1.maven.apache.org

[Brian Topping]

Hi Jason,

I don't know every detail, but my memory of it is the details that I gave you.  
You can find more in the list archives.  There's a lot of history on things, 
such as why the repository directory structure moved from flat to hierarchical 
(the CPU costs of generating index.html pages was large).  Ibiblio was the 
master host for central for many years, and they finally had to push back 
because the bandwidth use was so high.  Sonatype took over primary hosting 
sometime after that.

It stands to reason that the 80/20 rule applies very well here, as most 
projects only use one version of a given library and do not change very often.  
Downloading 30 other versions of it, as well as 30 versions of hundreds of 
other projects that aren't ever used by a site (including sources) are what 
caused the general prohibition on doing this.  All it takes is a few sites 
globally rsyncing and the aggregate bandwidth required to host central goes up 
by orders of magnitude.  It's not a good use of scarce resources to cater to a 
few groups that can't get their IT department to install Nexus.

I'm sure there's some community policy on when it's okay for rsyncing ibiblio, 
and that's probably why it's still there.

Cheers, Brian

On Apr 22, 2012, at 11:56 AM, Jason Pyeron wrote:

>> -Original Message-
>> From: Brian Topping 
>> Sent: Sunday, April 22, 2012 11:32
>> 
>> On Apr 22, 2012, at 10:26 AM, Jason Pyeron wrote:
>> 
>>> 1. Is mirrors.ibiblio.org a good source for mirroring 
>> repo1.maven.apache.org?
>>> 2. is there a strong reason not use rsync?
>> 
>> Mirroring a repository like that is considered very bad form 
>> and will probably get your servers blacklisted.
> 
> This caught me off guard. Is that not the point of ibiblio.org supporting 
> rsync?
> We have a daily rsync set up with them for other projects.
> 
>> 
>> I don't have the benefit of other posts you may have made on 
>> this subject, 
> 
> No other posts on this topic.
> 
>> but unless you are hosting half the known world 
>> of developers, why wouldn't you just use a repository? 
> 
> The mirror team has bandwith management infrastructure inplace. They did not
> want to modify their system to support Nexus for Nexus sake. We have a nexus
> server on our dev lan already. Our dev lan does not have direct access to the
> internet.
> 
>> It 
>> makes things so much simpler with your builds since real 
>> world projects generally do not pull from just central.  
> 
> It was listed on the bandwidth report.
> 
>> Having a half-dozen repositories in your build is a great way 
>> to have it constantly slow (and even slower at times when any 
>> one of those repositories is offline).  Caching those 
>> repositories through Nexus insulates you from their downtime, 
>> without having to soak their bandwidth for files you will never use.
> 
> I agree that the Nexus pull only when needed is nice. But there are other
> concerns too. The real question is there a strong reason for not using rsync
> other than use Nexus.
> 
> 
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> -   -
> - Jason Pyeron  PD Inc. http://www.pdinc.us -
> - Principal Consultant  10 West 24th Street #100-
> - +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
> -   -
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> This message is copyright PD Inc, subject to license 20080407P00.
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


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

Re: Mirroring repo1.maven.apache.org

[Brian Topping]

On Apr 22, 2012, at 10:26 AM, Jason Pyeron wrote:

> 1. Is mirrors.ibiblio.org a good source for mirroring repo1.maven.apache.org?
> 2. is there a strong reason not use rsync?

Mirroring a repository like that is considered very bad form and will probably 
get your servers blacklisted.

I don't have the benefit of other posts you may have made on this subject, but 
unless you are hosting half the known world of developers, why wouldn't you 
just use a repository?  It makes things so much simpler with your builds since 
real world projects generally do not pull from just central.  Having a 
half-dozen repositories in your build is a great way to have it constantly slow 
(and even slower at times when any one of those repositories is offline).  
Caching those repositories through Nexus insulates you from their downtime, 
without having to soak their bandwidth for files you will never use.

$0.02...

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

Re: Is Maven the answer?

[Brian Topping]

Adding to the valid observations of others, I'd first consider the size of the 
project, number of people that are going to be using it and their experience 
with Maven.  

If you want do to such a build cleanly with Maven, the best way to do it is by 
creating or obtaining plugins for the various tasks.  There actually is a PHP 
plugin, for instance, and others would be simple to make.  But if it's just a 
few people that know Maven and hoards of others that complain about it being 
there or JVM languages being a part of the build, it's just asking for 
problems.  For instance, you will probably find the team assigning any and all 
issues with the build to you.

OTOH, if you have a large organization that is going to use the build and a 
majority knows Maven already, plugins and lifecycle are still quite applicable 
and might be more enjoyable.

Maven can solve this problem just fine, but since dependency resolution and 
artifact versioning / releases may not be primary requirements for you, the 
non-technical issues Maven creates may outnumber the issues that it resolves.

$0.02... Brian


On Mar 1, 2012, at 12:13 AM, Néstor Boscán wrote:

> Although I really like maven, and use it in all my projects, maven is
> tightly integrated with the project lifecycle (clean, compile, package,
> install, deploy ,etc) so ant looks like a better fit for what you're
> looking for.
> 
> Néstor
> 
> On Wed, Feb 29, 2012 at 11:51 PM, Ron Wheeler <
> rwhee...@artifact-software.com> wrote:
> 
>> I would have suggested Ant since it is easy to use, widely supported with
>> documentation, books and examples.
>> It can do damn near anything.
>> 
>> make seems awfully obscure but it is used a lot for installation.
>> 
>> maven does not seem like a good fit.
>> 
>> Ron
>> 
>> 
>> On 29/02/2012 10:20 PM, Yuen-Chi Lian wrote:
>> 
>>> For such scripting with phases, I find rake (or make) to be more suitable
>>> than ant or Maven. Or try BuildR.
>>> 
>>> Yuen-Chi Lian | www.yclian.com
>>> "I do not seek; I find." - Pablo Picasso
>>> 
>>> 2012/3/1 Terence 
>>> Stephens
 
>>> 
>>> I'm looking for a tool that will help me:
 Build Java Code
 Move Php code to a different location on my computer
 Create New Directories on the server and upload content to them (via
 FTP over SSL or maybe SSH)
 Download whole directories and then zip of the contents
 
 
 I know I could do this in a shell script, but I think I would have
 better luck with a Java based tool.  This is outside the scope of
 Maven's uses.  For my needs, should I look into using Maven or find a
 different tool?
 
 thanks.
 
 --**--**
 -
 To unsubscribe, e-mail: 
 users-unsubscribe@maven.**apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 
 
>> 
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: rwhee...@artifact-software.com
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>> 
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 


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

Re: customizing the snapshot version build number

[Brian Topping]

On Feb 22, 2012, at 10:16 AM,  wrote:

> 
>> P.S. I think screwing around with the Maven snapshot naming scheme is
>> asking for trouble. Putting it in the manifest seems safer to me.
>> Unfortunately, you didn't elaborate on *why* you want to do this, so we
>> can't really comment on any alternative solutions.
>> 
> 
> Oh, I can elaborate ;)  This is currently how my team traces its way back 
> from an binary artifact in the field to source control checkins.  I assume 
> there are much better ways to do this, but, my approach, is an incremental 
> re-work of our nonstandard build with an eye towards the lowest hanging 
> fruit, iteratively.  Know what I mean?

It sounds like you're describing ad-hoc releases.  Recording the SCM id in the 
manifest will provide traceability, but you're also opening up the can of worms 
that variances in snapshots of the transitive dependencies make the version of 
a field installation the *set* of versions for the transitive snapshots that 
could also vary.  Make sense?  Resolving issues will get a lot harder because 
of this.

For that reason, I'd adjust your process so field engineers can generate 
releases on the CI in a self-service manner.  If I were BigCo, I'd probably 
link the release generation requests to the field sites that use them so that I 
can figure out what customers have these "releases" when it comes time to get 
them all updated.

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

Re: Converting ant build project to Maven based project

[Brian Topping]

On Feb 14, 2012, at 2:22 PM, Bobbepalli, Purnachandrarao wrote:

> Hi Good Afternoon to everybody
> 
> This is PurnachandraRao, my first day in this maven users list.
> 
> I want to how to convert Ant Build based project to Maven based project.

Some resources for you to review first:

0. http://www.sonatype.com/books/mvnref-book
1. http://www.lmgtfy.com?q=convert+Ant+Build+based+project+to+Maven
2. http://catb.org/esr/faqs/smart-questions.html

When you get stuck with specific questions that aren't documented anywhere, 
this list is a great resource, but Maven is a mature product and most of what 
you need to know is easy to find in Google.  You may want to consider a class, 
http://www.developintelligence.com/catalog/software-engineering-training/development-tools/working-with-apache-maven
 is a good one that I have taught to folks in the past.

Good luck!
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: the simplest Maven Project that can possibly work in Intellij?

[Brian Topping]

You're on the right track with this, but keep in mind that IDEA's integration 
is import-only. 

What this means is when you make changes to your IDEA project, it won't (at 
least with any feature I am familiar with) rewrite your POM for you.  You must 
hand-code the POM, then IDEA will notice that you've changed it and ask if you 
want to re-import.  

There are some very convenient macros for maintaining the POM, available 
through the speed-menu (meta-enter).  One I use a lot is "insert dependency 
template".  

As far as M2_HOME is concerned, you'd be better to set that in the Maven prefs 
for IDEA.  It's in the Maven tab of Preferences (see 
https://skitch.com/t0pping/8bwrn/settings).

On Feb 14, 2012, at 3:48 PM, Gogirl wrote:

> How do I create the simplest Maven Project that can possibly work in
> Intellij?
> In Intellij, I created a pom file as a Maven Module:
> 
> 
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
>4.0.0
> 
>com.myCompany
>myProject
>1.0
> 
> 
> 
> 
> I then used file open project and an idea project was
> created. The Project file displays an .idea folder, the
> typical src folder two .iml files and my pom file.
> 
> I wrote a typical Hello World  under src/main/java
> public class HelloWorld {
> public static void main(String[] args) {
>System.out.println("Hello World");
>}
> }
> 
> With View->WindowTools-> Maven Projects I can view all the
> goals that my pom created for me.
> 
> The symbols String and System cannot be resolved by Idea.
> When I try to compile from the Maven Project Window,
> I am asked to define M2_HOME which I have done under system 
> variables with the \apache-maven-3.0.4\bin.
> It repeats the same errors.
> 
> All i want is to be able to use the goals I see in the Maven project 
> window and to see the magic of Maven from Idea. Any advice greatly
> appreciated.
> 
> --
> View this message in context: 
> http://maven.40175.n5.nabble.com/the-simplest-Maven-Project-that-can-possibly-work-in-Intellij-tp5483841p5483841.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


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

Re: Mvn commands are stalling

[Brian Topping]

On Jan 9, 2012, at 12:01 PM, Robert Scholte wrote:

> Even though I'm not a newbie, I can see 2 potential problems with this 
> sentence:
> 1. line 84, column 15 of what? It doesn't mention the file. Sure, it always 
> about the poms, but we're talking about unexperienced users here.
> 2. build.plugins.plugin.version ? This doesn't look like xml, so maybe you're 
> not triggered to look inside the pom. And if you use a pom-editor, you may 
> have never seen the xml.

Another observation I might try to append to Robert's list is how to separate 
the signal from the noise.  My personal opinion is that Maven is pretty chatty, 
which is great for experienced users, but a bit overwhelming for some new 
users.  

One option would be to reduce verbosity, but that doesn't really serve 
experienced users well.  Another option would be what Karaf has done and that 
is to use colorized logs.  
http://blog.uncommons.org/2006/04/09/colour-coded-console-logging-with-log4j/ 
covers the gist of it.  The ANSI colorization characters are kind of ugly in 
terminals that aren't set up correctly, but it might help improve readability?

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

Re: EAR as WAR dependency?

[Brian Topping]

How would you solve this problem without Maven?  What kind of EAR could load a 
WAR it doesn't know about? 

I don't doubt that this is possible with some magic, but that magic is separate 
from Maven.  

Once you have the magic well-defined, Maven can help you build it and package 
it.  

Brian

On Oct 18, 2011, at 11:50 AM, Manos Batsis wrote:

> 
> Hello,
> 
> I've got an EAR application for which I'm building a specific extension as an 
> additional WAR. My question is, what is the best way to do this without the 
> original EAR's POM knowing anything about the extra WAR? Any examples would 
> be appreciated.
> 
> 
> Many thanks,
> 
> Manos
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 


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

Re: Programmatically get maven properties

[Brian Topping]

The code you put in your original email didn't make it to the list, maybe it 
was formatted somehow.  

What I think you are looking for is:

> /** @parameter default-value="${project}" */
> private org.apache.maven.project.MavenProject mavenProject;

This will give you the MavenProject object, which you can dereference to find 
the properties.

HTH, Brian

On Oct 17, 2011, at 11:27 PM, deusaquilus wrote:

> I'm trying to use the maven programmatic APIs to get the properties of the
> default profile (i.e. the stuff in Project->Properties->XYZ) and return them
> as a Java 'Properties' object, so far with no luck. First I thought of
> trying to use the maven invoker e.g:
> 
> 
> 
> That just seems to return null. The other way I tried was using the maven
> builder APIs like so:
> 
> 
> 
> That causes a "mavenTools: null" exception to be thrown from the
> MavenProject class.
> How do I get this to work?
> 
> --
> View this message in context: 
> http://maven.40175.n5.nabble.com/Programmatically-get-maven-properties-tp4912280p4912280.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 


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

Re: default auth for settings.xml

[Brian Topping]

You can use the ID from one of them in both places.  That's what I do.  

On Oct 13, 2011, at 7:16 PM, Tommy Chheng wrote:

> B is the most similar workflow.
> 
> So i have a few remote maven repos i want to use:
> i.e.  scala-tools.org and sweble, etc.
> 
> I added both of these to my Nexus server as proxy repos.
> 
> In my local settings.xml, i had to add two  entries. each
> with the same set of nexus username/password.
> 
> I would like to avoid having to specify the nexus username/password in every
>  definition.
> 
> 
> 
> On Thu, Oct 13, 2011 at 12:06 PM, Ansgar Konermann <
> ansgar.konerm...@googlemail.com> wrote:
> 
>> Am 13.10.2011 20:57, schrieb Tommy Chheng:
>>> The server ids are different because each is a different proxied server.
>> 
>> What exactly do you mean by "each is  a different *proxied server*"?
>> 
>> a) I want to deploy to maven repositories on different servers which are
>> located outside my organisation, but I have to use my organisation's
>> proxy to connect to these
>> or
>> b) I have a nexus repository manager where I configured various "proxy
>> repositories" (so a *proxied server* is the same as a proxied repository
>> in your wording).
>> or
>> c) same as b) but in addition I'd like to be able to deploy to the proxy
>> repositories
>> 
>> Ansgar
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 
>> 
> 
> 
> -- 
> @tommychheng
> http://tommy.chheng.com


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

Re: New to Maven

[Brian Topping]

Niyas,

There's really no effective way to use email for a precise solution to your 
problem.  The only way to solve a problem is to know what the problem is in the 
first place, and if it had already been solved, you could just copy it.  But 
the fact is, the problems are never the same (so there is no answer we can 
point you toward), and it turns out it really is faster to read a little or 
hire someone that knows it to come in than to ask one question after another 
over email for days on end.  It will take you forever!

http://catb.org/~esr/faqs/smart-questions.html might be a better resource to 
start with though.  You must understand that everyone on the internet wants to 
go home and do other things just as much as you do.  Your respect for their 
time and presenting concise, interesting, and localized problems that 
demonstrate gaps in the documentation will get you answers far more quickly.  
In other words, as the FAQ says:

> The first thing to understand is that hackers actually like hard problems and 
> good, thought-provoking questions about them. If we didn't, we wouldn't be 
> here. If you give us an interesting question to chew on we'll be grateful to 
> you; good questions are a stimulus and a gift. Good questions help us develop 
> our understanding, and often reveal problems we might not have noticed or 
> thought about otherwise. Among hackers, "Good question!" is a strong and 
> sincere compliment.

Please think about others first, whether you would ask the same question of 
someone who worked with you in your office, do some reading, and ask smart 
questions!  

Cheers, Brian


On Oct 11, 2011, at 12:58 AM, niyasmansoor wrote:

> Hi Barrie,
> 
>   Many thanks for your prompt response .
> 
>   I have a project handover with source code .
> 
>   This eclipse project is having dependency and is using maven repository
> concept .
> 
>   I do not have much time to go through maven extensively , that was the
> reason why i asked for a quick solution.
> 
> --
> Regards,
> Niyas 
> 
> --
> View this message in context: 
> http://maven.40175.n5.nabble.com/New-to-Maven-tp4890634p4890682.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 


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

Re: Possible to disable maven central ( repo1 ) ?

[Brian Topping]

Good point, but I don't believe it's necessary if CI and management are the 
only clients that can push dependencies to the internal repository.  Then, if 
someone checks in a POM that references an artifact that hasn't been blessed 
because they are using other repositories, CI will fail, also stopping the 
local production artifacts from being pushed.  If production artifacts only 
come from the internal repo that CI pushed, you have transitive assurance that 
everything is clean.

There are a lot of repositories out on the net, blocking central and mirrors 
with a firewall is a good reminder not to use them, but relying on that to keep 
unapproved artifacts out of production builds is fraught with issues like this.

On Sep 26, 2011, at 8:02 PM, Manfred Moser wrote:

> And in addition if you want to make sure they do not use anything from 
> central you might want to block it on the firewall level (including mirrors)
> 
> On 11-09-26 04:51 PM, Brian Topping wrote:
>> http://www.sonatype.com/books/nexus-book/reference/maven-sect-single-group.html
>>  discusses how to do that.
>> 
>> On Sep 26, 2011, at 7:47 PM, Sony Antony wrote:
>> 
>>> Hi :
>>> We have an http internal repository to which, I would like all developers to
>>> point for their local builds.
>>> But I dont want them to go to repo1.maven.org
>>> Looks like if I switch maven to online (false  ), it will
>>> attempt to go to repo1 ( in addition to the repositories specified under
>>> settings.xml )
>>> Is it possible to change this behavior
>>> 
>>> --sony
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 


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

Re: Possible to disable maven central ( repo1 ) ?

[Brian Topping]

http://www.sonatype.com/books/nexus-book/reference/maven-sect-single-group.html 
discusses how to do that.

On Sep 26, 2011, at 7:47 PM, Sony Antony wrote:

> Hi :
> We have an http internal repository to which, I would like all developers to
> point for their local builds.
> But I dont want them to go to repo1.maven.org
> Looks like if I switch maven to online ( false ), it will
> attempt to go to repo1 ( in addition to the repositories specified under
> settings.xml )
> Is it possible to change this behavior
> 
> --sony


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

Re: Should a plugin appear in pluginManagement if it already appears in build/plugins?

[Brian Topping]

If I may compliment what Anders has said already...

One of the distinctions I make between putting a plugin declaration in a parent 
POM versus a pluginMgmt is whether I want a plugin to be defined as a template 
for a given group of inherited projects or invoked for every child of that same 
group.  The distinction is important.  For instance, if I have a tree of 
projects starting with the parent, I might want a plugin to be configured in 
only one place, but only invoked on a random subset of the children.  In this 
case, defining the *template* is the way to go (i.e. pluginMgmt), but if I want 
the plugin to be used everywhere (maven-source-plugin comes to mind), I define 
that in the plugins section of the parent project. 

In the case of maven-source-plugin, if I did it as a pluginMgmt, I'd still have 
to *instantiate* the plugin in each build, creating four extra lines of XML in 
each POM (and the opportunity for someone to forget those four lines in new 
projects).  By putting it in build/plugins, it is instantiated for *every* 
child build.

Note there are also some pretty cool rules for defining plugins in a parent but 
then merging additional configuration in children.  I don't remember them all, 
but this can be done to great effect, allowing a plugin defined in a parent to 
have different/additional configuration in a child.

$0.02  Brian

On Sep 10, 2011, at 8:19 AM, Anders Hammar wrote:

> So one use case to have move the configuration to the pluginMgmt
> section would be if you want to have some config for the build AND for
> when executing the plugin goal directly.
 I take it you mean the plugin entry in build/plugins would then just
 contain the groupId/artifactId.
>>> 
>>> Yes, and the execution declaration.
>> 
>> Sorry, what do you mean by that?
>> 
>> Are you saying that there are parts of the pluginManagement
>> definitions that are not applied to build/plugins?
>> If so, is there any point in having the execution declaration in the
>> pluginManagement section?
> 
> Ok, now we're talking advanced stuff. I would only put the execution
> declaration in the pluginMgmt section if it would be something that is
> to be reused by several children projects. Otherwise I would put the
> declaration in build/plugins/plugin in the project it belongs.
> But there are exceptions to this of course. One would be if you want
> to configure the default execution (the one from CLI) differently than
> the one(s) bound to the lifecycle. Then you need to re-define the
> default execution (which is the one from CLI) in pluginMgmt and for
> that execution add the configuration you want (thus, within the
> execution section, not on plugin level).
> 
> But this is me. Others may very well have a different opinion.
> 
> /Anders
> 
>> 
>>> /Anders
>>> 
 
> And some people like defining the version of plugins in the pluginMgmt
> section but not in build/plugins. Then you define this in a parent and
> only have one place to change when new versions are released. This is
> how I do it.
 
 Yes, that is mainly how it is being used.
 
> /Anders
 
 Thanks!
 
> On Sat, Sep 10, 2011 at 02:14, sebb  wrote:
>> AIUI, both build/plugins and build/pluginManagement are inherited by
>> child projects, the difference being that plugiManagement entries are
>> only used if the child project references the plugin in its
>> build/plugins section.
>> 
>> That being the case, if a plugin is defined in build/plugins, is there
>> any point also including it in the build/pluginManagement/plugins
>> section?
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 
>> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>> 
>>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 
>> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 


--

Re: How to add a folder to the classpath used during maven build

[Brian Topping]

That won't work.  Maven keeps internal lists of these kind of things, and the 
plugins contribute to it.  So for instance, the compiler plugin adds the 
location it put the compiled objects to the list.  It generally doesn't make 
sense for these lists to be accessible outside the plugin space.

You could make a command-line system property ("-D") that is used in the plugin 
description with interpolation, but the plugin still needs to be there in the 
POM to do something with the system property you define.

On Aug 31, 2011, at 10:58 AM, Benjamin Dreux wrote:

> I'm sorry but i don't want to modify my pom
> I just want to change the maven parameters, or a env variable
> 
> Is there a way you know to achieve this ??
> 
> 2011/8/31 Brian Topping :
>> http://mojo.codehaus.org/build-helper-maven-plugin/add-source-mojo.html 
>> added to the verify phase might be what you are looking for?
>> 
>> If not, there are a lot of other goals in that plugin that have similar 
>> functionality, maybe one of them is better suited.
>> 
>> On Aug 31, 2011, at 10:34 AM, Benjamin Dreux wrote:
>> 
>>> Hi
>>> I want to add a folder to the classpath used during the maven build
>>> (verify pase to be precise)
>>> This folder must not be in the project (not inside src or any other child)
>>> How could i add  something to the classpath used my maven.
>>> 
>>> I've seen solution using the pom.xml, be since the folder is not in my
>>> source file, i don't want it in my pom neigther.
>>> 
>>> I suspect it's possible using the command line, maybe something like 
>>> -Dclassapth
>>> But i'm not sure
>>> 
>>> thanks for your help
>>> 
>>> --
>>> Benjamin Dreux
>>> Analyste-Programmeur
>>> Chaire de logiciel libre-Finance Social et solidaire
>>> UQAM
>>> Montréal
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>> 
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 
>> 
> 
> 
> 
> -- 
> Benjamin Dreux
> Analyste-Programmeur
> Chaire de logiciel libre-Finance Social et solidaire
> UQAM
> Montréal
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 


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

Re: How to add a folder to the classpath used during maven build

[Brian Topping]

http://mojo.codehaus.org/build-helper-maven-plugin/add-source-mojo.html added 
to the verify phase might be what you are looking for?

If not, there are a lot of other goals in that plugin that have similar 
functionality, maybe one of them is better suited.

On Aug 31, 2011, at 10:34 AM, Benjamin Dreux wrote:

> Hi
> I want to add a folder to the classpath used during the maven build
> (verify pase to be precise)
> This folder must not be in the project (not inside src or any other child)
> How could i add  something to the classpath used my maven.
> 
> I've seen solution using the pom.xml, be since the folder is not in my
> source file, i don't want it in my pom neigther.
> 
> I suspect it's possible using the command line, maybe something like 
> -Dclassapth
> But i'm not sure
> 
> thanks for your help
> 
> -- 
> Benjamin Dreux
> Analyste-Programmeur
> Chaire de logiciel libre-Finance Social et solidaire
> UQAM
> Montréal
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 


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

Re: Scripting

[Brian Topping]

Oh yah, that's right, there is a Groovy plugin.  Another one of those paths 
that I would use sparingly.  (Well actually, on the project I saw it used on, I 
went through and replaced it immediately.)

http://www.ronniealleva.org/index.php/2008/01/23/using-the-groovy-maven-plugin-to-do-magic/
 is an example.

The Maven plugins project has a wealth of tricks in it across the various 
plugins if/when you choose to create a true plugin.

On Aug 26, 2011, at 1:46 PM, Eric Kolotyluk wrote:

> OK, I grok the use of antrun as illustrated below. Is there anything more 
> general than antrun, for example execute some arbitrary commands or script 
> without having to write a plug-n? I'm thinking of a JavaScipt, Groovy or 
> Scala plugin - or am I just dreaming? If not, it might be fun to write such a 
> plugin for Maven, but for the moment I need a more expedient solution.
> 
> Cheers, Eric
> 
> |
>  [...]
>  
>
>  [...]
>  
>maven-antrun-plugin
>
>  
>deploy
>
>  
> 
>
> 
>  
>
>
>  run
>    
>  
>
>  
>
>  
>  [...]
> 
> |
> 
> 
> 
> On 2011-08-26 9:27 AM, Brian Topping wrote:
>> On Aug 26, 2011, at 12:13 PM, Hilco Wijbenga wrote:
>> 
>>> On 26 August 2011 07:02, Brian Topping  wrote:
>>>> A lot of people use antrun, see 
>>>> http://www.nyc.gov/html/oem/downloads/pdf/hurricane_map_english.pdf.  I 
>>>> personally do that as a last resort.
>>> What does a hurricane map have to do with Ant? :-)
>> LOL!  That was a map I was posting elsewhere about where not to buy an 
>> apartment in NYC.  I meant to post 
>> http://stackoverflow.com/questions/586202/best-practices-for-copying-files-with-maven,
>>  which has a reply from Tim O'Brien regarding antrun.
>> 
>> Anyway, off to write a plugin.  Too much fascinating information in the news 
>> today, gotta get some work done.
>> 
>> Cheers, Brian
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 


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

Re: Scripting

[Brian Topping]

On Aug 26, 2011, at 12:13 PM, Hilco Wijbenga wrote:

> On 26 August 2011 07:02, Brian Topping  wrote:
>> A lot of people use antrun, see 
>> http://www.nyc.gov/html/oem/downloads/pdf/hurricane_map_english.pdf.  I 
>> personally do that as a last resort.
> 
> What does a hurricane map have to do with Ant? :-)

LOL!  That was a map I was posting elsewhere about where not to buy an 
apartment in NYC.  I meant to post 
http://stackoverflow.com/questions/586202/best-practices-for-copying-files-with-maven,
 which has a reply from Tim O'Brien regarding antrun.

Anyway, off to write a plugin.  Too much fascinating information in the news 
today, gotta get some work done.

Cheers, Brian
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Scripting

[Brian Topping]

A lot of people use antrun, see 
http://www.nyc.gov/html/oem/downloads/pdf/hurricane_map_english.pdf.  I 
personally do that as a last resort.

I personally don't have a problem writing a plugin and adding it to my build.  
Reactor figures out the build order properly and does the right thing.  Using 
the plugin archetype (via 'mvn archetype:generate'), you get a plugin skeleton 
with no work.  

HTH, Brian

On Aug 26, 2011, at 9:54 AM, Eric Kolotyluk wrote:

> So if you need to actually do something that Maven does not do, for example 
> run a custom program to automatically generate some source code, what do 
> people usually do?
> 
> * Use a plug-in to run something like Ant or some other scripting tool
> * Write your own plug-in, or is this overkill for something really simple?
> * Something else, some other feature of Maven I am missing?
> 
> Cheers, Eric
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 


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

Re: Breaking a circular dependency on test utilities

[Brian Topping]

Hmm, maybe a plugin is in order for this.  As I thought about it some, assembly 
plugin isn't going to do anything to create a POM.  Makes sense in hindsight, 
assembly is for creating distributions and not Maven artifacts.  Shade plugin 
has facilities to generate a POM for the shaded jar which could be adapted for 
this case as well.

Seems there's not much way around two artifacts per build in this case, 
otherwise the core artifact is going to have to depend on unit testing 
artifacts, which is bad in this situation.

On Aug 26, 2011, at 2:15 AM, Anders Hammar wrote:

> Yep, I've run into a similar thing. In my case the tests were using
> classes in my core project, which would have been solvable by
> implementing interfaces (in a separate project). So both the tests
> artifact and the core artifact would then have a dependency to the
> core-api artifact.
> But you know the drill, dev team is under time pressure and just wants
> to do the release. So they kept the tests jar (with that classifier)
> in the core project. A real PIA for all other teams as they now don't
> get the transitive deps when they reuse that tests artifact.
> 
> /Anders
> 
> On Fri, Aug 26, 2011 at 04:26, Brian Topping  wrote:
>> Hi all,
>> 
>> I have typical module with tests, but the tests inherit from a base class.  
>> This base class (and a few related classes/resources) need to be generated 
>> as a separate jar so they can be used as a test scope dependency.
>> 
>> It initially seems like it would be an easy enough task for jar:test-jar, 
>> but that's going to include all the tests as well.  An  could be 
>> used, but the output still has tests, which is not 
>> quite correct.
>> 
>> The second option I looked at was to create a separate project for the base 
>> class and friends, but since the base class depends on classes in this first 
>> module, a circular dependency is formed.  The jar for the base class clearly 
>> needs to be created in the same project (i.e. one build creating two 
>> artifacts).
>> 
>> This would be easy enough to do with the assembly plugin, but out of 
>> academic curiosity, have others come across this problem and solved it 
>> differently?
>> 
>> Thanks for any input, Brian
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 
>> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 


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

Breaking a circular dependency on test utilities

[Brian Topping]

Hi all,

I have typical module with tests, but the tests inherit from a base class.  
This base class (and a few related classes/resources) need to be generated as a 
separate jar so they can be used as a test scope dependency.  

It initially seems like it would be an easy enough task for jar:test-jar, but 
that's going to include all the tests as well.  An  could be used, but 
the output still has tests, which is not quite correct.

The second option I looked at was to create a separate project for the base 
class and friends, but since the base class depends on classes in this first 
module, a circular dependency is formed.  The jar for the base class clearly 
needs to be created in the same project (i.e. one build creating two artifacts).

This would be easy enough to do with the assembly plugin, but out of academic 
curiosity, have others come across this problem and solved it differently?

Thanks for any input, Brian
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Kudos

[Brian Topping]

Yah, I'd have to agree with this sentiment.  Maven isn't the easiest thing to 
learn, but documentation has improved remarkably over the years and the 
"network effect" of having more people familiar with Maven means that there's 
Maven experts that are closer to more people in real life. 

More thanks to all the folks that made this happen!

On Aug 17, 2011, at 12:16 PM, Laird Nelson wrote:

> Mailing lists are often overrun with people complaining and reporting bugs
> and squabbles and whatnot.  I wanted to take a brief moment to simply say
> thanks to all for what has finally evolved into a really useful product.
> 
> I love the fact that I can pull down most open source projects these days,
> and, without really thinking too hard about it, pull up their pom.xml file
> and at least have a rough idea of what they're trying to accomplish.
> 
> I love that building and installing such a project has become as simple as
> mvn clean install.
> 
> I love that I don't have to get in the head of whichever
> build-engineer-of-the-moment crafted a hand-rolled Ant or Gradle build.  I
> love that as bulky and annoying as it can be, at least XML is declarative
> and easily read.
> 
> Anyhow, thanks.  Maven is not an easy system to learn, but once you do it
> pays off.
> 
> Best,
> Laird


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

Re: Archiva vs. Nexus

[Brian Topping]

Try http://localhost:8081/nexus.  

On Jul 25, 2011, at 3:30 PM, Eric Kolotyluk wrote:

> OK, so it is a bug, the correct way to start it is to go to the actual 
> directory and run
> 
> nexus.bat
> 
> without any parameters. Things seems to start up, but when I go to 
> http://localhost:8081 I get
> 
> HTTP ERROR: 404
> 
> Problem accessing /. Reason:
> 
> NOT_FOUND
> 
> Powered by Jetty://
> 
> I do have an open mind to issues, which is why I reported it on JIRA - I'm 
> just saying first impressions are very important.
> 
> Cheers, Eric
> 
> On 2011-07-25 12:20 PM, Brian Topping wrote:
>> I'd run it from a directory that does not contain spaces or other non 
>> alphanumeric characters.  Yours has two spaces, one of each different 
>> parenthesis, and a ">" in it.
>> 
>> Nexus is a very robust and easy to use installation that gets a lot of 
>> attention.  You are not "supposed to waste time on installing it", but 
>> having an open mind to issues that are often found in cross-platform 
>> software is helpful.  Especially when you are running it on Windows.
>> 
>> On Jul 25, 2011, at 3:06 PM, Eric Kolotyluk wrote:
>> 
>>> So I downloaded Nexus 1.9.2, watched the video, read the user manual on 
>>> starting Nexus, entered
>>> 
>>> C:\Program Files 
>>> (Open)\Sonatype\nexus-oss-webapp-1.9.2-bundle\nexus-oss-webapp-1.9.2>bin\jsw\windows-x86-64\nexus
>>>  start
>>> 
>>> and got back
>>> 
>>> FATAL  | wrapper  | Unable to open configuration file. C:\Program Files 
>>> (Open)\Sonatype\nexus-oss-webapp-1.9.2-bundle\nexus-oss-webapp-1.9.2\start
>>> Press any key to continue . . .
>>> 
>>> First impressions are very important - this one was pretty bad. How much 
>>> time am I supposed to waste now trying to figure out how to actually start 
>>> Nexus?
>>> 
>>> Maybe Archiva actually works according to the documentation...
>>> 
>>> Cheers, Eric
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>> 
>>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 


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

Re: Archiva vs. Nexus

[Brian Topping]

I'd run it from a directory that does not contain spaces or other non 
alphanumeric characters.  Yours has two spaces, one of each different 
parenthesis, and a ">" in it.

Nexus is a very robust and easy to use installation that gets a lot of 
attention.  You are not "supposed to waste time on installing it", but having 
an open mind to issues that are often found in cross-platform software is 
helpful.  Especially when you are running it on Windows.  

On Jul 25, 2011, at 3:06 PM, Eric Kolotyluk wrote:

> So I downloaded Nexus 1.9.2, watched the video, read the user manual on 
> starting Nexus, entered
> 
> C:\Program Files 
> (Open)\Sonatype\nexus-oss-webapp-1.9.2-bundle\nexus-oss-webapp-1.9.2>bin\jsw\windows-x86-64\nexus
>  start
> 
> and got back
> 
> FATAL  | wrapper  | Unable to open configuration file. C:\Program Files 
> (Open)\Sonatype\nexus-oss-webapp-1.9.2-bundle\nexus-oss-webapp-1.9.2\start
> Press any key to continue . . .
> 
> First impressions are very important - this one was pretty bad. How much time 
> am I supposed to waste now trying to figure out how to actually start Nexus?
> 
> Maybe Archiva actually works according to the documentation...
> 
> Cheers, Eric
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 


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

Re: Pimp My Mojo

[Brian Topping]

On Jul 25, 2011, at 7:57 AM, Aldrin Leal wrote:

> --
> -- Aldrin Leal,  / http://www.leal.eng.br/mnemetica/
> 
> 
> On Mon, Jul 25, 2011 at 8:15 AM, Brian Topping  wrote:
> 
>> A few minor observations (since you are soliciting them).  I haven't run
>> the plugins or have any experience of not in the plugin domain, so I can't
>> comment on the goals or workflow.
>> 
>> 1. I'm not sure of the benefit of putting the source on Bitbucket, versus
>> under Codehaus' Mojo project, the latter will push to Maven central and
>> allow for better name resolution.  More
> 
> 
> Sorry, are we on the same page? I'm mostly a mercurial user, but I'm aware
> there are git users (Mercurial is pretty flexible to let me mirror my hg
> repo out to github). I decided to keep my own mojo on its own address in
> order to stand my own work and company (for the record, it is at
> http://beanstalker.ingenieux.com.br/).

http://www.sonatype.com/books/mvnref-book/reference/writing-plugins-sect-custom-plugin.html#writing-plugins-sect-plugin-prefix

> 
> importantly, the visibility provided by being on Codehaus will encourage
>> someone that needs something similar to add to your project instead of
>> starting their own (if they didn't know yours existed).
>> 
> 
> Like forks on github?
> 

I didn't see your second link to github.  Maybe I should have spent more time 
reading your email, but there you go, feedback in the form of what wasn't 
noticed.  

> 
>> 2. If you really want to keep things in your own silo, consider getting
>> approved to use the Sonatype OSS repository.
>> 
> 
> It is already being put into OSS and released on central

Yes, I started by looking at the lower-level POMs.  (I'm starting to very much 
feel I shouldn't have wasted the time on commenting at all)

> 
> 3. The license is not clear.  License compliance is important in most
>> enterprises, and having a license protects you against personal liability.
>> 
> 
> Beyond bitbucket? Headers and meta state APSL

I don't see a LICENSE.TXT nor do I see headers on 
https://github.com/ingenieux/beanstalker/blob/master/mapreduce-maven-plugin/src/main/java/br/com/ingenieux/mojo/mapreduce/AbstractMapreduceMojo.java,
 for instance, other files seem similarly affected.  Consider using 
http://mojo.codehaus.org/license-maven-plugin/ (another project hosted at 
Codehaus).

> 
> 
> 
>> 4. Your plugin build is not running the "helpmojo" goal.  This generates
>> the proper code so (for instance) mapreduce-maven-plugin:help will generate
>> a usage information.
>> 
> 
> I will look into it.
> 
> 
>> 
>> The code otherwise looks pretty clean.  The use of expressions in
>> parameters is a big deal for usability, and you have that covered.  The
>> plugin API was designed to be easy to develop for, and you've used it
>> correctly.
>> 
> 
> Oh, great. Thank you


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

Re: Pimp My Mojo

[Brian Topping]

A few minor observations (since you are soliciting them).  I haven't run the 
plugins or have any experience of not in the plugin domain, so I can't comment 
on the goals or workflow.

1. I'm not sure of the benefit of putting the source on Bitbucket, versus under 
Codehaus' Mojo project, the latter will push to Maven central and allow for 
better name resolution.  More importantly, the visibility provided by being on 
Codehaus will encourage someone that needs something similar to add to your 
project instead of starting their own (if they didn't know yours existed).
2. If you really want to keep things in your own silo, consider getting 
approved to use the Sonatype OSS repository.
3. The license is not clear.  License compliance is important in most 
enterprises, and having a license protects you against personal liability.
4. Your plugin build is not running the "helpmojo" goal.  This generates the 
proper code so (for instance) mapreduce-maven-plugin:help will generate a usage 
information.

The code otherwise looks pretty clean.  The use of expressions in parameters is 
a big deal for usability, and you have that covered.  The plugin API was 
designed to be easy to develop for, and you've used it correctly.   

Cheers, Brian

On Jul 24, 2011, at 11:06 PM, Aldrin Leal wrote:

> Folks,
> 
> I wrote a few weeks ago a plugin for Amazon Elastic Beanstalk, with some
> Elastic MapReduce features as well.
> 
> It is at http://bitbucket.org/aldrinleal/beanstalker, with a git mirror at
> http://github.com/ingenieux/beanstalker
> 
> Can you look and give me advice on how to improve, and/or any interesting
> point to raise? (Or perhaps just use it? hehe)
> 
> Thank you
> 
> --
> -- Aldrin Leal, 


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

Re: Beginner needs help: Maven won't run my tests...

[Brian Topping]

Julien,

Sorry I didn't notice you had responded.  Like most mailing lists, one thing to 
keep in mind is we're all doing this for free and at one time or another 
someone helped us out.  So we're just returning the favor. 

Anyway, your logs show the line:

> [DEBUG]   (f) testSourceDirectory =
> /home/julien/Documents/donnees/projets/Site emploi
> finance/java/cheetah/web/src/test/java

I see you made many changes like removing spaces and that would have also been 
my first suggestion.  

Now, please run the mvn command with -X again.  There's no need now to send the 
entire file, just search through the output for "testSourceDirectory" and make 
sure you can do "ls /home/julien/Documents/donnees/projets/Site emploi 
finance/java/cheetah/web/src/test/java" from the command line, for instance, 
but using whatever the new output from that line is.

Also, take a look at the web page for the surefire plugin configuration at 
http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html.  Note how 
testSourceDirectory is documented there, along with every other parameter in 
your -X output.  Pay close attention to each one, mapping it back to the 
documentation, then ask questions about the ones you don't understand and think 
might be causing problems.

In the worst case, regenerate the project using a project archetype in a second 
directory and look how it gets set up there.  

Cheers, Brian

On Jul 19, 2011, at 2:36 AM, Julien Martin wrote:

> up
> 
> 2011/7/17 Julien Martin 
> 
>> Hello Thomas and thank you for the reply,
>> Yes the tests are indeed located there.
>> I was not able to reproduce the bug unfortunately...
>> Does anyone have any idea where else to look for a problem?
>> Regards,
>> Julien.
>> 
>> 
>> 
>> 2011/7/17 Thomas Sundberg 
>> 
>>> Hi Julien!
>>> 
>>> You still haven't told us where your tests are locted. They should be
>>> located in the directory
>>> 
>>> src/test/java/com/cheetah/web/pages
>>> 
>>> to be picked up and executed by Surefire.
>>> 
>>> Is it possible to clone your project, remove almost everything and
>>> keep a Hello world so you are able to locate the problem with a
>>> minimal set of possible problems and then add the things you want,
>>> step by step?
>>> 
>>> HTH
>>> Thomas




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

Re: Beginner needs help: Maven won't run my tests...

[Brian Topping]

You forgot to mention where your test is located.  I don't see a package on 
your test snippet, but it should be in 
${projectRoot)/src/test/java//CreateJobPostingTest.java.  Nothing else 
looked particularly problematic.

If that doesn't solve the problems, you should be able to find more clues with 
the output of 'mvn test -X'.  That will be helpful for anyone helping you out.

Hope that helps…

On Jul 16, 2011, at 5:53 PM, Julien Martin wrote:

> Hello,
> I would like for Maven to run my tests when I issue the following command:
> "mvn test"
> However, despite the presence of a test class named "CreateJobPostingTest",
> maven won't run my tests.
> Can anyone please help?
> 
> Here is my test class:
> 
> public class CreateJobPostingTest {
> 
>@Test
>public void test1() {
>String appPackage = "com.cheetah.web";
>String appName = "app";
>PageTester tester = new PageTester(appPackage, appName,
> "src/main/webapp");
>Document doc = tester.renderPage("CreateJobPosting");
>Element createJobPostingForm =
> doc.getElementById("createJobPostingForm");
>Map fieldValues = new HashMap();
>fieldValues.put("jobPostingTitle", "Développeur
> java/Tapestry/Junit");
>fieldValues.put("jobPostingBody", "Poste de de développeur agile/XP
> qui travaillera en TDD exclusivement");
>Document docFromForm = tester.submitForm(createJobPostingForm,
> fieldValues);
>assertTrue(docFromForm.toString().contains("TDD exclusivement"));
>}
> 
>@Ignore
>@Test
>public void test2() {
> 
>}
> }
> 
> Here is my pom.xml:
> http://maven.apache.org/POM/4.0.0"; xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 
>4.0.0
>com.cheetah
>cheetah-web
>war
>1.0-SNAPSHOT
>cheetah-web
> 
>
>
>
>src/main/java
>
>**/*.tml
>**/*.properties
>
>
>
>src/main/resources
>
>**/*.xml
>**/*.properties
>
>
>
> 
>
>
>org.apache.maven.plugins
>maven-war-plugin
>2.1.1
>
>
>org.apache.maven.plugins
>maven-compiler-plugin
>
>1.6
>1.6
>
>
>
>org.apache.maven.plugins
>maven-surefire-plugin
>
>
>
> 
>
> 
>
>com.cheetah
>cheetah-domain
>1.0-SNAPSHOT
>
>
>com.cheetah
>cheetah-service
>1.0-SNAPSHOT
>
>
>org.apache.tapestry
>tapestry-core
>5.2.6
>
>
>org.apache.tapestry
>tapestry-beanvalidator
>5.2.6
>
> 
>org.apache.tapestry
>tapestry-spring
>5.2.6
>
>  
>org.apache.tapestry
>tapestry-test
>5.2.6
>
>
>javax.servlet
>servlet-api
>2.5
>provided
>
>
>junit
>junit
>4.8.2
>test
>
>
> 


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

Re: Enabling functionality for all profiles BUT one?

[Brian Topping]

I'd create a plugin that wraps your troublesome plugin with Tim Moore's awesome 
mojo-executor library at https://github.com/TimMoore/mojo-executor.  

I just got done using it for a Real Big Client and it works great.

Just have your plugin gracefully return with a warning when the environment is 
ripe for failure.  Problem solved.

Remove the plugin when MDEP-259 is fixed.

HTH, Brian

On Jul 10, 2011, at 9:39 AM, Brinker, Don wrote:

> Hi all,
> 
> I've got an interesting situation where I need to disable functionality for 
> one profile only.  Well, unless of course there's a better solution to the 
> problem.
> 
> In my project, we have a number of different submodules.  One of these 
> modules (client) generates web service client JARs based on a schema file 
> placed in the Maven repo by a previous module (it uses dependency:copy to 
> pull down the schema file).  Now this works all well and good unless I try to 
> build the site.  When I do *that*, a bug in Maven (MDEP-259) makes the client 
> module fail outright with errors.
> 
> My natural tendency would be just to disable the client module for the 
> profile used for site generation.  However, we have a number of other 
> profiles, all of which should have this enabled.  For reasons that should be 
> obvious, I'd really rather not define a modules block for every profile.
> 
> Any thoughts/ideas?
> 
> Thanks
> - Don
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 


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

Re: Problems using Maven to build servicemix.

[Brian Topping]

1. Use Maven 2.2.1 or 3.0.3.  I haven't tracked SM or whether it's m3 based.
2. Make sure you are running Maven in a directory that has a proper POM.  It 
appears yours is not valid.

On Jul 9, 2011, at 11:58 PM, Sanjana Kadaba Viswanath wrote:

> Hi,
> I am really new to servicemix. I want to build a project on orchestration 
> using servicemix. I am having serious problems with maven. I want to use 
> maven2.0.8 and I use Mac OSX. I am not able to build anything. Do you have 
> any idea how to get rid of the issue?
> Please advise me how to proceed. I am really stuck...!!! 
> 
> 
> 
> My Error trace is as follows:
> ___
> 
> INFO] Error building POM (may not be this project's POM).
> 
> 
> Project ID: unknown
> POM Location: /Users/sanju/citytime/pom.xml
> 
> Reason: Not a v4.0.0 POM. for project unknown at /Users/sanju/citytime/pom.xml
> 
> 
> [INFO] 
> 
> [INFO] Trace
> org.apache.maven.reactor.MavenExecutionException: Not a v4.0.0 POM. for 
> project unknown at /Users/sanju/citytime/pom.xml
>   at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:376)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:289)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:597)
>   at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>   at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
>   at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
>   at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.project.InvalidProjectModelException: Not a 
> v4.0.0 POM. for project unknown at /Users/sanju/citytime/pom.xml
>   at 
> org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1405)
>   at 
> org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1377)
>   at 
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:474)
>   at 
> org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:197)
>   at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:548)
>   at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:458)
>   at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:362)
>   ... 11 more
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 


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

Re: Multimodule distribution

[Brian Topping]

This isn't a Maven thing, but we usually name all our component configuration 
files the same name in the respective jars.  Spring has a means to find all the 
files of the same name in the different jars (you can go check it out there, 
they use the "classpath*:" nomenclature for it).  That way, our component 
loader just asks for "classpath*:/lib/component.xml" or some such and gets back 
all the configs for components, regardless of how many there are, avoiding gaps 
in naming created over time by deprecated components and component names.

The part that *is* a Maven thing with this process is you don't need any 
complicated assembly config to get the component names worked out in a certain 
way.  

Hope that helps, B

On Jul 10, 2011, at 11:47 PM, Ivan wrote:

> Hello, guys! 
> We have a project consisting of a main module (we call it core) and several
> configurable plugin modules (we call it component). By the application
> design each module is highly customizable and depends on one or more
> configuration files. When the application starts the "conf" folder is
> scanned and application configuration is constructed from all conf-files
> located in that folder. Depending on the usage scenario several combinations
> of configuration files may be used
> 
> The basic aim we want to achieve is:
> 1) Have all possible configuration files stored in some folder of a module,
> e.g. for component A we have Aconf1.xml, Aconf2.xml and for component B
> Bconf1.xml and Bconf2.xml
> 2) For each target usage scenario we want to predefine a set of
> configuration files in a pom file that will build a distribution. E.g. for
> Scenario1 we should use Aconf1.xml and Bconf2.xml, but for Scenario2 we
> should use Aconf2.xml and Bconf1.xml
> 3) The resulting layout should look like ./lib - all *.jar files (core and
> components used) and ./conf - subset of configuration files specified in a
> distribution pom file.
> 
> Can you suggest how this goal can be achieved with maven and distribution or
> assembly plugin?
> 
> --
> View this message in context: 
> http://maven.40175.n5.nabble.com/Multimodule-distribution-tp4574067p4574067.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 


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

Re: Using Maven for large-scale deployment

[Brian Topping]

Thanks Stephen, these are good leads.  I had seen both of these projects some 
time in the past, but hadn't strongly considered them.

A primary concern is reusing existing maven plugins.  Ship seems focused on 
general script execution, no?  I'm still left with getting a groovy script to 
execute a maven plugin.  Due to differences in component resolution between 
plugins, maven itself is likely to be the only reliable container for a plugin 
to run within.

The concept of invoker reminds me of a blog entry I read somewhere where an 
"n+1" project is used to distribute all the software.  But unfortunately, that 
project would have to be tuned every time a new project is added. 

Still searching...

Cheers, Brian

On Jun 25, 2011, at 12:09 AM, Stephen Connolly wrote:

> 1. have a look at the ship-maven-plugin (i wrote it, but i think it has some
> good ideas for continuous delivery as well as delivery in general... i call
> it ship to have a different term from deploy so as not to confuse the maven
> lifecycle)
> 
> 2. you might have some luck with, eg the maven-invoker-plugin, or at least
> use maven-invoker from your own plugin...
> 
> - Stephen
> 
> ---
> Sent from my Android phone, so random spelling mistakes, random nonsense
> words and other nonsense are a direct result of using swype to type on the
> screen
> On 25 Jun 2011 07:57, "Brian Topping"  wrote:
>> Hi all,
>> 
>> I'm picking up a project that requires a configurable large scale
> deployment, something on the order of five concurrent development branches
> of HEAD, each with about five servers that the various projects in a branch
> will need to deploy to. Ideally, everything will be contained in the Maven
> build such that CI could deploy automatically and individuals with a
> sufficiently robust settings.xml could deploy manually from a Maven
> invocation.
>> 
>> The servers that are being deployed to will require a mix of different
> deployment strategies (one per packaging) and more than one artifact will
> need to be deployed to each server over the course of a reactor build.
> Closed-source m2 plugins have been developed for each of these package types
> and are provided by the target container vendor. Each plugin is basically a
> REST client that wouldn't be hard to rewrite, but it would be advantageous
> to use the vendor's plugins.
>> 
>> Having read
> http://docs.codehaus.org/display/MAVEN/Dynamic+POM+Build+Sections, I set off
> with the plan that executions might be added to a running build by a plugin
> in the initialize phase. For instance, if an artifact A needed to be
> deployed using plugin X to five separate machines for a branch, X would not
> be statically configured in the POM with five separate executions (which get
> transformed into entries in the goal queue), rather some plugin would be
> developed to insert the five new goals at the right place in the goal queue
> dynamically.
>> 
>> But it turns out that m2 pre-generates the list of goals before the first
> plugin runs, and in any case are not accessible from the mojo context, so
> this appears to be impossible. I haven't had a chance to check if this is
> still true in m3.
>> 
>> I took a look at Cargo, and it would probably work if Deployer
> implementations were developed, but again, local requirements strongly
> prefer using the vendor's m2 plugins, and Cargo doesn't have a means to wrap
> an m2 plugin in a Cargo Deployer for pretty obvious reasons.
>> 
>> I can easily see that plugins could be configured in a parent build and
> executions statically defined, one per target machine in each build that
> needs a particular kind of deployment. This creates a lot of configuration
> volume though, something I was hoping to avoid by creating named groups for
> the servers and possibly storing them in LDAP. This is especially important
> in the production cluster, where there are about 100 servers, and the
> expansion of the POMs for all these servers would not be well-received
> (merging the branches to HEAD prior to a release would be very tricky for
> the POMs, besides just being unwieldy).
>> 
>> It may be that I am missing something obvious, or it may be that Maven
> isn't ideal for this job. Can anyone who's tried this before share their
> thoughts on it?
>> 
>> Kind regards, Brian
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 


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

Using Maven for large-scale deployment

[Brian Topping]

Hi all,

I'm picking up a project that requires a configurable large scale deployment, 
something on the order of five concurrent development branches of HEAD, each 
with about five servers that the various projects in a branch will need to 
deploy to.  Ideally, everything will be contained in the Maven build such that 
CI could deploy automatically and individuals with a sufficiently robust 
settings.xml could deploy manually from a Maven invocation.

The servers that are being deployed to will require a mix of different 
deployment strategies (one per packaging) and more than one artifact will need 
to be deployed to each server over the course of a reactor build.  
Closed-source m2 plugins have been developed for each of these package types 
and are provided by the target container vendor.  Each plugin is basically a 
REST client that wouldn't be hard to rewrite, but it would be advantageous to 
use the vendor's plugins.

Having read http://docs.codehaus.org/display/MAVEN/Dynamic+POM+Build+Sections, 
I set off with the plan that executions might be added to a running build by a 
plugin in the initialize phase.  For instance, if an artifact A needed to be 
deployed using plugin X to five separate machines for a branch, X would not be 
statically configured in the POM with five separate executions (which get 
transformed into entries in the goal queue), rather some plugin would be 
developed to insert the five new goals at the right place in the goal queue 
dynamically.

But it turns out that m2 pre-generates the list of goals before the first 
plugin runs, and in any case are not accessible from the mojo context, so this 
appears to be impossible.  I haven't had a chance to check if this is still 
true in m3.

I took a look at Cargo, and it would probably work if Deployer implementations 
were developed, but again, local requirements strongly prefer using the 
vendor's m2 plugins, and Cargo doesn't have a means to wrap an m2 plugin in a 
Cargo Deployer for pretty obvious reasons.

I can easily see that plugins could be configured in a parent build and 
executions statically defined, one per target machine in each build that needs 
a particular kind of deployment. This creates a lot of configuration volume 
though, something I was hoping to avoid by creating named groups for the 
servers and possibly storing them in LDAP.  This is especially important in the 
production cluster, where there are about 100 servers, and the expansion of the 
POMs for all these servers would not be well-received (merging the branches to 
HEAD prior to a release would be very tricky for the POMs, besides just being 
unwieldy).

It may be that I am missing something obvious, or it may be that Maven isn't 
ideal for this job.  Can anyone who's tried this before share their thoughts on 
it?

Kind regards, Brian
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: How to define local repository path in settings.xml or pom.xml?

[Brian Topping]

On May 21, 2011, at 10:41 PM, Ron Wheeler wrote:

> On 20/05/2011 9:06 PM, Petr V. wrote:
>> Thanks Brian for your reply.
>> 
>> Our developers work on several projects at same time using same machine. 
>> What we want is that when they build the particular project then every thing 
>> related to project goes to its own build directory (lot of output other than 
>> jars) instead of putting every thing in central m2 location.
> I think that Brian is asking "Why do you want to do this?"

Yes, that approximates what I was asking pretty well.  :-)

Petr, the only time I've ever had a mind to intentionally manipulate my 
repository is when I want to make sure that a new build that I am committing 
does not have any missing dependencies.  In other words, a build might work on 
my machine, but not on another machine because of a missing dependency.

The path to that happening is (for instance) if I have built a version of an 
artifact from source with 'mvn install', but that version does not exist in a 
remote repository that the build is configured to look in.  If someone else 
were to try this new build without a copy of my local repository, their build 
will fail.  

Note that this is the correct behavior!  

So by moving my repository aside and doing a build ("mv ~/.m2/respository /tmp; 
mvn clean install"), I am forcing my machine to grab every dependency (direct 
or transitive) and fail if one of those dependencies does not exist in a 
configured remote repository.  When it succeeds, I usually move my old 
repository back ("rm -rf ~.m2/repository; mv /tmp/repository ~/.m2") because 
the old one has a lot of dependencies from other projects that I work on but 
don't want to download again.

Also note that I am not saying "public repository" instead of "remote 
repository".  Some of the aforementioned dependencies that will be missing by 
some people may be dependencies that they do not have source for, but are not 
public dependencies either.  Hypothetically, if my company has super sekrit 
algorithms that we don't want the source floating around for, we might only 
provide binaries to most developers.  These binaries come from a *private 
remote repository* such as Nexus (but could just be a writable WebDAV 
directory) that lives *inside the firewall*.  There are tens or hundreds of 
thousands of these private repositories in use around the world.

If I were to guess where you and Srinath might be having problems, it's because 
you aren't running a private repository for your company's artifacts like this. 
 When I do a 'mvn install', my build only goes to my local repository, which 
limits any brain-damaged code to my local machine.  I do this over and over 
until it's ready to share, and when it's ready, I do a 'mvn deploy' to share 
it.  For smaller companies with no QA resources, everyone might have the 
credentials to deploy to a private repository, but they don't do so until they 
have really done their homework and are sure the artifacts are ready for their 
teammates to use.  

The other thing that might be happening is you aren't using the release plugin. 
 Teams of people need to make releases when milestones are released.  For a 
small company, a great milestone is "I want to push this software out to 
customers".  I never let snapshot builds reach a customer.  Never never never!  
But if all a team creates is 1.0-SNAPSHOT versions, there's never any way to 
find those milestones over time.  This would be a reason to have multiple 
copies of a repository, but completely unnecessary if a single repository is 
properly creating distinct releases in a single repository.

Versions are so important that I bake the version string into every build, for 
instance into an admin screen.  Bugs get filed against that version string, and 
if there's no version in a bug, we assume it cannot be reproduced without 
wasting time checking every version, so we reject it.  

I apologize for all the text, but maybe this helps you and Srinath see some 
things you aren't doing.  Please continue to ask questions until you get your 
questions resolved!  If we can help you, you'll eventually help others!  

Cheers, Brian
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: How to define local repository path in settings.xml or pom.xml?

[Brian Topping]

Can you describe more about what you are specifically trying to accomplish?  
Maybe the list can help better that way.

In general, the location of the repository should not matter.  One of the 
beautiful things about Maven is it manages the location per machine 
automatically.  There's no need to put it in the same place for all developers, 
which breaks for Windows v. *nix.  And your builds plugins should not require a 
fixed location for the repository, rather, it should be resolved from the 
context sent by Maven itself. 

On May 20, 2011, at 4:35 PM, Petr V. wrote:

> I have figured out the way to use {env.CODE_BASE} but for that each user will 
> have to change their settings.xml. 
> 
> Is there a way, I can define localRepository in project pom file instead of 
> settings.xml so that user does not have to define environment variable and 
> edit their settings.xml.
> 
> Thanks,  
>  
> 
> 
> --- On Sat, 5/21/11, Petr V.  wrote:
> 
> From: Petr V. 
> Subject: How to define local repository path in settings.xml or pom.xml?
> To: "Maven Users List" 
> Date: Saturday, May 21, 2011, 2:26 AM
> 
> I am trying to define local repository path in settings.xml on Windows.
> 
> I have a windows environment variable CODE_BASE=C:\mycode
> 
> In settings.xml , I put
> 
> ${env.CODE_BASE}\build\local_depot
> 
> But it does not read environment variable. How can I read environment 
> variable in settings.xml.
> 
> If that's not a possibility, can I define local repository in pom.xml of 
> project?
> 
> Your help will be much appreciated.
> 
> Thanks,
> 
> 
> 
> 
> 


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

Re: Why does dependency:tree not show what's inside wars?

[Brian Topping]

Are you running dependency:tree from a top-level build that includes both other 
builds via a parent POM?  That's what I do, reactor does the right thing and 
dumps all the builds it finds.

Personally, I believe this is the correct behavior, I wouldn't want a reactor 
dump of such a build to analyze the WAR build twice.

$0.02...

On May 17, 2011, at 7:52 AM, Evert Hoff wrote:

> If I run a "mvn dependency:tree" on a module with EAR packaging, I see the 
> WARs that are included in the EAR, but not what's inside each WAR. With JAR 
> dependencies I can always see the full dependency tree, but not with WARs. 
> Why is this?
> 
> Some of these WARs do contain JARs.
> 
> If I run the dependency:tree on the module that creates the WAR then I can 
> see what's inside the WAR, but not if I run it on the EAR module.
> 
> It would be useful to be able to run a dependency tree on my top module and 
> see all the way to the bottom all the dependencies that are included.
> 
> Evert


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

Re: Generating Config Files for multi-module project

[Brian Topping]

It sounds like you are mostly stuck on the config files issue so I'll focus on 
that.  Ron already answered this, but I had this typed and didn't send it for 
some reason.  I'm basically repeating what he's already said.

I would organize the config files into a separate top-level project, then have 
these other projects depend on it.  The output of this project will be your 
config files as a jar, but I would suggest not worrying about that in the 
config file build.  The m2 repo needs to have a single artifact per build, and 
it does not make sense to have one build per config file, if you see what I 
mean.

So what you would do here is use the assembly plugin to extract the config 
files you need from the config file artifact jar for each specific product 
scenario.  If there are separate POMs for each product scenario, you could copy 
the plugin to each module with a separate  element for the file 
selection used by that specific product.  

Or you could put the assembly plugin in a parent build one time, but have it 
rely on  elements in the child build.  In this manner, product 
scenarios share a common POM with the single assembly plugin, but each child 
POM has the specific config files listed.

There's probably other ways to accomplish this, but that's the path I would go 
if I were doing it.

Brian

On Mar 26, 2011, at 12:15 PM, Adam Retter wrote:

> Hi there,
> 
> I am trying to migrate a complex Ant setup to Maven and need some help
> about how we can share our config files.
> 
> I have a series of Maven project modules that make up the Jar files
> for my project. I also need to produce several end product scenarios -
> 
> 1) A WAR file for users to deploy in Tomcat etc.
> 2) A IzPack installer distribution (I have seen the IzPack plugin).
> 3) Several Zip file distributions, various combinations of the output
> of my maven modules.
> 
> I understand that I can create a Maven module to produce each of
> these, and that is indeed my intention.
> 
> However, I have some common config files etc that I need to
> incorporate into each of these final product scenarios.
> So my question is, where can I keep these config files???
> 
> I would like to have one atomic version of them, that can be reused by
> each scenario, some sort of dependency. To complicate things -
> 1) These config files typically are generated from template XML files
> using XSLT, with some parameters injected into the XSLT depending on
> the scenario.
> 2) These config files need to be easily modified by our end-users, who
> use our product scenarios, so packaging them into Jar files is a not a
> good idea.
> 
> Thanks Adam.
> 
> 
> 
> -- 
> Adam Retter
> 
> skype: adam.retter
> tweet: adamretter
> http://www.adamretter.org.uk
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 


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

Re: Using profiles to control execution of a maven build (conditional execution)

[Brian Topping]

You might want to look in the list archives, there was a discussion in which I 
learned a lot from others on the list about the pros and cons of using profiles 
versus using separate (nearly identical) POMs.  My takeaway was that if one 
just jumps on profiles as the solution to every conditional situation, the 
build will grow a second head like a hydra in a bad horror flick and you'll 
really regret it.

The point is that profiles are often an expedient substitute for using Maven 
correctly.  They should always be considered "last resort" unless you know what 
you are getting yourself into.  

In my situation, I wanted to have a whole subtree of sources compiled if they 
were there, otherwise fetched from Nexus if needed.  Profiles work great for 
that, but I can see exactly where the hydra head fits on the beast now and 
don't intend on doing anything more with them unless absolutely necessary.

$0.02... 


On Jan 13, 2011, at 5:10 PM, Dean Schulze wrote:

> 
>I need to modify the maven build for a large project 
> to skip certain steps during typical development builds (i.e. don't 
> build the *-source.jar files).  I've searched for "conditional 
> execution" for maven, but haven't found anything.
> 
> A dev profile sounds like the intuitive way to do this - but I don't 
> know how intuitive maven is.  The docs for profiles show how to set 
> different properties (i.e. database connection parameters) for different
> profiles.  I suppose I could set a property and then test if that 
> property is set in the maven-source-plugin - executions - execution tag.
> 
> Is this the right way to do conditional execution in maven?
> 
> What's the "right" way to do this in maven?
> 
> Thanks.
> 
> 
> 
> 


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

Re: Reasonable use of profiles?

[Brian Topping]

These replies have been incredibly helpful, thanks especially to Ron and 
Stephen for your investment in them!

Very accidentally, I have fallen into the "MV-SOA" pattern.  I am using Mule 
for the services container with the VM connector for speed and ease of 
iterative development, knowing that I can trade out the connector once the site 
scales into the datacenter and needs it.

At the webapp level, what I've done is focus all command dispatches to a small 
class that either a) knows how to reach Mule or b) returns some mock objects.  
I've found developers who are good with both backend architecture and user 
interfaces are very rare.  In "agile" environments, UI folks often are at the 
front line of working with business stakeholders though, and if they can't see 
the results of their work without also wiring the backend, they are quickly 
stuck.  In small team situations, stakeholders respond to this by insisting 
that the architect is smoking something bad and being given an ultimatum to get 
the UI folks productive again or be replaced.

As a response to this, I've found that making the command messages to the SOA 
core as a separate shared project between these realms as step one.  Next, the 
web build is set up with a default implementation of the dispatcher that 
returns these command messages with mocked results.  Practically, this is 
managed as a named Spring bean.  

Things change when a developer includes a single library that has the alternate 
implementation of the command dispatcher.  When this library is loaded, it's 
alternate definition of the dispatcher overrides the mock dispatcher and is 
injected into the webapp accordingly.  Now, when commands are dispatched, they 
transparently go to the SOA core instead of returning mocks.  This could also 
be done with JNDI registrations and solves the same problem.

This works at an organizational level because UI devs can create mock 
implementations in their own sandbox, then throw them over the fence to the 
core developers with very little documentation.  A picture speaks a thousand 
words. 

All these artifacts are automatically deployed to Nexus by CI with sources 
after every checkin, so a developer that needs to trace source in the 
complimentary project need not have privileges on both projects.  More 
restrictive environments are obviously possible.  Along with Nexus, my svn repo 
is also slaved to LDAP, so authorization is easy to manage.

One of the last things to note here:  Spring or JNDI is not necessary for 
smaller projects, just use the classpath, whose namespace is naturally the sum 
of all loaded artifacts.  If a build includes a new artifact and that artifact 
includes additional configuration, use it.  Using the same name for the 
configuration file in all artifacts helps here, when doing a getResources() for 
a single filename, you'll be given a list of all classpath files that exist 
across your various jars.

Brian


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

Re: Reasonable use of profiles?

[Brian Topping]

On Dec 11, 2010, at 3:59 AM, Stephen Connolly wrote:

> My issue with using orofiles for adding modules is that you can end up with
> version numbers out of sync of course that's why I created
> versions-maven-plugin, but that is just a band-aid.

Is this because the release plugin doesn't see some modules when doing a 
release on a module subset or am I missing something else?  

Initially, I didn't imagine someone doing a release on a profile that contained 
less than a full set of modules, but see the error in that logic now (it would 
appear to be a very clean way to release a subset of functionality), and as I 
put this together with the functionality in the versions-maven-plugin, can 
better imagine the kinds of builds you are working with.

> Using profiles to pull in modules can just as easily result in broken
> builds... what I ended up doing is using profiles to turn off the system
> specific parts of a build when on a system without those system specific
> components (e.g. missing flashplayer, rpmbuild), but also to fail a release
> if the system specific components are missing.

So are you also of the camp that having multiple "developer POMs" is the best 
practical solution?  

It seems like these approaches are essential for projects that have grown to 
the size of the death star, and what I am asking myself now is whether there is 
a breakeven to starting a project with the "wrong" patterns (saving time during 
early agile development due to things like IDE integration) versus avoiding 
profiles wherever possible from the start and skipping the pit stop to migrate 
everything down the road.  In other words, are these "good problems to have" 
(the company and it's IP got out of the incubator and now this as a problem) 
versus solving them too early being counterproductive to getting smaller 
projects off the ground.

Thanks, Brian
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Reasonable use of profiles?

[Brian Topping]

On Dec 10, 2010, at 10:03 PM, Ron Wheeler wrote:

> On 10/12/2010 9:19 PM, Bryan Loofbourrow wrote:
 What is the semantic difference between multiple POMs and a single POM 
 containing the different module lists in profiles?  It seems like the 
 former is harder to support because a change outside the module sets 
 requires changing every POM.<<
>> Well, one difference is a separation of developer concerns from the concerns 
>> of the consumers of your artifacts. This is especially applicable if the pom 
>> containing the profiles is the parent pom of your project, that actually 
>> gets deployed to a repository and consumed by those who consume your 
>> software.
>> 
>> More subtly, I'd argue that the profiles are "magic beans," things for which 
>> you have to introspect your source code to know what's going on, and not 
>> really knowing, without extensive examination, whether these profiles have 
>> any effect on any of the projects in the child tree. In contrast, a 
>> developer-facing pom is a distinct file whose purpose can be made quite 
>> clear at the file system level, and whose purpose is unambiguously contained 
>> entirely within the file itself.
>> 
>> Descending down to the final level of abstract mysticism, I'd also say that 
>> the profiles represent a "last resort" in the context of "The Maven Way," a 
>> thing you do not use unless you must. Yes, we use them -- for things like 
>> telling the build to execute integration tests that depend on the presence 
>> of an active database whose location you have defined in a settings.xml 
>> file. But for a trivial purpose like this, they are overkill.
>> 
> +1.

I see where you are coming from here and can see how that would be attractive 
in one perspective.

For the benefit of the original poster (I assume you guys know this already), 
module elements are purely metadata for the reactor in the form of a closure of 
all the projects that should be built, and don't have anything to do with 
module dependencies once installed/deployed.  As long as dependency elements 
are not inside profiles, the dependency tree is static, and the process of 
installing to the local repository "flattens" the tree, converting the 
hierarchical file directory tree to a directed graph that rarely has any 
resemblance whatsoever to the original project directory tree.  [1] details 
this with helpful pictures.

Once that's done, whether or not profiles are used to expand or contract a 
module selection, what starts as an empty repository is only going to have a 
larger or smaller set of artifacts in it in either case (via multiple POMs or 
profile-based selection of modules to be built).  

One of the things that I would feel is hard to support with multiple POMs (at 
least in IDEA) is how to deal with making the selection of what artifacts to 
build.  It's easy at the top level, I just import one POM instead of the other. 
 But what about when there are multiple child POMs that need to make 
selections, or there are are permutations?  In IDEA, four distinct profile 
names can provide up to fifteen compositional permutations with one POM per 
project.  Getting fifteen builds with separate POMs implies I have fifteen POMs 
at the root, and some diminishing number > 1 at most child levels.  I realize 
this is a degenerate case, but everything in between is just a matter of 
degrees.  By overloading the profile ID namespace, I can do this with one POM 
per project in all cases.

The other thing that bothers me about multiple POMs is keeping them in sync.  
In IDEA, if an import is not on the classpath, an inspector speedmenu will ask 
me if I want to add a dependency to my POM.  But if IDEA only knows about one 
POM, there are others that I have to update manually, and I might forget about 
them or not know about them.  This leads to broken builds that might not be 
hard to fix, but I'll venture that it's more work to keep all the permutations 
happy that way than to learn the profiles, keep their use limited, and maintain 
a single set of POMs.

It seems like there is complexity either way.  I agree that profiles can be a 
bit like C++ multiple inheritance and it's easy to abuse them and end up with a 
train wreck, but I've also seen some impossibly elegant designs with multiple 
inheritance as well, and the same is true for this kind of use of profiles.  In 
the end, either technique has pros and cons.  Makes for a good horse race... :-)

Brian

[1] 
http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-best-practice.html#pom-relationships-sect-multi-vs-inherit


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

Re: Reasonable use of profiles?

[Brian Topping]

On Dec 10, 2010, at 8:08 PM, Bryan Loofbourrow wrote:

> You don't need separate projects for this. You just need a bunch of 
> developer-facing pom files with different  lists. They can certainly 
> live in the same directory. This is something we definitely take advantage 
> of, for producing interesting developer build sets.

What is the semantic difference between multiple POMs and a single POM 
containing the different module lists in profiles?  It seems like the former is 
harder to support because a change outside the module sets requires changing 
every POM.



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

Re: Reasonable use of profiles?

[Brian Topping]

On Dec 10, 2010, at 1:30 PM, KARR, DAVID (ATTSI) wrote:

> Interesting.  This could go into the "build" project POM, but if a
> developer needed a custom list of modules, they could define that in
> their settings.xml.  I guess that could work for what I'm looking for.


It's not possible to put the  element in settings.xml, if that's what 
you are thinking.  But given that you can specify multiple profiles for a build 
and individual profile IDs can be used in multiple projects, you might consider 
making a different profile ID for each root component that made sense to be 
selectable.  IntelliJ lets developers persistently select profiles for a 
project, so it would not be hard to do an a la carte like this without using 
settings.xml.

I am in the midst of getting Nexus and SVN to play nice from LDAP, so developer 
access can be granted or revoked from a UI as a part of their master access 
profile.  Nexus privileges can also be set up for "everything but source jars", 
so CI can publish source to Nexus but not everyone can get it.

Nexus isn't hard to set up like this, but getting SVN to work through Atlassian 
Crowd for fine-grained repository access still needs a little work it seems.  
Definitely experiment with this dummy projects before jumping in though, SVN 
authz is not a trivial setup to deploy, get it working and confirm that there 
aren't leaks.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Reasonable use of profiles?

[Brian Topping]

I'd second the very good points that Kalle made.  To add some practical 
experience from this end, I just last night learned the power of using the 
 element within a  element...

> 
> 
> all
> 
> web
> core
> messaging
> security
> 
> 
> 
> web
> 
> web
> messaging
> security
> 
> 
> 
> core
> 
> core
> messaging
> security
> 
> 
> 

I use Spring for the IoC container on my projects, and in an optional project 
for core, have a stubbed command bean that is defined once in the web project, 
then with a full implementation again in the core project, but with the 
"primary" attribute on the bean definition set to true.  This transparently 
overrides the central command message interface with a real implementation, 
connecting the two projects together at runtime.  

The messaging and security projects are obviously needed by either project, 
whether they run separately or together.  The messaging project contains the 
message classes that are sent to the stub or the core depending on what gets 
loaded, and the core project accepts those messages, thus creating a dependency 
from both.

Brian


On Dec 10, 2010, at 12:57 PM, Kalle Korhonen wrote:

> On Fri, Dec 10, 2010 at 9:20 AM, KARR, DAVID (ATTSI)  wrote:
>> Another desire I have is to allow for developers not even building most
>> of the modules, and just letting the "ear" project pull snapshot
>> artifacts from the Nexus repo (built by the release team or continuous
>> integration).  I could do this with multiple "build" projects, including
>> different sets of "module" elements.  That seems messy, however.  I wish
>> I had different options for setting that up, perhaps in a profile, but I
>> don't see how that could work.
> 
> Overall, I'd say this sounds better than trying to (mis-)use profiles.
> Nothing you said indicates to me that the EARs are functionally
> equivalent, and therefore I'd create different modules for different
> EARs. One of the Maven ground rules is one artifact per module.
> Typically you deviate from that plan only if you need to build
> different versions of the same module (packaged differently, for
> different OSes/JVMs etc.) and often you use profiles for the desired
> effect. I'd further say using profiles should never be your first
> option. Reserve profiles for the time you really need them.
> 
> Since you are going to re-work the build, I'd mercilessly refactor it
> into a modular build now. Since Maven is so good at versioning things,
> your build doesn't have to be monolithic. Snapshots are ok, but it's
> far better if you can identify common, stable areas of the codebase
> and simply release them separately. Then your top-level builds are
> mostly assembling things together rather than compiling/building them.
> Personally, I'd put my efforts on making the build modular, automating
> version migration and doing more continuous integration & testing
> rather than trying to force Maven the same logic as your Ant build.
> Depending on the size of the project and your team, it would likely be
> beneficial to pay somebody who really knows Maven to assist you in the
> migration at this point (if you can get it approved, I know how it
> is). It would save you from a lot of grief later.
> 
> Kalle
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 


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

Re: maven-eclipse-plugin

[Brian Topping]

On a related note, can anyone summarize what the best way of maintaining 
eclipse projects from Maven is?  I use IDEA, and the best way from there is 
IDEA itself, not with the IDEA plugin for Maven.  

Is the same true for Eclipse that the IDE plugin for Maven is better than the 
Maven plugin for the IDE?  If so, what is the best plugin for Eclipse (there 
seems to be more than one).

Thanks, Brian

On Dec 5, 2010, at 6:41 PM, Barrie Treloar wrote:

> On Mon, Dec 6, 2010 at 12:51 AM, Asmann, Roland  
> wrote:
>> Hi all,
>> 
>> Does anybody know in which version the support for wtp 2.x was added?
> 
> Not really, you'd have to trawl through the code base to see for sure.
> http://maven.apache.org/plugins/maven-eclipse-plugin/wtp.html lists
> the versions available
> 
>> And when will support for wtp 3.x be added?
> 
> There is no active development for adding wtp 3.x support.
> Feel free to create a jira, integration tests and patches.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 


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

Re: Catch 22 with clean phase

[Brian Topping]

On Dec 2, 2010, at 7:05 PM, Wayne Fay wrote:

>> Ok, so this is working great now, except for one problem.  It runs
>> great the first time, but if I run "mvn clean" a second time, the
>> batch file is not there so it can't call it and it returns with an
>> error.
> 
> Turn your batch file into a plugin and these problems will magically go away.

I have to agree here.  Creating a plugin is easy, and we will refund your 
purchase price of Maven if you do not find the Plugin interface to be the 
easiest one you've ever seen.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Catch 22 with clean phase

[Brian Topping]

There is a pre-clean, see 
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference

On Dec 2, 2010, at 3:08 PM, Phillip Hellewell wrote:

> There's a batch file I want to run during the clean phase.  Problem
> is, the batch file lives below target/dependency, and the clean phase
> wipes "target" first, so then my batch file can't be found.
> 
> Is there a good solution to this?  Like a pre-clean phase or something?
> 
> The only other ideas I've come up with are:
> 1. Move the functionality of the batch file into a plugin.
> 2. Copy the batch file from target/dependency to the base directory
> (where the pom.xml is) during process-sources after the unpack.
> 
> The downside of #1 is that a plugin is really overkill for what this
> batch file does.
> The downside of #2 is that I have yet another file cluttering up the
> base directory (though of course it will be svn:ignored).
> 
> Phillip
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 


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

Re: Issue if colon in project path

[Brian Topping]

For one thing, using a colon in a filename on OSX is bound to lead to problems 
in a lot of different applications.  That is the directory separator for MFS 
and HFS volumes, and while HFS+ and has deprecated use of colon, I believe it 
is still supported in strange ways. 

On Nov 26, 2010, at 3:49 PM, Siegmar Alber wrote:

> Hi all,
> 
> is it only my setup or is there a problem if there is a colon in the project 
> path? I attached a small sample project. (I hope it's allowed to attach 
> files...)
> 
> I'm using Maven 3 and tried it on Mac OS X (10.6.5) and on Ubuntu Linux.
> 
> To reproduce the problem:
> 1. Untar the attached project somewhere.
> 2. Try "mvn test".
> 3. Everything works like expected.
> 4. Do "mvn clean".
> 5. Rename some parent directory (or the project directory itself) to 
> something containing a colon (for example from "colon_issue" to 
> "colon:issue").
> 6. Retry "mvn test".
> 7. It shows a compilation error and, of course, gives you a build failure.
> 
> The error message looks something like this:
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:2.3.2:testCompile 
> (default-testCompile) on project colon_issue: Compilation failure
> [ERROR] issue/src/test/java/org/example/colon_issue/FooTest.java:[11,30] 
> cannot find symbol
> [ERROR] symbol  : class Foo
> [ERROR] location: class org.example.colon_issue.FooTest
> 
> Looks like it splits the path to the main classes at the colon and 
> consequently can't compile the test sources...
> 
> Should I report this as a bug?
> 
> -- 
> Thank you and have fun,
> Siegmar
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org


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

Re: Whatever happened to j2ee-1.4.jar ?

[Brian Topping]

On Nov 10, 2010, at 9:58 PM, Simon Lewis wrote:

> What's up with  http://repo2.maven.org/maven2/javax/j2ee/j2ee/1.4/

You need to download it directly from the JavaEE site and install it with the 
instructions that you find in the build log.  License issues, it can't be 
distributed through the central repo.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Figuring out the proper Maven dependency setting

[Brian Topping]

On Nov 10, 2010, at 4:20 PM, Ron Wheeler wrote:

> It is mostly exclusions to stop old versions of libraries from being dragged 
> in by mistake.
> It took a bit of doing to get these the first time but it is nice now that we 
> do not have a screen full of conflicting version notes.

So I guess you are then having to manually import the dependencies that you are 
excluding?  That is seriously painful. 

It seems to follow that you would also want to set exclusions on all the 
excluded dependencies that you manually import, right?  I mean, there's no 
telling that you might get a version of a transitive dependency somewhere that 
has two versions!  :-)

At that point, I don't know why you would bother with Maven at all.  The effort 
required to disable all the dependency functionality (one dependency at a time) 
is so much more painful than using it well.

I'm not trying to be mean here, just trying to illustrate how the situation 
degenerates.  

Have you tried not using exclusions at all, then using dependency:tree to debug 
conflicts?  Classpath conflicts where there are two versions of the same jar 
are usually pretty easy to spot, and when they happen, they make such a big 
mess of everything that it's hard to miss.  But dependency:tree will show you 
one or two root causes of the problem, then you can put in a single exclusion 
on the precise jar that is causing the problem.  Problem solved, and you still 
get updates to transitives like God intended.



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

Re: Figuring out the proper Maven dependency setting

[Brian Topping]

On Nov 10, 2010, at 4:06 PM, Yanko, Curtis wrote:

> I have used the technique described here but I have also had too to
> forensic type package level comparisons to try an find matches.
> Eventually slugging our way through namespace collisions and knocking
> down issues one Classpath Not Found at a time.

The directory entries in a Zip archive are not compressed.  This makes class 
names searchable with 'grep -R' on the local repository.  If you download and 
compile a lot of OSS projects that use Maven, chances are your repository has 
most of the dependencies you would normally want to use already in it.  

Alternately, to speed inquiries on jar contents, I use 
http://mvnrepository.com.  Once one drills down to the page for a specific 
version of a dependency, the package structure of the contents is displayed.  
It's a lot easier than constantly doing 'jar tvf ' to see what's in 
there, and there's a bunch of additional information about the dependency on 
that page too.  It only works for jars in the central repo though, and sadly, 
there are a few things that could be made a lot nicer, but the authors have a 
full email box and apparently do not want to be bothered.



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

Re: Figuring out the proper Maven dependency setting

[Brian Topping]

On Nov 10, 2010, at 3:40 PM, marshall wrote:

> Hi;
>  This is probably a beginner question, but I thought it was worth posing 
> because it is frequently very frustrating when working with Maven.
>  Is there a clear way to know which particular dependencies Maven requires, 
> when working with a set of jars/libraries?

This isn't as much a Maven question as it is a question on the organizations 
that package the dependencies, but here's some info.  Dependencies typically 
depend on other dependencies, and one eventually gets a transitive closure of 
dependencies.  You can see this in your build by running 'mvn dependency:tree'. 
This will show you a tree of who is pulling in what, and help make decisions on 
what to pull in at the top level and what you can ignore.

For instance, if you used to pull in asm for use with Hibernate, you can stop 
doing that, because the Hibernate dependency you choose will know better what 
exact version it was compiled at.  If you need a specific version of asm for 
your own needs, this is where things get more complicated.

These problems existed before Maven though.  Maven just gives you a bigger, 
more efficient gun to shoot yourself in the foot with.

Hope that helps...


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

Re: Continuous Delivery and Maven

[Brian Topping]

On Nov 8, 2010, at 2:27 PM, Yanko, Curtis wrote:

> 
> To be clear, I'm not advocating time stamped artifacts simply indulging
> them for now to try and solve a problem that imo doesn't exist except as
> a thought experiment.

Yup, feel the same way.

> I agree with your assessment of a Maven Repo and that's why we have a
> build manager to go with it. It keeps records of build meta-data.
> 
> Sure, A doesn't have the meta-data for B & C but they do and they all
> got put together at some point (we are integrating no?). The build
> management system also keeps all of the logs and manages them
> intelligently based on how for they got promoted in the life cycle. So
> pretty optimal in my opinion since I do want to pass an audit. The BMS
> also keeps all of the meta-data in it's db and while that is not
> *indefinitely*, it's very long when compared to release cycles (driven
> more by compliance and legal).

Also fair.  But if were talking about "generalized solutions" instead of 
"localized means of coping", it's a bit of a different problem space.  Agreed 
that the BMS as a whole should not be losing it's cache so often that one needs 
to look at the logs very often, if ever.   I'm just making the point that if a 
solution is going to adhere to standards set by it's dependent subsystems, it 
ought to solve the problem within those constraints or make it an explicit 
non-requirement.  Sometimes searching logs is the only way to solve a database 
corruption or loss issue, but it's a disaster recovery response, not 
business-as-usual.

> Keeping the SCC info in the manifest provides excellent traceability. I
> don't care that Maven can't use it, I can.

The adage from the world of disaster recovery can be summed up as "it doesn't 
matter if your data is backed up, it matters if someone else can restore it".  

DR situations usually arise when someone needed the archives ten minutes ago 
and found them corrupted.  I was never an advocate of foolproof DR tools until 
I had to wear the hat of a recovery guy with a half-dozen frustrated users 
crawling all over me because someone set up a system that wasn't built to be 
restored.

> The real crux here is whether or not B and C are mine or some one else's
> (even if that is internal).

Indeed, and all bets are off once the transitive facilities stop communicating 
sufficient information.

> Only my stuff can be a SNAPSHOT and it is either all a snapshot or it is
> not. So, if B & C are mine it's not an issue, if they belong to some one
> else's, they can't be SNAPSHOTs, it's that simple. I can even use the
> enforcer to ensure there isn't a SNAPSHOT set anywhere as part of the
> inspection process.
> 
> We release by changing one entry in one POM and all of our stuff gets
> versioned, built and released. Repeat the process and everything is back
> to the next SNAPSHOT so we can resume changing things. It seems it is
> this one discreet activity that CD abhors. You want to defer it to after
> the fact which doesn't seem any different than what Stephen suggested by
> waiting for CI feedback and then trigger a CD build. I don't get what
> event prompts you to wan to go back and reproduce a build to be a
> release?

There was a time I wouldn't have felt naked without a CI server.  I would 
"never" institute CD, but then who would ever need more than 640KB?  Things 
change.  Any tool can either provide generalized facilities to enable (if not 
support) these kind of requests or sometimes find itself delegitimized by cocky 
upstarts with more hype than heat.  I like Maven and want it to remain the 
favorite build tool, so it makes sense to help consider these kinds of 
arguments.  I look forward to being surprised someday.  In the mean time, if 
someone wants to put their head in this area, why discourage them?

> The ours vs. theirs problem exist for your plugin scenario too. Sure
> you've created a synthetic POM but have they? If B & C's  development is
> in fact decoupled from yours, why would they? How would they know? If
> they didn't make one and in turn are using SNAPSHOT deps themselves then
> you're hosed and your problem is spiraling in complexity.

The site-specific policy that groups make today are still valid.  I generally 
don't allow external SNAPSHOTs into Nexus, and this is probably a sufficient 
means to solve the problem if their RM can't transitively supply the facilities 
required to interoperate to provide a named snapshot (i.e. their RM doesn't run 
the plugin).  

I simply can't imagine a partnership where I have no clue about what an 
external partner is doing but still want their bleeding-edge work product 
deployed to my production server in a CD process.  On the other hand, if I am 
tight enough with them to know what they are doing and we agree I do want their 
bleeding-edge going live on my server, it's not farfetched at all that we would 
be sharing a lot more than just build artifacts.  We would probably be pretty 
well-integrated as tea

Re: Continuous Delivery and Maven

[Brian Topping]

On Nov 8, 2010, at 12:33 PM, Yanko, Curtis wrote:

> Why is that not guaranteed to exist or be reliable?

A Maven repository is a cache, not a reliable persistent store.  *Yours* may be 
reliable, but the artifacts that are built to it should not contain metadata 
that, if lost, would make rebuilding that (or another artifact) exceptionally 
difficult.  

> And at the
> moment I build A the build log will tell me exactly which SNAPSHOT we
> received.

So you want to keep build logs around indefinitely to solve this problem?  That 
sounds suboptimal.  There's no schema for log output, so pulling the values out 
by machine is unreliable over time.  

> I can crack it open and see exactly which SCC
> revision was used and which path within the SCC it came from (because we
> bake that info into everything we build).

But if A depends on B and C and the SCC revisions of B and C are not recorded 
in A, then there isn't a way to reliably build A.  

The other side of this question is where to store the revision IDs for B and C. 
 In the manifest?  Maven can't use that information.  Possibly in the POM as an 
additional qualifier in the respective  element of the POM that is 
stored in the artifact would make more sense, but then Maven needs to be 
changed with questionable semantics (what happens if there is an impossible 
combination of  and this revision ID qualifier?)

This is why I was considering a repository manager plugin.  It's site specific, 
and if it generated throwaway synthetic POMs for reproducing old builds, 
nothing has to be changed in Maven itself (the repository manager can call the 
artifacts anything it wants to properly identify the exact versions of B and C, 
likely returning synthetic POMs for them too).




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

Re: Continuous Delivery and Maven

[Brian Topping]

On Nov 7, 2010, at 1:29 PM, jhumble wrote:

> One possibility to get repeatable builds without filling up an artifacts
> repository too fast could be to make Maven store the fully qualified pom
> files in the artifacts repo and an md5 of the binary but not necessarily the
> actual binary. I know artifacts repos already store some of this
> information.
> 
> That way you could make sure sufficient metadata is publicly available such
> that they can be reproduced, without using up loads of disk space. You could
> also happily delete older binaries, safe in the knowledge that people could
> reproduce them from the metadata in the artifacts repo.

One of the things I like about snapshots is it just simply means "latest".  
Though the thing about timestamped snapshots is that they aren't guaranteed to 
exist (the repository is not typically assumed to be reliable), and they aren't 
100% reproducible (the timestamp offset includes the time it took to build the 
artifact and all the artifacts before it, meaning there's no way to know 
exactly what point in time the build came from).  Even if one could find the 
correct timestamp to check out from to get the same binary, whatever subsystem 
creates the timestamp on upload (wagon?) probably doesn't like being told what 
to call the snapshot.  

It follows the only way to get a reproducible build is either to tag the 
original sources or to know the SCM revision id.  The revision id is a natural 
tag that is automatically generated, and does not clutter the named tag space 
with thousands of tags that have no organizational meaning.  On my CI builds, 
the first thing that happens is grabbing the revision ID from SVN, and that's 
put in a properties file that can be used when the UI is generated.  Where the 
version number helps users identify the general features to expect of the 
current software, the revision ID is great for filing issues so devs don't have 
to guess at what sources have the issue.  

When the sources all come from the same SCM repository tree, the rev ID makes 
it a cinch to reproduce the build.  Of course, a better solution can span 
multiple trees and is reproducible.

It just seems like the rev ID is really useful here for identifying 
reproducible builds without creating releases every time, does it fit with your 
ideas?  If so, a hypothetical repository manager plugin could be maintaining 
information about snapshot dependencies based on SCM rev ID, thus allowing for 
reproducibility without modifying Maven or existing snapshot mechanics.  Such a 
plugin might be able to generate a POM that has the extra rev ID metadata that 
the repo manager would recognize, allowing for existing SNAPSHOT-style 
identifiers to keep working for developer desktops (avoiding SCM thrash), but 
also providing reproducibility through synthetic POMs.



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

Re: Continuous Delivery and Maven

[Brian Topping]

On Nov 7, 2010, at 11:14 AM, jhumble wrote:

> Ideally what I'd like is for Maven to explicitly support the continuous
> delivery model and provide snapshots that are reproducible.

Snapshots can be reproducible if developers set dependencies on the timestamped 
name of the deployed version.  I remember there being reasons that these 
strategies are discouraged (should be in the list archives), but those reasons 
may not apply here.

If I understand the paradigm, it's not that developers would want to reject the 
latest version of any dependencies, just that the snapshot builds should be 
reproducible.  Since the POM is the source of dependency resolution for any 
Maven build, it seems like the release plugin in use would have to update the 
project POMs to the currently resolved name of the actual dependency and check 
them in before the tag.  

But if the release checks in a POM and this is happening over and over for 
every checkin (a one line change in a heavily connected project could easily 
cause several POMs to be updated), suddenly dependent versions need to have 
their POMs changed, checked in, and new version propagated iteratively.  On 
developer desktops, all these new POMs would need to be kept up to date 
constantly to avoid text conflicts.  Maybe a VFS SCM could get around this, 
but ick!  The tooling is suddenly very heavyweight.

Does your book discuss ways to get around these issues?
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: The joys of dependencies

[Brian Topping]

On Nov 5, 2010, at 4:56 PM, Phillip Hellewell wrote:

> I'm guessing you also update the parent pom's version each time the
> dependency management section changes, yes?

Are you keeping in mind the impact that SNAPSHOT versions have on your build?  
A released version is like a point on a line or an instant in time, whereas 
snapshots are the distance between points.  Snapshots can be for your own use 
only (with the 'install' goal) or to share with others who have access to a 
shared remote repository (with the 'deploy' goal).  If I am using snapshots, I 
don't have to change the version every time I make a change, since someone 
else's build that depends on the snapshot I deployed to our shared repository 
will check that repository with every build to make sure it has the latest.  In 
other words, if I deploy a new snapshot with a changed dependency management 
section, it will be picked up by others (including CI) when they run a build.

I've found CI systems to be the easiest way to manage this complexity, but I 
haven't found a self-maintaining way to get them to trigger with the 
granularity necessary to just build based on changes.  For instance, I can add 
one SCM repository trigger to a top-level build, but that just triggers CI to 
rebuild everything.  I believe this is not what you want because if CI deploys 
new snapshots for everything, the binaries for everything built will look stale 
to all the developer desktops that share the repository that CI pushed to.  On 
the other hand, if I have hundreds of modules and I need to create a separate 
SCM triggers for each one of them, the effort to maintain the build shoots way 
up.  It would create the desired granularity, but I haven't had a case that 
this would be worth it yet.

But I think your original observation of using version ranges is correct.  

Anyway, if you have a build that is this complex, you may need someone to wear 
the release management hat.  Maven doesn't make the problem less complex, it 
just does most of the work for the solution.  It won't stop people from having 
variations on what the correct answers are (i.e. when to change versions), 
hence the need to have a single authority that manages procedure the same way 
every build.

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

Re: how to start

[Brian Topping]

On Nov 5, 2010, at 12:41 PM, Ron Wheeler wrote:

> JSF 2 over Struts

Wicket over JSF.

$0.02...

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

Re: Problem while deploying snapshot to repository

[Brian Topping]

On Nov 4, 2010, at 5:08 PM, Ron Wheeler wrote:

> On 04/11/2010 2:36 PM, Brian Topping wrote:
>> On Nov 4, 2010, at 1:59 PM, Ron Wheeler wrote:
>> 
>>> Putting repository information in a Parent POM keeps your project POMs 
>>> small and uncluttered.
>> I often make an exception to this very good advice:  If I am working with 
>> snapshot versions from a remote repository, I'll temporarily put that 
>> repository declaration in the POM for the project with the dependency, not 
>> at the top level.   This speeds up builds because every defined repository 
>> with snapshots enabled are consecutively searched until the latest version 
>> of any snapshot can be confirmed.  Reduce the number of repositories to 
>> search, speed up the build!
> You are clearly a user that is comfortable with Maven and can deal with a 
> significant amount of complexity so I will gladly accept your exception.
> You are also braver than I am (or stuck with third party developers who hate 
> to actually say that they have finished something), so you need to experiment 
> with remote Snapshots. So far, I have been lucky in this regard.

FWIW, the first "discovery" I made on this route was adding these two lines to 
every repository:

true
false

Then do a build and turn on snapshots for the repositories you need them on.  
The ones that you turn them on with, these are candidates for moving to a 
sub-build.  But even without moving them, disabling snapshots on repositories 
that don't have any snapshots will speed up your build as well.



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

Re: Problem while deploying snapshot to repository

[Brian Topping]

On Nov 4, 2010, at 1:59 PM, Ron Wheeler wrote:

> Putting repository information in a Parent POM keeps your project POMs small 
> and uncluttered.

I often make an exception to this very good advice:  If I am working with 
snapshot versions from a remote repository, I'll temporarily put that 
repository declaration in the POM for the project with the dependency, not at 
the top level.   This speeds up builds because every defined repository with 
snapshots enabled are consecutively searched until the latest version of any 
snapshot can be confirmed.  Reduce the number of repositories to search, speed 
up the build!

Of course, this is not a problem if you use a nearby repository manager.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: [Repetitive]: Maven does not live up to its promises

[Brian Topping]

On Oct 23, 2010, at 5:15 PM, Kenneth McDonald wrote:

> First, note that I did tag this as repetitive: You don't need to be reading 
> it if you don't want to be rehashing recent issues.

You might feel better now, but emailing future such works to file:/dev/null or 
articulating it to your dog might be a better use of everyone else's time.

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

Re: Questions on SNAPSHOTs

[Brian Topping]

On Oct 16, 2010, at 4:42 PM,  wrote:

> That's what I get for trying to save a step by replying to someone else's 
> post, but forgetting to change the subject :-[

That's called "thread hijacking", and the problem with it is that the mail you 
create will show up in everyone's inbox and every list archiver as a part of 
the thread that you hit "Reply" to and change the subject.  It's a much bigger 
problem than you realized!

The cause of this is an SMTP header called "In-Reply-To".  Most mail readers 
will allow you to "Show All Headers" so you can see it for yourself.  If you 
don't remove that header before sending your new inquiry, you'll inadvertently 
join hijackers everywhere!

Practically, it takes just as much time to remove that header as it does to 
create a new email to the list.  That's why most people do it (and keeping the 
mail list archives clean in the process).

Please, don't hit "Reply" to start a new thread!  

Cheers, Brian
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven is a swamp

[Brian Topping]

On Oct 15, 2010, at 4:50 PM, Kenneth McDonald wrote:

> I still don't get the complacency at the XML swamp.

If I have to speak Italian to get the best cup of coffee in Little Italy, so 
what if it's a chore?  A focus on language instead of semantics leaves one lost 
to the opportunity at hand.

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

Re: Maven SQL plugin

[Brian Topping]

Hi gang,

I can help with the plugin.  There have been a few authors on it over the 
years, and there may be some gaps in coverage.  Apologies for that. 

Would it be too difficult to get a small project in HSQL that demonstrates the 
issue?  I don't use the plugin any more, but am happy to help out.  

It's probably due for a release as well.  

Cheers, Brian

On Oct 14, 2010, at 3:44 PM, Martin Gainty wrote:

> 
> Chris and Company
> 
> i tried 12 ways from sunday and I could not get this plugin.xml to work for 
> me 
> debug statements display NPEs on any/all references to srcFiles
> I discovered the srcFiles array is not initted and not allocated
> Source file: org.codehaus.mojo.sql.SqlExecMojo
>
>  srcFiles
>  java.io.File[]
>  false
>  true
>  List of files containing SQL statements to 
> load.
>
> 
> One solution is to refactor the array to use ArrayList 
> and reconfig on pluginXml to implement java.util.ArrayList does 
> work (at least for me)
>
> 
>  srcFiles
> 
>  java.util.ArrayList
> 
>  false
> 
>  true
> 
>  List of files containing SQL statements to 
> load.
> 
>
> 
> 
> this is more than a 1 line change and I have other things to do..i could do a 
> fix
> but then theres the test-suite to worry about
> 
> any possibility to get an official response from the author?
> 
> Good Catch Chris!
> Martin Gainty 
> __ 
> Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
> 
> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
> sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
> oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich 
> dem Austausch von Informationen und entfaltet keine rechtliche 
> Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen 
> wir keine Haftung fuer den Inhalt uebernehmen.
> Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
> destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
> l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci 
> est interdite. Ce message sert à l'information seulement et n'aura pas 
> n'importe quel effet légalement obligatoire. Étant donné que les email 
> peuvent facilement être sujets à la manipulation, nous ne pouvons accepter 
> aucune responsabilité pour le contenu fourni.
> 
> 
> 
> 
>> Date: Thu, 14 Oct 2010 10:03:58 -0400
>> Subject: Re: Maven SQL plugin
>> From: john.te...@gmail.com
>> To: users@maven.apache.org
>> 
>> Hi Chris,
>> 
>> #2 is probably the best to ensure repeatability in the order you want.  It
>> also prevents inadvertent re-ordering if a new sql file is introduced into
>> the sql directory.  In our project, we use srcFiles rather than fileset:
>> 
>> 
>>[file1]
>>[file2}
>>...
>> 
>> 
>> HTH,
>> John Singleton
>> 
>> On Thu, Oct 14, 2010 at 9:25 AM, Chris Odney  wrote:
>> 
>>> Hi,
>>> 
>>> I am facing some problem in ordering the sql execution.
>>> 
>>> We have one sql script file for each table under one directory. Ex: There
>>> is
>>> user.sql and role.sql in the directory c:\SqlScripts. We are using the sql
>>> maven plugin to execute these sql files.
>>> 
>>> The role table has a Foriegn key to the user table and the execution is
>>> failing because the plugin is trying to execute the role.sql before
>>> user.sql. I cannot use the  orderfile attribute as we specify the 
>>> as c:\SqlScripts\*.sql.
>>> 
>>> How do I overcome this problem?
>>> 
>>> I see 2 solutions:
>>> 
>>> 1) Merge all scripts into one file in the creation order, the script to
>>> create role comes after the script to create user.
>>> 
>>> 2)Remove the * wildcard and specify each file in the  attribute
>>> in
>>> the order of execution.
>>> 
>>> 3)Number the name of the files according to the execution order ex:
>>> 1_user.sql, 2_role.sql and use the 'ascending' orderfile attribute(not sure
>>> if this would work though, as the ordering may not be applied)
>>> 
>>> Any more elegant solutions?
>>> 
>>> Thank you,
>>> Chris.
>>> 
> 


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

Re: maven is a swamp

[Brian Topping]

On Oct 12, 2010, at 10:01 PM, Martin Gainty wrote:

> Suprisingly maven is not the first programming language to use XML

This is worth clarifying.  What makes Maven unique, and I believe 
groundbreaking, is that the POM is declarative, not procedural.  It is not a 
programming language in the traditional sense.  There are many examples of 
procedural languages written in XML, and many agree they are painful to use.  
That's why the one that was used in Maven 1.x is notably absent from Maven 2.x.

Once you get used to the paradigm shift and get used to it, it becomes 
remarkably easy to look at any build and find what it is doing.  While many 
systems (like Ivy) have started using Maven's central repository, if they use 
procedural descriptions of a build, they are missing the vision that Maven has. 

Personally, I find it frustrating to have to dissect an Ant build to figure out 
what's going on.  A Maven build is validated against a schema, and finding what 
I am looking for is predictable and quick.  It's also fast to write, since most 
IDEs can do type-completion with a schema declaration, and many have been 
augmented to read plugin.xml files inside plugins to do type completion of 
plugin configuration as well.

Lastly, having a validated structure for the build allows IDEs to import the 
POM directly, and because the Plugin interface is so simple, it's easy for IDEs 
to integrate against plugins.  In my experience, this level of integration is 
unique to Maven.

Hope you stick with it.  Maven will really grow on you, as it has with a huge 
number of folks over the last few years.

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

Re: Phase between install and deploy?

[Brian Topping]

On Oct 7, 2010, at 3:57 PM, Phillip Hellewell wrote:

> What is the general approach to solving this conundrum?  If there were
> a "post-install" or a "pre-deploy" phase, that would solve it, but
> those don't exist afaik :(

You can create a custom lifecycle for that build, then bind where you want.  

http://www.sonatype.com/books/mvnref-book/reference/writing-plugins-sect-custom-lifecycle.html



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

Re: Strategies for converting from Ant

[Brian Topping]

The largest build I converted to Maven was about five years ago, and it had 
roughly 100 projects in Ant.  Intriguingly, they had written an Ant plugin to 
process Eclipse project metadata.  It strikes me you might be able to take the 
same shortcut with your project if your build is somehow able to create eclipse 
projects.  The code that I wrote generated dependencies for subprojects, and 
most of the interesting plugin configuration was inherited, so the child 
projects were very thin.

If you do things this way, consider keeping your non-central repository 
references in the project they are used in, and definitely be sure to 
explicitly define whether a repository is snapshot and/or release.  If you 
don't, snapshots will be looked for all over the internet for each build and in 
all the repositories that are hanging around the top level, slowing your builds 
tremendously.  A repository manager like Nexus can help you a lot here, and if 
you have the resources, makes sense to deploy as early as possible.

Regarding the desire to do partial builds and run with relatively current code, 
having a shared corporate repository will allow developers to deploy snapshot 
binaries after they are satisfied with the changes they have made to modules 
they were working on.  Maven will naturally check for snapshots on this shared 
repository, and if some code has been changed outside your module, you'll pick 
up the binaries and be running with the latest.  Note this is not 
"bleeding-edge trunk", but binaries for modules in a state that your peers were 
comfortable with before they deployed them.  Of course, if you configure the 
build to deploy source jars as well, you'll have sources in your IDE for 
whatever version your peers deployed as well.  

The hardest thing I've found in such large migrations is effort required to 
migrate the source tree if most of your peers will continue to work on other 
projects with the old build during the migration.  Working on a branch is 
practically impossible since there are a lot of non-linear mappings between 
subtrees spread throughout your trunk.  Merging changes between them becomes 
impossible with many SCMs out there.

Hope that helps..

On Sep 23, 2010, at 5:30 PM, David Karr wrote:

> I work on a pretty large project that uses Ant for builds. We're doing some
> research on converting to Maven.  I'd like to describe some of the elements
> of our situation, hopefully to find some conceptual "cookbook" strategies
> for those aspects.
> 
> The "application" consists of the aggregation of several (10-20) separate
> SVN/Eclipse projects on a particular branch.  Sometimes a project is used on
> the branch, sometimes on the trunk.  The "build", when spawned from one of
> those projects expects the other projects to exist with expected names in
> peer directories (like "../module"). In order to complete a build of the
> entire application, a developer has to check out all of the projects
> required for the build, even if they only do work in one of them.  The plans
> for a particular release define which projects will be on the branch, and
> which on the trunk.
> 
> Although the deployment unit of the application is an EAR, the present build
> process uses a vendor-specific assembly mechanism to produce the EAR
> modules.  We're examining how/whether we can simplify that part to be more
> conventional, but we may have to just figure out how to integrate more
> closely with that mechanism so we can control it, instead of replacing it.
> 
> Developers use Eclipse on Windows, although the official build and
> deployment is on Unix/Solaris.  Developers would likely use the m2eclipse
> plugin in Eclipse.
> 
> One thing that I'm particularly looking forward to is the ability to just
> have to check out a single project from SVN in order to build the entire
> application, as I'm hoping it can somehow know to pull subproject builds
> from the repo instead of expecting to build the source locally.  I'm not
> certain exactly how that will work, but I believe that should be an expected
> benefit of this conversion.
> 
> I know I've left out a lot of specific details of our environment, but can
> you enumerate specific strategies and steps we should be examining?


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

Re: AW: Building ODE with Maven

[Brian Topping]

Wow, Ode builds with Maven now?!?  Awesome!!

On Sep 16, 2010, at 5:31 AM, Stephen Connolly wrote:

> There may be test-jar dependencies
> 
> I would recommend using
> 
> mvn clean install -DskipTests
> 
> if that does not work you should contact the Apache ODE mailing list
> 
> -Stephen
> 
> On 16 September 2010 10:19, Tina Schliemann  wrote:
> 
>> Thank u but now i have a new error :(
>> 
>> 
>> [INFO]
>> 
>> [ERROR] BUILD FAILURE
>> [INFO]
>> 
>> [INFO] Compilation failure
>> 
>> E:\Diplomarbeit\trunk\bpel-test\src\main\java\org\apache\ode\test\BPELTestAb
>> stra
>> ct.java:[125,41] package org.springframework.mock.jndi does not exist
>> 
>> 
>> 
>> -Ursprüngliche Nachricht-
>> Von: Lukas Theussl [mailto:ltheu...@apache.org]
>> Gesendet: Donnerstag, 16. September 2010 11:14
>> An: Maven Users List
>> Betreff: Re: AW: Building ODE with Maven
>> 
>> 
>> 
>> Tina Schliemann wrote:
>>> Hi
>>> 
>>> It is a normal minus sign. That comes from copying out of the console.
>>> 
>>> That’s the command I use
>>> 
>>> mvn install –Dmaven.test.skip=true
>> 
>> Then your console uses the wrong minus sign :) Compare:
>> 
>> mvn install –Dmaven.test.skip=true (yours)
>> mvn install -Dmaven.test.skip=true (mine)
>> 
>> -Lukas
>> 
>> 
>>> 
>>> -Ursprüngliche Nachricht-
>>> Von: Lukas Theussl [mailto:ltheu...@apache.org]
>>> Gesendet: Donnerstag, 16. September 2010 11:08
>>> An: Maven Users List
>>> Betreff: Re: Building ODE with Maven
>>> 
>>> 
>>> 
>>> Tina Schliemann wrote:
 Hi,
 
 I try to build the apache ode with maven.
 
 
 
 With that command mvn install –Dmaven.test.skip=true I get that error
 
 
 
 [ERROR] BUILD FAILURE
 
 [INFO]
 
 
 [INFO] Invalid task -ûDmaven.test.skip=true': you must specify a valid
 lifecycle
>>> 
>>> You are using an invalid character for the cl option -D, it should be a
>>> normal minus sign.
>>> 
>>> HTH,
>>> -Lukas
>>> 
>>> 
 
   phase, or a goal in the format plugin:goal or
 pluginGroupId:pluginArtifactId:pl
 
 uginVersion:goal
 
 
 
 The building of the elipse files with that command mvn eclipse:eclipse
>>> works
 fine
 
 
 
 Can u pls help me?
 
 
 
 Thanks
 
 
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 
>> 


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

Re: Integrate Spring bean with Maven plugin ?

[Brian Topping]

If you start the Spring container manually, it will return a context that you 
can query for beans.  Within that started context, the beans will have 
obviously been wired according to your configuration.  

There's no limitation on where you create the context, but to get beans from 
the context, you need a reference to the context.  Use your favorite patterns 
to save the reference somewhere safe, and you are on your way.

On Jun 24, 2010, at 5:56 PM, Dan Tran wrote:

> basically i have all my spring beans wiring up thru an small initial
> xml config file, the rest are thru annotation ( spring 3.0.x )
> 
> so if I want to wrap Spring Service with maven mojo, i guess i need to
> start the the spring container from some where.  Where is the right
> place in the plugin?
> 
> -D
> 
> On Thu, Jun 24, 2010 at 1:46 PM, Baptiste MATHUS  wrote:
>> I guess you'll have to be give more details about what you want to do.
>> I don't understand: you want to create a jar containing spring beans? What
>> do you mean by spring beans (xml configuration, annotation, other...). Are
>> you writing a mojo where you want to use some part of spring, or even use
>> spring managed beans?
>> 
>> Cheers
>> 
>> 2010/6/24 Dan Tran 
>> 
>>> Hi
>>> 
>>> I have a set of Spring beans that I'd like to wrap them with maven
>>> plugin's mojo.  Any suggestion?
>>> 
>>> Thanks
>>> 
>>> -Dan
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>> 
>>> 
>> 
>> 
>> --
>> Baptiste  MATHUS - http://batmat.net
>> Sauvez un arbre,
>> Mangez un castor !
>> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 


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

Re: Mavenizing a project

[Brian Topping]

Put your tests in src/test/java as normal.  

If your helper classes are to be used by multiple projects, create a new 
project just for the helper classes, call it foo-test or something.  Put the 
helper classes in src/main/java in the foo-test project, not src/test/main.  
Then you can create a dependency with test scope on foo-test from the projects 
that need the test helper classes.

If you don't use that little trick, project B cannot depend on project A for 
it's test classes because the final artifacts never contain test classes. 

Brian

On May 28, 2010, at 1:26 PM, Greg Akins wrote:

> I'm working on Mavenizing a small project.  In the current project,
> there are three "source" directories.
> 
> The Main source, the JUnit test source and a dir called
> "test_informal" that contains some "helper" classes for doing
> interactive testing...
> 
> In a maven project, where would one put that type of source?
> 
> -- 
> Greg Akins
> 
> http://insomnia-consulting.org
> http://www.pghcodingdojo.org
> http://pittjug.dev.java.net
> http://twitter.com/akinsgre
> http://www.linkedin.com/in/akinsgre
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 


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

Re: No such archiver: 'swf'.

[Brian Topping]

Thanks Brian, I saw that configuration and realized that was one solution, but 
needed a non-SNAPSHOT means of completing the task.  I don't know the criteria 
that an issue gets promoted to configuration level options, but it seems like 
this issue periodically comes up as new archive formats are created.  It might 
be useful to have this as build-level configuration

It turns out that 'swc' *is* supported, 'swf' is not.  That actually makes 
sense, I can't imagine a situation where one would want to create a flattened 
archive with the contents of a swf since it is already a self-contained module 
with a single entry point.  This is how I realized I was using the wrong tool 
for the job, assembly:single with  seems to want to flatten the 
contents of the dependency into the output archive, where I wanted to include 
the dependency directly.  

Someone on the flexmojos list pointed out that I could use dependency:copy to 
handle this.  (So many plugins, so little time ;-))  That's working for me now.

One thing that seems relevant as a general Maven point-of-note, flexmojos has a 
goal called copy-flex-resources which takes any flex dependencies and adds them 
to the output WAR for this specific POM, and it gives a warning if the output 
artifact is not a WAR.  It's convenient, but not a universally applicable 
solution (such as when the flex resources need to be included in a zip 
archive).  So the general inquiry here is how dependency artifacts of opaque 
and previously undefined types should be included into archives such as .zip or 
.war.  Is this kind of copy-flex-resources thing the best way to do it 
everywhere?  If not, any thoughts on a better means?

On May 14, 2010, at 10:37 AM, Brian Fox wrote:

> Take a look at the patch for this issue:
> http://jira.codehaus.org/browse/MDEP-183
> 
> You would need to do something along the same lines, possibly
> introducing your own archiver impl, but this shows how you map the
> extension to the impl.
> 
> On Tue, May 11, 2010 at 2:52 PM, Brian Topping  wrote:
>> We've been successfully using Flex-mojos with our projects under Maven.  
>> It's been working well, but we need to include the .swf artifacts that are 
>> generated in an assembly.  That seems to be failing, and I get the following 
>> error:
>> 
>> Caused by: org.codehaus.plexus.archiver.manager.NoSuchArchiverException: No 
>> such archiver: 'swf'.
>>at 
>> org.codehaus.plexus.archiver.manager.DefaultArchiverManager.getResourceCollection(DefaultArchiverManager.java:90)
>>at 
>> org.codehaus.plexus.archiver.manager.DefaultArchiverManager.getResourceCollection(DefaultArchiverManager.java:128)
>>at 
>> org.codehaus.plexus.archiver.AbstractArchiver.asResourceCollection(AbstractArchiver.java:506)
>> 
>> My assembly descriptor, for reference, is pretty simple:
>> 
>> > xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0";
>>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>>  
>> xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
>>  http://maven.apache.org/xsd/assembly-1.1.0.xsd";>
>>php-webapp
>>
>>zip
>>
>>
>>
>>
>>  *:swf:*
>>
>>/
>>false
>>
>>
>>
>>
>>src/main/php
>>/
>>
>>
>> 
>> 
>> Is this the best way to compose the assembly?  If it is, I presume that I 
>> need to create and add an archiver that can deal with .swf (treating it as 
>> an opaque blob, presumably).  If not, it would be pretty easy to write a 
>> plugin, but I can't imagine I'm the only person running into this issue.
>> 
>> Thanks for any thoughts,
>> 
>> Brian
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 


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

No such archiver: 'swf'.

[Brian Topping]

We've been successfully using Flex-mojos with our projects under Maven.  It's 
been working well, but we need to include the .swf artifacts that are generated 
in an assembly.  That seems to be failing, and I get the following error:

Caused by: org.codehaus.plexus.archiver.manager.NoSuchArchiverException: No 
such archiver: 'swf'.
at 
org.codehaus.plexus.archiver.manager.DefaultArchiverManager.getResourceCollection(DefaultArchiverManager.java:90)
at 
org.codehaus.plexus.archiver.manager.DefaultArchiverManager.getResourceCollection(DefaultArchiverManager.java:128)
at 
org.codehaus.plexus.archiver.AbstractArchiver.asResourceCollection(AbstractArchiver.java:506)

My assembly descriptor, for reference, is pretty simple:

http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0";
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
  
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
 http://maven.apache.org/xsd/assembly-1.1.0.xsd";>
php-webapp

zip




  *:swf:*

/
false




src/main/php
/




Is this the best way to compose the assembly?  If it is, I presume that I need 
to create and add an archiver that can deal with .swf (treating it as an opaque 
blob, presumably).  If not, it would be pretty easy to write a plugin, but I 
can't imagine I'm the only person running into this issue.

Thanks for any thoughts,

Brian

Re: Need advice on version numbering convention

[Brian Topping]

I would echo Eric's sentiments, with a caveat.

A lot of smaller (in house, no exposed APIs) projects can be helped  
by starting with build numbers taken directly from the subversion  
revision ID.  This is a monotonically increasing integer, and by  
using that for your release ID, there's little or no reason to use  
tags, since every release ID _is_ a tag.  The use of the release ID  
also gives users a very weak idea of how much difference there is  
between two builds.


What release IDs do not do is provide information about architectural  
changes.  For instance in the traditional number of x.y.z, a change  
in x would indicate a substantial or full rewrite of the product, a  
change in y would indicate potential incompatibilities, and a change  
in z would indicate bug fixes.  But if you are running a small shop  
that does not have customers relying on the APIs of your product, you  
can just use subversion IDs and save yourself a ton of time, since  
architectural changes don't matter to anyone but the engineers, and  
all they care about is where to find that version in the source  
repository.


As Eric said, you can always add later, but it's hard to take away.   
So start with SVN IDs, and if that's not enough, move on to simple  
version numbers (as tags) as an external communication aid.


HTH,

:b

On Apr 4, 2006, at 8:06 PM, Eric Redmond wrote:

Well, sorry to dissapoint, but I'm not an expert... I am, however,  
full of

opinions!

This is how I tend to number, and it works well for me:

Skip bugfix numbering unless you are working on a major project.  
Seriously.
It gets very burdonsome to handle multiple minor edits on smaller  
projects,
since they either 1) change a lot... meaning that all of their  
dependencies
are expected to change? Naw, just use SNAPSHOTs or timestamps. 2)  
rarely
change... meaning, why would you need to keep track of version  
1.0.1 versus

1.0.2?
Now, that said, bugfix numbering is good for larger projects, like  
linux,

jboss, or maven. The difference between 2.0.0 and 2.0.3 is fairly
substantial. So, what's the difference between a small and large  
project?
Well, thats up to you. Just don't get overzealous. Remember: you  
can always
add decimals later, but its hard to take them away (try and explain  
to your
users and developers why you moved from 1.1.0.1a to the number 2:  
"what

version is this, really"?).

Parent and aggregator projects (pom packages) can live quite well  
with a
single number. 1, 2, 3... no need to complicate matters, they don't  
change
enough to need minor numbers, and when they do, its a pretty major  
change

for their children.
Addendum to the previous statment: if the artifact is the top  
aggregator of
a large project. Since this version will tend to be the project's  
actual

version, use the actual project's numbering scheme.

I also like to use the *-alpha-1, *-beta-3, *-RC-1 style of naming. It
works, its descriptive, and it lets users know if they're using a beta
project right off the bat.

I'd love the chat more, but the new episode of "House" is on!

Hope this helps;
Eric

On 4/4/06, Man-Chi Leung <[EMAIL PROTECTED]> wrote:


hi,

sorry that it is not a direct question on Maven usage, but I  really
hope to improve my Release management process with  Maven.

I would like to understand more regarding version numbering
convention, perhaps, the most commonly practice in Java community.

1) for subversion source tree. it is using Release.Minor.Bugfix-
ReleaseCandidate scheme
e.g. from  1.0.x  -> 1.1.x ->1.2.x -> 1.3.x
1.3.x-rc1 -> 1.3.x-rc2 -> 1.3.x-rc3

2) in linux kernel, 1.x  , odd-numbered releases (2.5, 2.7, etc.) are
unstable development versions, while even-numbered releases (2.6,
2.8, etc.) are stable consumer releases.

3) Eclipse community is using a term "Milestone". it is from 2.x M1 -

2.xM2 ... -> 2.xM6 -> 3.x , etc


4) Apple is practicing number-letter-number scheme, also having
development version & marketing version
e.g first build of Panther (10.3) was 7A1. The first public release
was 7B85; the last, 10.3.9, was 7W98. But the next build of OS X was
10.4, 8A1

5) in general, there is also 1.x apha , 1.x beta , 1.x final release.
etc

6) in Maven and relating maven plugin, there is a SNAPSHOT scheme.
i would like to find out more about the differences and good
practice. any expert can help?

thanks so much for help and advice!

Regards,
manchi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Plugin Classpath Problem

[Brian Topping]

Howdy,

I'm putting together some changes for the WAR plugin for resource  
filtering, and I'm having some problems with classpaths.  I've  
attached a stacktrace.  The class that is being searched is in plexus- 
utils-1.2-SNAPSHOT on ibiblio, and it appears from the output snippet  
below that the jar is being properly loaded via local override, but  
when it comes time to load a class from the jar, it's not found.


Presumably it's a problem with my configuration, is there enough  
information in this trace to determine the issue?


Thanks,

Brian


[DEBUG] Retrieving parent-POM from the repository for project:  
null:plexus-utils:jar:1.2-20060213.104414-2
[DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.5 (removed -  
nearer found: 1.2-SNAPSHOT)
[DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.2-SNAPSHOT  
(selected for runtime)
[DEBUG]   org.apache.maven:maven-plugin-api:jar:2.0 (selected for  
runtime)
[DEBUG]   org.apache.maven:maven-artifact:jar:2.0.1 (removed -  
nearer found: 2.0)
[DEBUG]   org.apache.maven:maven-artifact:jar:2.0 (selected for  
runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed -  
nearer found: 1.2-SNAPSHOT)
[DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-war-plugin: 
2.0-beta-3-SNAPSHOT:war' -->
[DEBUG]   (s) classesDirectory = /Users/topping/dev/topspin/topspin- 
web/target/classes
[DEBUG]   (f) filters = [/Users/topping/dev/topspin/topspin-web/src/ 
main/webapp]
[DEBUG]   (f) outputDirectory = /Users/topping/dev/topspin/topspin- 
web/target

[DEBUG]   (s) project = [EMAIL PROTECTED]
[DEBUG]   (f) warName = topspin-web
[DEBUG]   (s) warSourceDirectory = /Users/topping/dev/topspin/ 
topspin-web/src/main/webapp
[DEBUG]   (s) webappDirectory = /Users/topping/dev/topspin/topspin- 
web/target/topspin-web
[DEBUG]   (f) workDirectory = /Users/topping/dev/topspin/topspin- 
web/target/war/work

[DEBUG] -- end configuration --
[INFO] [war:war]
[INFO] Exploding webapp...
[INFO] Copy webapp resources to /Users/topping/dev/topspin/topspin- 
web/target/topspin-web
[INFO]  
-- 
--

[ERROR] FATAL ERROR
[INFO]  
-- 
--

[INFO] org/codehaus/plexus/util/FileUtils$FilterWrapper
[INFO]  
-- 
--

[DEBUG] Trace
java.lang.NoClassDefFoundError: org/codehaus/plexus/util/FileUtils 
$FilterWrapper
at org.apache.maven.plugin.war.AbstractWarMojo.copyFile 
(AbstractWarMojo.java:329)
at org.apache.maven.plugin.war.AbstractWarMojo.copyResources 
(AbstractWarMojo.java:310)
at  
org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp 
(AbstractWarMojo.java:276)
at org.apache.maven.plugin.war.WarMojo.performPackaging 
(WarMojo.java:146)
at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java: 
124)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo 
(DefaultPluginManager.java:415)
at  
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals 
(DefaultLifecycleExecutor.java:531)
at  
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLif 
ecycle(DefaultLifecycleExecutor.java:472)
at  
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal 
(DefaultLifecycleExecutor.java:451)
at  
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHand 
leFailures(DefaultLifecycleExecutor.java:303)
at  
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegment 
s(DefaultLifecycleExecutor.java:270)
at  
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute 
(DefaultLifecycleExecutor.java:139)
at org.apache.maven.DefaultMaven.doExecute 
(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java: 
115)

at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced 
(Launcher.java:315)

at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode 
(Launcher.java:430)

at org.codehaus.classworlds.Launcher.main(Launcher.java:375)





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Mutliple source directories in project.xml

[Brian Topping]

> -Original Message-
> From: John Casey [mailto:[EMAIL PROTECTED]
> Subject: RE: Mutliple source directories in project.xml
> 
> It seems to me that the POM is the wrong place to put anything related
> to artifacts created during maven execution.  

I tend to agree with this, but in my case, the generated artifacts are
abstract base classes and factory classes, one of each for every entity,
generated from a UML model (somewhat critical to the success of the goals...
;)  The correct implementation is likely that the XMI has special
representation in the POM, but is this just a specific case of a bigger
problem?  If so, there will never be an end to this issue as new metamodels
are introduced.  

XDoclet is a tricky case of this because it is mixing two sources of
information (java classes and class metadata) into a single source set.  The
problem with the POM might be the inability to differentiate between vanilla
source and source that is seasoned with XDoclet tags (or aspects, etc...).
It is a similar argument to the premise against projects having multiple
artifacts.

If I understand the POM correctly, it almost seems that Maven could use
pluggable providers for various metamodels, allowing for it to direct
generation during build and querying of the project from a component/PM
perspective.  Querying a project model but omitting the class metadata gives
an incomplete picture of the project, reducing the effectiveness of eventual
tools that will be able to query POMs on the net like Google (Poogle? :).
Imagine being very happy with a particular component and doing a "backwards
links" search for components that use it.  If metamodels are not available
for querying (XDoclet, UML via XMI, etc.) much of that information could be
unavailable.

> I'd even go so far as to
> say that the list of reports to be generated doesn't belong 
> in here.  To
> me, it makes sense to have the POM describe the project 
> itself, in pure
> terms, without making assumptions about what artifacts will be
> generated. 

It seems to me that the POM should be both a director to the generation of
artifacts as well as an indicator to the existence of artifacts.  In a
potential alternate universe, the transitive closure of POMs through
dependencies includes all components ever built under various Maven
installations.  This mirrors the web itself, but uses POM instead of HTML for
hyperlinking.

Imagining that such a world existed, a developer could import a class by
name, and the IDE would automagically look it up in a hypothetical POM search
engine, then update the POM with the correct dependency.  Or maybe Maven
starts to form the idea of a "build container", and a Java compiler that is
executing uses an import resolution service of the container for issues such
as missing imports.  

But without indication that an artifact (such as a report) existed, the
engine would have a harder time to find it.  Could POM search engine
functionality be the metric by which inclusion in the POM is measured?  If
so, how do generated artifacts fit in now?

> To that end, configuring things like the generated source directory
> should take place in project.properties instead of the POM. Obviously,
> it's not acceptable to try to configure the list of reports via
> project.properties, but somehow this information should also 
> be excluded
> from the POM. 
> 
> In general, operational information used in maven execution but not
> having any use outside of maven SHOULD NOT be in the POM. This will
> leave open the opportunity for the POM to outlive maven's current
> incarnation. Accomplishing this will make the POM much more 
> stable, and
> will mean that users won't be penalized by having to rewrite POMs for
> each update to a maven plugin. It should also reduce the requirements
> involved in providing backwards compatibility.
> 
> -john

-b

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Stupid Q's #2: What is an Action Definition?

[Brian Topping]

> -Original Message-
> From: Jason van Zyl [mailto:[EMAIL PROTECTED]
> Subject: Re: Stupid Q's #2: What is an Action Definition?
>
> > 
> > BUILD FAILED
> > ...
> > Goal [test:test] has no action definition.
> 
> Some times the cache gets whacked if you interrupt a build and the
> pointers among goals get corrupted and if the pointer can't 
> be found you
> will get this message. Go into your ~/.maven/plugins 
> directory and erase
> the *.cache files and try again.

Worked great!  I'll put that on my "things to do before posting" list.
Thanks a ton, Jason!

-b

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Stupid Q's #2: What is an Action Definition?

[Brian Topping]

Hi all,

Just wondering if anyone can explain what an "action definition" is?  I've
got a subproject that simply provides a jar for a source generation step.  I
would have rather had an exploded JAR sitting around and have the directory
available to the generator, but I couldn't figure that out, so decided to put
the jar subproject in instead.  

But when I do a build now, I get:

BUILD FAILED
File.. file:/C:/dev/bill2/generator-jar
Element... attainGoal
Line.. 4
Column 37
Goal [test:test] has no action definition.
Total time: 3 seconds
Finished at: Sat Jan 10 22:55:48 EST 2004

I presume that is because the generator jar really has no tests yet, and in
fact I cannot think of a situation that I would ever waste time on the
generator tests.  (I like the idea of TDD, I'm just not "bleeding seven
colors" yet...)

Anyway, I added "maven.test.skip = true" to project.properties to no avail.  

So as before, one problem and two questions:

1) what is the solution to this?
2) how could I find this myself?  (this question has been asked on the lists
but never answered that I can tell...)

I'll ask the a more general question in a followup to this.

Thanks again!

-b

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]