Re: Getting source code for existing JARs

2009-07-10 Thread Anders Hammar
If I didn't misunderstand the situation, the poster has a runtime
system with a bunch of jars. Thus, no poms.

/Anders

On Fri, Jul 10, 2009 at 02:52, Barrie Treloarbaerr...@gmail.com wrote:
 On Fri, Jul 10, 2009 at 5:25 AM, Singhal, Pulkitpulkit.sing...@hp.com wrote:
 Hello,

 I wanted to know if maven can be used to fetch source code for existing jars 
 on a system?
 Can I simply point maven to a jar on my system and expect it to do its best 
 to fetch the source code for the correct version according to my jar from 
 its global repository?
 Can I do this via an eclipse plugin?

 Thanks!


 If you have your dependencies declared correctly in a pom you can use
  mvn eclipse:eclipse -DdownloadSources=true -DdownloadJavadocs=true

 to download both the source jar and the javadoc jar (you may need the
 javadoc if the source does not exist)

 If you happen to also be using eclipse as your IDE then everything is
 all setup and ready for importing your projects.

 If not, you can find the -sources and -javadoc jars in the same
 directory as the base jar in your local m2 repository.

 -
 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: Online Poll for Maven Cookbook

2009-07-10 Thread Anders Hammar
The list is fine. I've received both your messages. You can always
check if your mail gets through by looking at the Nabble archive.

/Anders

On Fri, Jul 10, 2009 at 07:56, Peter
Horlockpeter.horl...@googlemail.com wrote:
 Hi, I can't wait to see the Maven cookbook from Tim O'Brien -
 but Tim said he's going to work more on the Definitve guide and the
 m2eclipse book first,
 after he has worked on the nexus book. So if the cookbook will ever appear,
 it will be the last in line! :-(

 Let's change that! :-)

 I've started a survey, vote here (for whatever book you want to see next):
 http://www.doodle.com/p42ebutub2zx4kb4

 P.s.: There seems to be a problem with this list - I sended this message
 already yesterday, but still didn't get it...

 Peter


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



RE: Reporting Plugins Not Inheriting Versions

2009-07-10 Thread Jörg Schaible
Mohan KR wrote at Donnerstag, 9. Juli 2009 20:06:

 Yup..got bitten by it..As a best practice you have to lock down the
 plugin version
 in the reporting section, it is *not* propogated from the pluginManagement
 I believe.
 (at least not in 2.0.9), I believe there is a JIRA issue to have a
 reportingManagement
 section or supposed to be fixed in 3.0.x :)

Additionally you have to keep in mind, that a plugin is only loaded once in
the reactor i.e. if a plugin is used during build as well as for the
reports (like surefire) the version of the plugin used during the
build wins and the version defined in the report section is ignored
completely (just like both version are ignored in a reactor build if the
plugin has been used before in another project of the build).

- Jörg


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



AW: Getting source code for existing JARs

2009-07-10 Thread Lewis, Eric
Well, I don't know if you're using m2eclipse, but with that it's possible. Just 
open the Maven Dependencies, right-click on some jar and choose Maven... 
download sources.

Best regards,
Eric

-Ursprüngliche Nachricht-
Von: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] Im Auftrag 
von Anders Hammar
Gesendet: Freitag, 10. Juli 2009 00:08
An: Maven Users List
Betreff: Re: Getting source code for existing JARs

Hi,

Not the magically way I think you're asking for, no. Not to my knowledge anyhow.
What you could do, is to try to find out what artifact you have an
then, if you're lucky, the source code might exist in a repository
(central for instance). One way to find out what artifact you have is
to use its checksum and then use a Nexus instance to try to find a
match. You can find some info about this in one of Jason van Zyl's
blog posts:
http://www.sonatype.com/people/2009/04/mavenizing-the-appengine-sdk/

/Anders

On Thu, Jul 9, 2009 at 21:55, Singhal, Pulkitpulkit.sing...@hp.com wrote:
 Hello,

 I wanted to know if maven can be used to fetch source code for existing jars 
 on a system?
 Can I simply point maven to a jar on my system and expect it to do its best 
 to fetch the source code for the correct version according to my jar from its 
 global repository?
 Can I do this via an eclipse plugin?

 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



Re: Reporting Plugins Not Inheriting Versions

2009-07-10 Thread Stephen Connolly
2009/7/10 Jörg Schaible joerg.schai...@gmx.de

 Mohan KR wrote at Donnerstag, 9. Juli 2009 20:06:

  Yup..got bitten by it..As a best practice you have to lock down the
  plugin version
  in the reporting section, it is *not* propogated from the
 pluginManagement
  I believe.
  (at least not in 2.0.9), I believe there is a JIRA issue to have a
  reportingManagement
  section or supposed to be fixed in 3.0.x :)

 Additionally you have to keep in mind, that a plugin is only loaded once in
 the reactor i.e. if a plugin is used during build as well as for the
 reports (like surefire) the version of the plugin used during the
 build wins and the version defined in the report section is ignored
 completely (just like both version are ignored in a reactor build if the
 plugin has been used before in another project of the build).


That is only true if you invoke the build lifecycle first...

mvn site install

vs

mvn install site

;-)


 - Jörg


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




Re: Reporting Plugins Not Inheriting Versions

2009-07-10 Thread Jörg Schaible
Stephen Connolly wrote at Freitag, 10. Juli 2009 09:59:

 2009/7/10 Jörg Schaible joerg.schai...@gmx.de
 
 Mohan KR wrote at Donnerstag, 9. Juli 2009 20:06:

  Yup..got bitten by it..As a best practice you have to lock down the
  plugin version
  in the reporting section, it is *not* propogated from the
 pluginManagement
  I believe.
  (at least not in 2.0.9), I believe there is a JIRA issue to have a
  reportingManagement
  section or supposed to be fixed in 3.0.x :)

 Additionally you have to keep in mind, that a plugin is only loaded once
 in the reactor i.e. if a plugin is used during build as well as for the
 reports (like surefire) the version of the plugin used during the
 build wins and the version defined in the report section is ignored
 completely (just like both version are ignored in a reactor build if the
 plugin has been used before in another project of the build).

 
 That is only true if you invoke the build lifecycle first...
 
 mvn site install
 
 vs
 
 mvn install site
 
 ;-)

Apart from the fact that then the version configured in the pluginMgmt is
ignored ... :-)

- Jörg


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



Re: Maven 1.0.2 Errors

2009-07-10 Thread Martijn Dashorst
Not sure how you compare things in your assertions, but it may be
someone in your team who has different svn client settings (EOL style)
or not the correct encoding for the files. This is a certain way to
get strange test results. Write the comparison strings to a file and
open it with a hex editor to see the contents. Do this also on other
failing platforms to see if there's a difference.

Martijn

On Thu, Jul 9, 2009 at 6:53 AM, Dunstall,
Christophercdunst...@csu.edu.au wrote:
 Hi,

 Lately, I've been getting some really bizarre behaviour from running junit 
 tests in Maven 1.0.2.

 The tests were written in Eclipse, where they run fine.  However, when I run 
 a maven target, it runs the junit test but shows an error.  As a result, it 
 finishes up as the build has failed.

    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.74 sec
    [junit] Running au.edu.csu.ole.msi.impl.dao.test.WebMethodsTest
 Service: webmethods:pMDRTarget.flowservices:getCampusName?campusCode=A
 webmethods
 msi.flowservices
 getOutlineInfo
 webmethods
 msi.flowservices
 getOutlineInfo
    [junit] Tests run: 6, Failures: 0, Errors: 5, Time elapsed: 0.808 sec
    [junit] [ERROR] TEST au.edu.csu.ole.msi.impl.dao.test.WebMethodsTest FAILED

 You can see here that it output the information from the test as I expected, 
 but still had 'errors'.  Running the Stacktrace or verbose switch with maven 
 reveals absolutely nothing.

 To add even a more bizarre twist to it, some tests run fine with no errors on 
 my Macbook Pro, but on my colleagues Windows box it errors.

 More concering is that our continuum install also gets the errors (on a Unix 
 VM), and running the -Dmaven.test.failure.ignore=true switch isn't possible 
 to my knowledge.

 Has anyone seen this before or know what the problem is, it really is driving 
 me batty. :(

 Thanks,

 Chris Dunstall | Service Support - Applications
 Technology Integration/OLE Virtual Team
 Division of Information Technology | Charles Sturt University | Bathurst, NSW

 Ph: 02 63384818 | Fax: 02 63384181



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





-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.5 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.

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



RE: Putting instrumented classes on the classpath

2009-07-10 Thread lvdpal

Nobody else has any ideas?
-- 
View this message in context: 
http://www.nabble.com/Putting-instrumented-classes-on-the-classpath-tp24183679p24425518.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



How to use maven-scm-plugin with subversion and without a command line

2009-07-10 Thread Benson Margulies
The doc for the svn piece of the scm-plugin has several tantalizing
hints that suggest that there is some way to use an API to svn instead
of running commands. Since I've got some people on Windows with
cygwin, where the command line is not working, I'd like to try that
out. Could someone please post the recipe? I'd be willing to type it
into Confluence if I just knew what it was.

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



Re: Preventing Inclussion of Multiple Versions

2009-07-10 Thread daniel.green


Wes Wannemacher wrote:
 
 If you find some inconsistencies, let me know and I'll fix them up, 
 
Thank you! I appreciate the offer and will get back to you if I find any.

I switched to org.freemarker, and realized tabletags was the oddball and
excluded freemarker:freemarker from that. Problem solved!


Wes Wannemacher wrote:
 
 On Wednesday 08 July 2009 13:52:59 daniel.green wrote:
 daniel.green wrote:
  Apparently struts2-core is bringing in org.freemarker:freemarker

 And, uh, struts2-annotations (1.0.2) is bringing in
 freemarker:freemarker...!? You think they'd remain consistent

 
 I'm jumping in late (sorry), so I didn't see the original pom file. Why
 are you 
 bringing in such an old struts2-annotations? I'm pretty sure I did some
 work 
 on that recently and it has a later version. 
 
 If you find some inconsistencies, let me know and I'll fix them up, I'm
 gearing 
 up to roll another release in the near future, which includes (among other 
 things) updates to dependencies that we haven't touched in a while
 (commons-
 logging and things like that). 
 
 -Wes
 
 -- 
 Wes Wannemacher
 Author - Struts 2 In Practice 
 Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more
 http://www.manning.com/wannemacher
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Preventing-Inclussion-of-Multiple-Versions-tp24392573p24426841.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



Re: Site generation tutorials?

2009-07-10 Thread Fiona Mahon
I would like to hear an answer to this one too. I have a multimodule 
project also. Site generation only generations a site with the 
information contained in the parent.xml (that all the modules 
reference), and nothing from each of the modules e.g. there are no 
contributors listed as all this information is down deeper in the module 
poms. I can see that a site is generated under each module, but they are 
all their own independent sites and not linked together in the overall 
project site.


I've tried using a site.xml with the menu ref=modules option to even 
just get a link to each module site, but there are no modules listed 
under the Modules menu in the generated project site.


Anyways, an answer to David's question would help me too.

Fiona.


David C. Hicks wrote:

Is there a decent tutorial out there anywhere on how to build the
project site within Maven?  I've found nothing that I would consider
useful.  MDG is rather short on details, too.

I've got a multi-module project that I'm trying to get the site built
and deployed for.  It seems to build, but trying to examine the site is
fruitless.  Module links take me to the Maven site, and my custom pages
don't show up at all - the links appear to be broken.  I just can't find
any clear information that describes a process by which someone can
iteratively work on the site, as they might work on their code.

Any help?
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



[OT] The real identity of Martin (WAS Re: Site generation tutorials?)

2009-07-10 Thread Antonio Petrelli
Aha! Martin you are a bot then! You seem to have some sort of
text-scraping sw that tries to identify questions and try to answer.

Antonio

2009/7/9 Martin Gainty mgai...@hotmail.com:

 seems specific to web-application basedir or build folder parameters
 what is the J2EE Server you are using?
 did you supply all the necessary environment and .properties?

 for example in building axis in adb-codegen/pom.xml i have
 project basedir=. 
 !-- later on i use the basedire which is current folder to specify build dir 
 --
                                property name=maven.build.dir 
 location=${basedir}/target/
                                property name=schema.source.dir 
 value=test-resources/xsd/
                                property name=schema.output.base.dir 
 value=target/schema/
                                property name=schema.generated.src.dir 
 value=${schema.output.base.dir}/src/
                                property name=schema.generated.classes.dir
                                          
 value=${schema.output.base.dir}/classes/

 ?
 Martin
 __
 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, 9 Jul 2009 14:38:59 -0400
 From: dhi...@i-hicks.org
 To: users@maven.apache.org
 Subject: Site generation tutorials?

 Is there a decent tutorial out there anywhere on how to build the
 project site within Maven?  I've found nothing that I would consider
 useful.  MDG is rather short on details, too.

 I've got a multi-module project that I'm trying to get the site built
 and deployed for.  It seems to build, but trying to examine the site is
 fruitless.  Module links take me to the Maven site, and my custom pages
 don't show up at all - the links appear to be broken.  I just can't find
 any clear information that describes a process by which someone can
 iteratively work on the site, as they might work on their code.

 Any help?
 Thanks,
 Dave


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


 _
 Lauren found her dream laptop. Find the PC that’s right for you.
 http://www.microsoft.com/windows/choosepc/?ocid=ftp_val_wl_290

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



Re: Excluding all jboss provided

2009-07-10 Thread daniel.green

Thank you for the idea! Creating a dependencyManagement section for jboss
libraries would probably useful for more people than just me. Any
suggestions as to where I should start? That's a fair amount of data to
collect...


Anders Hammar wrote:
 
 Starting with Maven 2.0.9 there is a possibility to import another
 pom. That pom could have the dependencyManagement you're talking
 about. However, I don't think that such a pom already exists, so you
 need to create it yourself. However, when that's done you could reuse
 it.
 
 More info:
 http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies
 
 /Anders
 
 On Thu, Jul 9, 2009 at 23:41, daniel.greenoctober...@gmail.com wrote:

 Do I have to go through and manually mark each dependency that jboss
 already
 includes as provided or is there a way to inherit something that does
 this
 for me? Perhaps a list?
 --
 View this message in context:
 http://www.nabble.com/Excluding-all-jboss-provided-tp24418333p24418333.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
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Excluding-all-jboss-provided-tp24418333p24428071.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



Filesize changes during assembly

2009-07-10 Thread bshepherd

I have a Solaris executable checked in to my subversion repository. When I
build on windows via maven, all is fine. When I build on Red Hat (server
where Hudson performs the build), the file size is the wrong size.

File size in the repository is 753004. After build on Red Hat, the file size
in the assembled directory/tar  is 956776. 

After the build, I did a find and noticed the file (capturepacket2) is in
several locations:

find . -name capturepacket2
./pbsn-distribution/target/pbsn-distribution-2.0-SNAPSHOT-export-pcs.dir/npp_pbsn/bin/capturepacket2
./pbsn-distribution/target/pbsn-distribution-2.0-SNAPSHOT-export-lds.dir/npp_pbsn/bin/capturepacket2
./pbsn-distribution/target/archive-tmp/fileSetFormatter.1359454028.tmp/capturepacket2
./pbsn-distribution/target/archive-tmp/fileSetFormatter.1660537483.tmp/capturepacket2
./pbsn-distribution/target/archive-tmp/fileSetFormatter.1413606523.tmp/capturepacket2
./pbsn-distribution/target/archive-tmp/fileSetFormatter.573642392.tmp/capturepacket2
./pbsn/src/main/exec/capturepacket2

Files size for ./pbsn/src/main/exec/capturepacket2 is correct. All other
directories have the filesize as larger.

The file used to be named capturepacket. Trying to solve this thing thinking
I might have a rouge copy someplace, I change the file name to
capturepacket2, but I get the same result.

Any Ideas?

-- 
View this message in context: 
http://www.nabble.com/Filesize-changes-during-assembly-tp24428092p24428092.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



Re: Site generation tutorials?

2009-07-10 Thread Benson Margulies
Due to some issues that are visible in JIRA for MSITE, I found that
some trickery was needed to get the site plugin version 1.2 to work
for a multi-module project with a structure of top-level, parent,
users-of-parent.

In the top-level POM:

properties
!-- where to deploy the site --

site.deploy.basescp://hudson.basistech.net/home/projects/rex2009/site.deploy.base
!-- where to see it when deployed --
url.basehttp://hudson.basistech.net:8280/projects/rex2009/url.base
/properties

url${url.base}/url


distributionManagement
site
  idrex2009.website/id
  url${site.deploy.base}/url
/site
/distributionManagement

In each child POM, including the parent:

!-- what goes in the POM for a project named 'common' --

properties

site.deploy.basescp://hudson.basistech.net/home/projects/rex2009/site.deploy.base
url.basehttp://hudson.basistech.net:8280/projects/rex2009/url.base
/properties

url${url.base}/url


Then, I have not customized site.xml for the top-level project, and I have.

I find that, with this, mvn clean site:site site:deploy

works.

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



Re: mvn assembly:assembly won't package jars and ears, but mvn package will

2009-07-10 Thread David Weintraub
I actually don't want to install these jars/wars/hars into my repository
because they aren't really separate components. No other project of ours
uses them. Instead, I'm trying to build a multi-part project which consists
of two built wars, a built har, three built jars, plus all of the dependent
jar files into a single ear. No need to waste the diskspace (even though
install only puts them into my local .m2 repository)

The problem I'm having is getting Maven to understand that the jars it needs
aren't in the repository, but are the ones it just built earlier in the
project. This works beautifully when I do:

  *$ mvn package*

Everything builds as I expect it too. It's that when I do:

*  $ mvn assembly:assembly*

that everything fails.

According to the book, the assembly:assembly goal executes all the poms up
to the package lifecycle. That sounds like it first does a:

*   $ mvn package*

before it attempts to create the assembly. I have no problems with that. The
problem I have is that when the assembly:assembly step executes the
package lifecycle on all the poms, the build fails because suddenly Maven
cannot figure out that the jars it needs were built earlier in the build
process.

Even stranger is I discovered after I sent out the email, that this:

   *$ mvn clean package assembly:assembly
*
works! Suddenly. the assembly is built.

Can someone explain the difference between
*
$ mvn clean package
$ mvn assembly:assembly*

and

  * $ mvn clean package assembly:assembly*

Why does the first one fail because of the dependency confusion, and the
second one works fine?

On Thu, Jul 9, 2009 at 2:34 PM, Tim O'Brien tobr...@discursive.com wrote:

 David,

 It looks like
 com.solbright.adinventory.projects.base:jar:jar:2.1.2-SNAPSHOT
 can't be found in the local repository.   Instead of running
 assembly:assembly by itself, try:  mvn install assembly:assembly

 Better yet, why not just bind the assembly goal to the package phase
 of the project that is going to produce the assembly? like this:
 http://tr.im/rBBw

 Maybe binding to the package phase isn't the right solution for you,
 if you are looking for a list of phases, see  http://tr.im/rBAq


 On Thu, Jul 9, 2009 at 12:49 PM, David Weintraubqazw...@gmail.com wrote:
  We have a project we're converting over to Maven. The structure is a bit
  convoluted:
 
  Project Root
apps.war: Builds apps.war
aimwebservices: Builds aimwebservices.war
ear: Builds adinventory.ear. Contains all other modules
projects
   adplanning: Builds adplanning.jar
   base
  jar: Builds base.jar
  har: Builds base-hib.har
  servlet: Builds base-ui.jar
 
  For various reasons, we do not want the version names in any of these
 files
  we create.
 
  The project is structured so that most of the components depend upon
  base.jar. The aimwebservices.war and apps.war also depend upon the
  base-hib.har and the base-ui.jar.
 
  The adinventory.ear file contains all of the built wars, hars, and jars.
  Each component directory contains a pom.xml.
 
  When I do a mvn package, everything is built, and the final result is
 the
  adinventory.ear file which contains all the jars, hars, and wars that it
 is
  suppose to have. This is what I want. Beautiful.
 
  The problem is I want to package this adinventory.ear file with a bunch
 of
  scripts, configuration files, and other items that are in the
  src/main/instance directory. I configured a assembly, and am using the
  assembly plugin. The problem is when I run mvn assembly:assembly, I get
  the following error:
 
  [INFO]
  
  [INFO] Building servlet
  [INFO]
  
  [INFO] [resources:resources]
  [WARNING] Using platform encoding (UTF-8 actually) to copy filtered
  resources, i.e. build is platform dependent!
  [INFO] Copying 16 resources
  [INFO] snapshot
 com.solbright.adinventory.projects.base:jar:2.1.2-SNAPSHOT:
  checking for updates from snapshot
  Downloading:
 
 http://aladdin.solbright.com:8082/nexus/content/repositories/snapshots//com/solbright/adinventory/projects/base/jar/2.1.2-SNAPSHOT/jar-2.1.2-SNAPSHOT.jar
  [INFO] Unable to find resource
  'com.solbright.adinventory.projects.base:jar:jar:2.1.2-SNAPSHOT' in
  repository snapshot
  (http://aladdin.solbright.com:8082/nexus/content/repositories/snapshots/
 )
  [INFO]
  
  [ERROR] BUILD ERROR
  [INFO]
  
  [INFO] Failed to resolve artifact.
 
  Missing:
  --
  1) com.solbright.adinventory.projects.base:jar:jar:2.1.2-SNAPSHOT
 
   Try downloading the file manually from the project website.
 
   Then, install it using the command:
   mvn install:install-file
  -DgroupId=com.solbright.adinventory.projects.base -DartifactId=jar
  

Problem getting javasvn to work with build number plugin Click to flag this post

2009-07-10 Thread stug23

Has anyone been successful in getting the javasvn provider for the build
number plugin to work?

I posted this question to codehaus-mojo/mojo-user forum with the details:

http://www.nabble.com/Problem-getting-javasvn-to-work-with-build-number-plugin-td24419164.html

TIA!


-- 
View this message in context: 
http://www.nabble.com/Problem-getting-javasvn-to-work-with-build-number-plugin-Click-to-flag-this-post-tp24428652p24428652.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



Re: mvn assembly:assembly won't package jars and ears, but mvn package will

2009-07-10 Thread Stephen Connolly
2009/7/10 David Weintraub qazw...@gmail.com

 I actually don't want to install these jars/wars/hars into my repository
 because they aren't really separate components. No other project of ours
 uses them. Instead, I'm trying to build a multi-part project which consists
 of two built wars, a built har, three built jars, plus all of the dependent
 jar files into a single ear. No need to waste the diskspace (even though
 install only puts them into my local .m2 repository)

 The problem I'm having is getting Maven to understand that the jars it
 needs
 aren't in the repository, but are the ones it just built earlier in the
 project. This works beautifully when I do:

  *$ mvn package*

 Everything builds as I expect it too. It's that when I do:

 *  $ mvn assembly:assembly*

 that everything fails.

 According to the book, the assembly:assembly goal executes all the poms up
 to the package lifecycle. That sounds like it first does a:

 *   $ mvn package*

 before it attempts to create the assembly. I have no problems with that.
 The
 problem I have is that when the assembly:assembly step executes the
 package lifecycle on all the poms, the build fails because suddenly Maven
 cannot figure out that the jars it needs were built earlier in the build
 process.

 Even stranger is I discovered after I sent out the email, that this:

   *$ mvn clean package assembly:assembly
 *
 works! Suddenly. the assembly is built.

 Can someone explain the difference between
 *
$ mvn clean package
$ mvn assembly:assembly*

 and

  * $ mvn clean package assembly:assembly*

 Why does the first one fail because of the dependency confusion, and the
 second one works fine?


The first one is two _separate_ invocations of Maven.  invocations of Maven
can only share artifacts via the local / remote repositories... so you need
to run up as far as at least the *install* phase to allow the artifacts be
accessed from a subsequent invocation.

so

$ mvn clean install
$ mvn assembly:assembly

would work (but this is not the solution you want)

The second is_one single invocation of Maven_ thus the assembly:assembly
mojo can find the artifacts that were attached to the reactor during the
earlier phases/mojo executions.

You should always try to make sure that your build will build successfully
when you have met the following conditions:

1. Blow away your local repository, e.g. rm -rf ~/.m2/repository
2. Do a clean build without populating the local repository, e.g. mvn clean
verify

This will result in your build being one of the holy grail maven builds.

Such builds nearly always just work(TM) with the maven release plugin, and
are generally considered to be the dog's bollicks

If you want your build to be such a build, then what you need to do is bind
an execution of the assembly plugin to a phase = package.

Then all you need to do to package your project is

$ mvn clean package

and you are done!

-Stephen


 On Thu, Jul 9, 2009 at 2:34 PM, Tim O'Brien tobr...@discursive.com
 wrote:

  David,
 
  It looks like
  com.solbright.adinventory.projects.base:jar:jar:2.1.2-SNAPSHOT
  can't be found in the local repository.   Instead of running
  assembly:assembly by itself, try:  mvn install assembly:assembly
 
  Better yet, why not just bind the assembly goal to the package phase
  of the project that is going to produce the assembly? like this:
  http://tr.im/rBBw
 
  Maybe binding to the package phase isn't the right solution for you,
  if you are looking for a list of phases, see  http://tr.im/rBAq
 
 
  On Thu, Jul 9, 2009 at 12:49 PM, David Weintraubqazw...@gmail.com
 wrote:
   We have a project we're converting over to Maven. The structure is a
 bit
   convoluted:
  
   Project Root
 apps.war: Builds apps.war
 aimwebservices: Builds aimwebservices.war
 ear: Builds adinventory.ear. Contains all other modules
 projects
adplanning: Builds adplanning.jar
base
   jar: Builds base.jar
   har: Builds base-hib.har
   servlet: Builds base-ui.jar
  
   For various reasons, we do not want the version names in any of these
  files
   we create.
  
   The project is structured so that most of the components depend upon
   base.jar. The aimwebservices.war and apps.war also depend upon the
   base-hib.har and the base-ui.jar.
  
   The adinventory.ear file contains all of the built wars, hars, and
 jars.
   Each component directory contains a pom.xml.
  
   When I do a mvn package, everything is built, and the final result is
  the
   adinventory.ear file which contains all the jars, hars, and wars that
 it
  is
   suppose to have. This is what I want. Beautiful.
  
   The problem is I want to package this adinventory.ear file with a bunch
  of
   scripts, configuration files, and other items that are in the
   src/main/instance directory. I configured a assembly, and am using the
   assembly plugin. The problem is when I run mvn assembly:assembly, I
 get
   the following error:
  
   

Re: mvn assembly:assembly won't package jars and ears, but mvn package will

2009-07-10 Thread David Weintraub
Still a bit confused. The Assembly plugin's documentation says it runs a
lifecyle package before creating the assembly.  The only thing I can think
of is that assembly:assembly is running a separate package against each
and every pom.xml separately.

I did a mvn clean verify and everything runs.

I can now do a:

*$ mvn clean package assembly:assembly
*
And that works. It builds exactly what I want.

Now, I want to combine in the assembly step in the package goal. I add the
following in my root pom.xml:

*executions
  execution
idBuild Adinventory Package/id
phasepackage/phase
goals
  goalsingle/goal
/goals
  /execution
/executions
*
Right? (I've attached my full root pom.xml to this email).

Run

   $ mvn clean package

And, I get the following error (entire output is in package.out file which
is enclosed):

[*INFO] Building adinventory*
*[INFO]task-segment: [package]*
*[INFO]
*
*[INFO] [site:attach-descriptor]*
*[INFO] [assembly:single {execution: Build Adinventory Package}]*
*[INFO] Reading assembly descriptor: src/main/assembly/bin.xml*
*[INFO]
*
*[ERROR] BUILD ERROR*
*[INFO]
*
*[INFO] Failed to create assembly: Error adding file to archive:
/home/dweintraub/builds/adinventory-trunk/ear/target/adinventory.ear isn't a
file.*

Now, the adinventory.ear file that built before isn't building?

Look at the beginning of the build process:

[*INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO]   adinventory-projects
[INFO]   base
[INFO]   jar
[INFO]   servlet
[INFO]   har
[INFO]   adplanning
[INFO]   adinventory
[INFO]   aimwebservices.war
[INFO]   jboss-init
[INFO]   apps.war
[INFO]   adinventory.ear
*

Wait a second, it's doing adinventory (the root pom.xml) before building
adinventory.ear?

How can I specify the dependency order. That the adinventory root project
needs to be built after adinventory.ear?

As far as I can tell, I have the right dependencies set in each pom.xml.

On Fri, Jul 10, 2009 at 12:24 PM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 2009/7/10 David Weintraub qazw...@gmail.com

  I actually don't want to install these jars/wars/hars into my repository
  because they aren't really separate components. No other project of ours
  uses them. Instead, I'm trying to build a multi-part project which
 consists
  of two built wars, a built har, three built jars, plus all of the
 dependent
  jar files into a single ear. No need to waste the diskspace (even though
  install only puts them into my local .m2 repository)
 
  The problem I'm having is getting Maven to understand that the jars it
  needs
  aren't in the repository, but are the ones it just built earlier in the
  project. This works beautifully when I do:
 
   *$ mvn package*
 
  Everything builds as I expect it too. It's that when I do:
 
  *  $ mvn assembly:assembly*
 
  that everything fails.
 
  According to the book, the assembly:assembly goal executes all the poms
 up
  to the package lifecycle. That sounds like it first does a:
 
  *   $ mvn package*
 
  before it attempts to create the assembly. I have no problems with that.
  The
  problem I have is that when the assembly:assembly step executes the
  package lifecycle on all the poms, the build fails because suddenly Maven
  cannot figure out that the jars it needs were built earlier in the build
  process.
 
  Even stranger is I discovered after I sent out the email, that this:
 
*$ mvn clean package assembly:assembly
  *
  works! Suddenly. the assembly is built.
 
  Can someone explain the difference between
  *
 $ mvn clean package
 $ mvn assembly:assembly*
 
  and
 
   * $ mvn clean package assembly:assembly*
 
  Why does the first one fail because of the dependency confusion, and the
  second one works fine?
 

 The first one is two _separate_ invocations of Maven.  invocations of Maven
 can only share artifacts via the local / remote repositories... so you need
 to run up as far as at least the *install* phase to allow the artifacts be
 accessed from a subsequent invocation.

 so

 $ mvn clean install
 $ mvn assembly:assembly

 would work (but this is not the solution you want)

 The second is_one single invocation of Maven_ thus the assembly:assembly
 mojo can find the artifacts that were attached to the reactor during the
 earlier phases/mojo executions.

 You should always try to make sure that your build will build successfully
 when you have met the following conditions:

 1. Blow away your local repository, e.g. rm -rf ~/.m2/repository
 2. Do a clean build without populating the local repository, e.g. mvn clean
 verify

 This will result in your build being one of the holy grail maven builds.

 Such builds nearly 

Re: mvn assembly:assembly won't package jars and ears, but mvn package will

2009-07-10 Thread Tim O'Brien
Move your assembly into a project separate from the root and then make
it dependent on the ear project.

Don't reference an artifact across project boundaries using relative
directories in an assembly descriptor.  Declare dependencies and use
the local repository as the medium to store and retrieve the
dependencies for a single project.

Tim

On Fri, Jul 10, 2009 at 2:04 PM, David Weintraubqazw...@gmail.com wrote:
 Still a bit confused. The Assembly plugin's documentation says it runs a
 lifecyle package before creating the assembly.  The only thing I can think
 of is that assembly:assembly is running a separate package against each
 and every pom.xml separately.

 I did a mvn clean verify and everything runs.

 I can now do a:

     $ mvn clean package assembly:assembly

 And that works. It builds exactly what I want.

 Now, I want to combine in the assembly step in the package goal. I add the
 following in my root pom.xml:

     executions
   execution
     idBuild Adinventory Package/id
     phasepackage/phase
     goals
   goalsingle/goal
     /goals
   /execution
     /executions

 Right? (I've attached my full root pom.xml to this email).

 Run

    $ mvn clean package

 And, I get the following error (entire output is in package.out file which
 is enclosed):

 [INFO] Building adinventory
 [INFO]    task-segment: [package]
 [INFO]
 
 [INFO] [site:attach-descriptor]
 [INFO] [assembly:single {execution: Build Adinventory Package}]
 [INFO] Reading assembly descriptor: src/main/assembly/bin.xml
 [INFO]
 
 [ERROR] BUILD ERROR
 [INFO]
 
 [INFO] Failed to create assembly: Error adding file to archive:
 /home/dweintraub/builds/adinventory-trunk/ear/target/adinventory.ear isn't a
 file.

 Now, the adinventory.ear file that built before isn't building?

 Look at the beginning of the build process:

 [INFO] Scanning for projects...
 [INFO] Reactor build order:
 [INFO]   adinventory-projects
 [INFO]   base
 [INFO]   jar
 [INFO]   servlet
 [INFO]   har
 [INFO]   adplanning
 [INFO]   adinventory
 [INFO]   aimwebservices.war
 [INFO]   jboss-init
 [INFO]   apps.war
 [INFO]   adinventory.ear

 Wait a second, it's doing adinventory (the root pom.xml) before building
 adinventory.ear?

 How can I specify the dependency order. That the adinventory root project
 needs to be built after adinventory.ear?

 As far as I can tell, I have the right dependencies set in each pom.xml.

 On Fri, Jul 10, 2009 at 12:24 PM, Stephen Connolly
 stephen.alan.conno...@gmail.com wrote:

 2009/7/10 David Weintraub qazw...@gmail.com

  I actually don't want to install these jars/wars/hars into my repository
  because they aren't really separate components. No other project of ours
  uses them. Instead, I'm trying to build a multi-part project which
  consists
  of two built wars, a built har, three built jars, plus all of the
  dependent
  jar files into a single ear. No need to waste the diskspace (even though
  install only puts them into my local .m2 repository)
 
  The problem I'm having is getting Maven to understand that the jars it
  needs
  aren't in the repository, but are the ones it just built earlier in the
  project. This works beautifully when I do:
 
   *$ mvn package*
 
  Everything builds as I expect it too. It's that when I do:
 
  *  $ mvn assembly:assembly*
 
  that everything fails.
 
  According to the book, the assembly:assembly goal executes all the poms
  up
  to the package lifecycle. That sounds like it first does a:
 
  *   $ mvn package*
 
  before it attempts to create the assembly. I have no problems with that.
  The
  problem I have is that when the assembly:assembly step executes the
  package lifecycle on all the poms, the build fails because suddenly
  Maven
  cannot figure out that the jars it needs were built earlier in the build
  process.
 
  Even stranger is I discovered after I sent out the email, that this:
 
    *$ mvn clean package assembly:assembly
  *
  works! Suddenly. the assembly is built.
 
  Can someone explain the difference between
  *
     $ mvn clean package
     $ mvn assembly:assembly*
 
  and
 
   * $ mvn clean package assembly:assembly*
 
  Why does the first one fail because of the dependency confusion, and the
  second one works fine?
 

 The first one is two _separate_ invocations of Maven.  invocations of
 Maven
 can only share artifacts via the local / remote repositories... so you
 need
 to run up as far as at least the *install* phase to allow the artifacts be
 accessed from a subsequent invocation.

 so

 $ mvn clean install
 $ mvn assembly:assembly

 would work (but this is not the solution you want)

 The second is_one single invocation of Maven_ thus the assembly:assembly
 mojo can find the 

maven spring eclipse and properties/spring config

2009-07-10 Thread Vincent Fumo
I'm converting an old project to maven and I have a question re: spring.
This project has about 20 spring config files and it reads them all in on
startup and uses the  In addition I have 4 properties files
(local/dev/qa/prod) that I'd like to use to inject/filter/substitute values
into them depending on the build. Lastly I am using the eclipse plugin to
generate an eclipse project.
What I need to know is the following :

1) where should I put the spring files? I am considering
src/main/resources/spring
2) how should I best filter the props files? Should I use maven for this
(using profiles in some way), or should I load the files in the app and use
the spring properties configurator?
3) what is the best way to use the eclipse plugin to generate a project
where I can run the app and it can see the newly filtered spring files
(instead of the src ones)?

Can anyone help me out? I'd certainly give more info if needed.