Re: Why Maven is Hard?
Isn't this sort of a catch-22? People are saying I don't get maven, it's too complex. Now it's time for them to give something back and document it? How do you propose they do that? Start at the source and pore through it to explain it? Saying that is sort of a cop-out, IMO. I think that the problem is that we have maven in 5 minutes and then the rest of the docs assume that people are experts with it - the 2 books mentioned earlier are useful, but I think people want something more approachable and contextual. One other thing is the navigation - I find it very difficult to get around the maven site in any meaningful way. There are many inter-dependent concepts and components, and each area's documentation assumes that the reader understands the other areas. For a beginner, that is rarely if ever the case. I'm not trying to add the rants, just provide some constructive criticism. Larry On 9/24/07, Michael McCallum [EMAIL PROTECTED] wrote: On Tuesday 25 September 2007 01:10, Ryan Moquin wrote: If people are build their core infrastructure around Maven to the point where they feel like they should give the project developers a hard time due to something as simple as documentation, don't you think then that it's time to contribute? I concur wholeheartedly... -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: annotations are not supported in -source 1.3
http://docs.codehaus.org/display/MAVEN/Java+5+Annotations+for+Plugins On 9/13/07, Kyle.Bober [EMAIL PROTECTED] wrote: I have been using Maven for quite sometime and this is the first JDK6 project POM I have created. I am running into a compilation issue using the compiler:compile goal... This is what I get annotations are not supported in -source 1.3 (use -source 5 or higher to enable annotations) @WebService I have my JAVA_HOME env variable set to point to JDK6 and I can compile the java file fine using javac command but when I try using mvn compile I receive the above error... I feel like a goof not being able to figure this one out. Is there a way to set in the Maven POM file the JDK version to compile against??? Thanks for anyone's help in advance... -Kyle -- View this message in context: http://www.nabble.com/annotations-are-not-supported-in--source-1.3-tf4435690s177.html#a12654771 Sent from the Maven - Users mailing list archive at Nabble.com. - 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]
Re: Cobertura broken ?
Is this bug *ever* going to be fixed? It's been like this for many months... Larry On 7/24/07, Mac-Systems [EMAIL PROTECTED] wrote: Dennis Lundberg schrieb: That is odd. Version 2.1 of the plugin does not use Cobertura 1.9. That has just recently been added to the 2.2-SNAPSHOT version, which is not yet stable. Have you added a dependency on cobertura (not the plugin) yourself somewhere? No. I only listet it in pluginDependecies I tried version 2.2-SNAPSHOT also without luck. i will give 2.0 a try. - jens There is a reported issue for this, but that is against version 2.2 of the plugin: http://jira.codehaus.org/browse/MCOBERTURA-71 Mac-Systems wrote: plugin groupIdorg.codehaus.mojo/groupId artifactIdcobertura-maven-plugin/artifactId version2.1/version If i added the cobertura to my pom and run mvn site i get error like: [ERROR] There are test failures. [INFO] Preparing surefire-report:report-only [INFO] No goals needed for project - skipping [INFO] Preparing cobertura:cobertura [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Nothing to compile - all classes are up to date [INFO] [cobertura:instrument] [INFO] Cobertura 1.9 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file Cobertura: Loaded information on 418 classes. Instrumenting 418 files to /home/mavensite/continuum-1.0.3/apps/continuum/working-directory/1/Project/target/generated-classes/cobertura Cobertura: Saved information on 418 classes. Instrument time: 2321ms [INFO] Instrumentation was successful. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Couldn't find 'cobertura' artifact in plugin dependencies [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Couldn't find 'cobertura' artifact in plugin dependencies at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:896) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:739) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:530) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) 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) Caused by: org.apache.maven.plugin.MojoExecutionException: Couldn't find 'cobertura' artifact in plugin dependencies at org.codehaus.mojo.cobertura.CoberturaInstrumentMojo.addCoberturaDependenciesToTestClasspath(CoberturaInstrumentMojo.java:164) at org.codehaus.mojo.cobertura.CoberturaInstrumentMojo.execute(CoberturaInstrumentMojo.java:122) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 20 more [INFO] [INFO] Total time: 46 seconds [INFO] Finished at: Tue Jul 24 14:17:14 CEST 2007 [INFO] Final Memory: 30M/54M [INFO]
Re: Cobertura broken ?
Am I the only one that finds it profoundly ironic that a testing tool is broken? The cobbler's children have no shoes? Larry On 7/24/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Mac-Systems wrote: I tested 2.0 with an -U (force update) Again it is broken like shown below. Then you would get 2.1 which is the latest released version. How can a stable version break ? It is called a regression [1] and happens to many systems. [1] http://en.wikipedia.org/wiki/Software_regression - Jens That is odd. Version 2.1 of the plugin does not use Cobertura 1.9. That has just recently been added to the 2.2-SNAPSHOT version, which is not yet stable. Have you added a dependency on cobertura (not the plugin) yourself somewhere? There is a reported issue for this, but that is against version 2.2 of the plugin: http://jira.codehaus.org/browse/MCOBERTURA-71 Mac-Systems wrote: plugin groupIdorg.codehaus.mojo/groupId artifactIdcobertura-maven-plugin/artifactId version2.1/version If i added the cobertura to my pom and run mvn site i get error like: [ERROR] There are test failures. [INFO] Preparing surefire-report:report-only [INFO] No goals needed for project - skipping [INFO] Preparing cobertura:cobertura [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Nothing to compile - all classes are up to date [INFO] [cobertura:instrument] [INFO] Cobertura 1.9 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file Cobertura: Loaded information on 418 classes. Instrumenting 418 files to /home/mavensite/continuum-1.0.3/apps/continuum/working-directory/1/Project/target/generated-classes/cobertura Cobertura: Saved information on 418 classes. Instrument time: 2321ms [INFO] Instrumentation was successful. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Couldn't find 'cobertura' artifact in plugin dependencies [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Couldn't find 'cobertura' artifact in plugin dependencies at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:896) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:739) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:530) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) 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) Caused by: org.apache.maven.plugin.MojoExecutionException: Couldn't find 'cobertura' artifact in plugin dependencies at org.codehaus.mojo.cobertura.CoberturaInstrumentMojo.addCoberturaDependenciesToTestClasspath(CoberturaInstrumentMojo.java:164) at org.codehaus.mojo.cobertura.CoberturaInstrumentMojo.execute(CoberturaInstrumentMojo.java:122) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 20 more [INFO]
Re: Runtime dependencies in Eclipse classpath
Eclipse is not Maven, and Maven is not Eclipse - you are kind of comparing apples to orangutans. Eclipse makes no differentiation between compile time and run time, but Maven is different - it's a build tool, not an IDE. As I understand it, compile time means what I need to compile this thing, but runtime means what I need to run the beast. An example would be JDBC drivers. I don't need the Oracle JDBC driver jar to compile my application (unless I did something really deeply profoundly wrong) but I do need it to *run* my application. Larry On 5/16/07, lightbulb432 [EMAIL PROTECTED] wrote: So runtime seems very similar to the compile scope type. Could somebody please explain the difference? The Maven documentation seems to imply something about transitive dependencies, but I don't understand what it's trying to say. Thanks. Larry Meadors-2 wrote: I'd assume that it's there so that you can run your app from the IDE - that's the behavior I'd expect. Larry On 5/16/07, lightbulb432 [EMAIL PROTECTED] wrote: Why are dependencies with a scope of runtime added to Eclipse's .classpath file? I thought the point of runtime is that it's not a compile-time dependency; therefore, why the addition to the .classpath? Perhaps someone can correct me, but my understanding of runtime scope is that it is not included in the compile-time classpath, but is added to the JAR or WAR upon packaging - is this an accurate statement? Thanks. -- View this message in context: http://www.nabble.com/Runtime-dependencies-in-Eclipse-classpath-tf3769914s177.html#a10658508 Sent from the Maven - Users mailing list archive at Nabble.com. - 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] -- View this message in context: http://www.nabble.com/Runtime-dependencies-in-Eclipse-classpath-tf3769914s177.html#a10658694 Sent from the Maven - Users mailing list archive at Nabble.com. - 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]
Re: Runtime dependencies in Eclipse classpath
I'd assume that it's there so that you can run your app from the IDE - that's the behavior I'd expect. Larry On 5/16/07, lightbulb432 [EMAIL PROTECTED] wrote: Why are dependencies with a scope of runtime added to Eclipse's .classpath file? I thought the point of runtime is that it's not a compile-time dependency; therefore, why the addition to the .classpath? Perhaps someone can correct me, but my understanding of runtime scope is that it is not included in the compile-time classpath, but is added to the JAR or WAR upon packaging - is this an accurate statement? Thanks. -- View this message in context: http://www.nabble.com/Runtime-dependencies-in-Eclipse-classpath-tf3769914s177.html#a10658508 Sent from the Maven - Users mailing list archive at Nabble.com. - 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]
Build-number plug-in and install goal conflict?
I am trying to use the build number plug-in:
http://commons.ucalgary.ca/projects/maven-buildnumber-plugin/howto.html
I changed my pom to use
${project.artifactId}-${project.version}-r${buildNumber} as the final
name, and it works great for all of the files built, but for the pom,
it messes up the name like this:
blah-SNAPSHOT-r${buildNumber}.pom
blah-SNAPSHOT-r509202.jar
Any ideas why the pom is being misnamed..or more importantly, how to fix it?
Larry
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Overriding properties in a dependency's pom.xml
On 1/4/07, mraible [EMAIL PROTECTED] wrote: Is Maven like Ant in that properties are immutable? If so, can I hook into the lifecycle sooner and set this dao.framework property from the local pom.xml? I was thinking the same thing - it sure is acting like that is the case, no? Larry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repositories with just older software ?
I know that for the iBATIS project, we are just starting to use maven, so are just getting ready to start publishing it. Larry On 11/27/06, Javier Leyba [EMAIL PROTECTED] wrote: Hi I'm trying to use maven with my projects but I found every jar file I need is totally older in maven repositories. For example, activemq (and everything related to this project), springframework, iBatis Is ibiblio.org and older repository, am I making a mistake or just nobody actualize repositories packages ? Thanks in advance -- Javier Leyba Barcelona - Spain http://blog.leyba.com.ar - 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]
Re: Using the assembly plugin to build a stand-alone application
Hmm, no, not really. I have dependencies on oracle (ojdbc), spring, mail, activation, commons-net, log4j, ibatis-common, and ibatis-sqlmap in my project. I want to have my jar, and all of the jars required to run it somewhere in the target directory. Larry On 11/20/06, pjungwir [EMAIL PROTECTED] wrote: Hi Larry, I believe the descriptorId is required. You must also reference assembly.xml from your POM by giving the assembly plugin a configuration like this: configuration descriptorassembly.xml/descriptor /configuration But the 4 files result is correct, I think. What's in them? The jar should contain only your current project's classes. That is not the result of the assembly plugin, but of the jar plugin (probably running automatically on account of jar packaging). The other three files are coming from the assembly plugin. What's in them? You should see your jar plus your dependency jars. That's what you wanted, right? Paul Larry Meadors-2 wrote: Thanks, Paul - I added that as a file named assembly.xml in the directory with my pom.xml in it. I then added this to my pom (in the build/plugins section): === plugin artifactIdmaven-assembly-plugin/artifactId version2.0-beta-1/version configuration descriptorIdbin/descriptorId descriptors descriptor./assembly.xml/descriptor /descriptors finalNamemarcdelivery/finalName outputDirectorytarget/assembly/outputDirectory workDirectorytarget/assembly/work/workDirectory /configuration /plugin === But it still only creates 4 files: - target/marc-delivery-1.0-SNAPSHOT.jar - target/assembly/marcdelivery-bin.tar.gz - target/assembly/marcdelivery-bin.tar.bz2 - target/assembly/marcdelivery-bin.zip If I remove the descriptorIdbin/descriptorId line from the pom, I get only one file (target/marc-delivery-1.0-SNAPSHOT.jar) and an error. :( How do you have this in your project? Larry On 11/20/06, pjungwir [EMAIL PROTECTED] wrote: Hi Larry, I'm doing this, too. I think you'll need to create your own assembly descriptor. Here is mine: assembly idbin/id formats formattar.gz/format formatzip/format /formats fileSets fileSet directorytarget/directory outputDirectory/outputDirectory includes include*.jar/include !-- the jar of this project's classes -- /includes /fileSet fileSet directorytarget/scripts/directory outputDirectory/outputDirectory includes include*/include !-- clui scripts to launch the main java class -- /includes fileMode755/fileMode /fileSet fileSet directorytarget/doc/directory outputDirectory/outputDirectory includes include*/include /includes /fileSet /fileSets files file sourceREADME/source outputDirectory//outputDirectory fileMode644/fileMode !-- broken. see http://jira.codehaus.org/browse/MASSEMBLY-153 -- /file /files dependencySets dependencySet /dependencySet /dependencySets /assembly Paul Larry Meadors-2 wrote: Hi, I am using maven for the first time, so I apologize if this is a retarded question, but I can't find it anywhere in the docs. I have an app that is a command line app. I want to create an assembly that has my jar, along with the other jars that are listed as dependencies on it. I tried the jar-with-dependencies approach, and that *almost* works, but one of the jars i am including has some added files in the META-INF directory, and they do not end up getting included, so the app fails. Bummer. :( So, I guess i am looking for one of two things: 1) how can I get *all* the files in the uber jar. -or- 2) how can I get the assembly to just put all the individual dependent jars in a directory somewhere? I think I'd prefer #2, but at this point... I'll take what I can get! :-) TIA, Larry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Using-the-assembly-plugin-to-build-a-stand-alone-application-tf2670816s177.html#a7448665 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: Using the assembly plugin to build a stand-alone application
OK, I got it. I added a section to my pom for snapshot plugins like this: project ... ... pluginRepositories pluginRepository idmaven-snaps/id urlhttp://people.apache.org/repo/m2-snapshot-repository/url snapshots enabledtrue/enabled /snapshots releases enabledfalse/enabled /releases /pluginRepository /pluginRepositories ... /project Then to build, I do this: mvn install dependency:copy-dependencies That does a totally adequate job of putting everything out in my target directory for me. Thanks for your help, people. Larry On 11/20/06, Barrie Treloar [EMAIL PROTECTED] wrote: On 11/21/06, Larry Meadors [EMAIL PROTECTED] wrote: Hi, I am using maven for the first time, so I apologize if this is a retarded question, but I can't find it anywhere in the docs. I have an app that is a command line app. I want to create an assembly that has my jar, along with the other jars that are listed as dependencies on it. See * http://www.nabble.com/forum/ViewPost.jtp?post=5936062framed=yskin=177 * http://www.nabble.com/forum/ViewPost.jtp?post=5954911framed=yskin=177 for an example of how to do this. - 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]
Using the assembly plugin to build a stand-alone application
Hi, I am using maven for the first time, so I apologize if this is a retarded question, but I can't find it anywhere in the docs. I have an app that is a command line app. I want to create an assembly that has my jar, along with the other jars that are listed as dependencies on it. I tried the jar-with-dependencies approach, and that *almost* works, but one of the jars i am including has some added files in the META-INF directory, and they do not end up getting included, so the app fails. Bummer. :( So, I guess i am looking for one of two things: 1) how can I get *all* the files in the uber jar. -or- 2) how can I get the assembly to just put all the individual dependent jars in a directory somewhere? I think I'd prefer #2, but at this point... I'll take what I can get! :-) TIA, Larry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using the assembly plugin to build a stand-alone application
Thanks, Paul - I added that as a file named assembly.xml in the directory with my pom.xml in it. I then added this to my pom (in the build/plugins section): === plugin artifactIdmaven-assembly-plugin/artifactId version2.0-beta-1/version configuration descriptorIdbin/descriptorId descriptors descriptor./assembly.xml/descriptor /descriptors finalNamemarcdelivery/finalName outputDirectorytarget/assembly/outputDirectory workDirectorytarget/assembly/work/workDirectory /configuration /plugin === But it still only creates 4 files: - target/marc-delivery-1.0-SNAPSHOT.jar - target/assembly/marcdelivery-bin.tar.gz - target/assembly/marcdelivery-bin.tar.bz2 - target/assembly/marcdelivery-bin.zip If I remove the descriptorIdbin/descriptorId line from the pom, I get only one file (target/marc-delivery-1.0-SNAPSHOT.jar) and an error. :( How do you have this in your project? Larry On 11/20/06, pjungwir [EMAIL PROTECTED] wrote: Hi Larry, I'm doing this, too. I think you'll need to create your own assembly descriptor. Here is mine: assembly idbin/id formats formattar.gz/format formatzip/format /formats fileSets fileSet directorytarget/directory outputDirectory/outputDirectory includes include*.jar/include !-- the jar of this project's classes -- /includes /fileSet fileSet directorytarget/scripts/directory outputDirectory/outputDirectory includes include*/include !-- clui scripts to launch the main java class -- /includes fileMode755/fileMode /fileSet fileSet directorytarget/doc/directory outputDirectory/outputDirectory includes include*/include /includes /fileSet /fileSets files file sourceREADME/source outputDirectory//outputDirectory fileMode644/fileMode !-- broken. see http://jira.codehaus.org/browse/MASSEMBLY-153 -- /file /files dependencySets dependencySet /dependencySet /dependencySets /assembly Paul Larry Meadors-2 wrote: Hi, I am using maven for the first time, so I apologize if this is a retarded question, but I can't find it anywhere in the docs. I have an app that is a command line app. I want to create an assembly that has my jar, along with the other jars that are listed as dependencies on it. I tried the jar-with-dependencies approach, and that *almost* works, but one of the jars i am including has some added files in the META-INF directory, and they do not end up getting included, so the app fails. Bummer. :( So, I guess i am looking for one of two things: 1) how can I get *all* the files in the uber jar. -or- 2) how can I get the assembly to just put all the individual dependent jars in a directory somewhere? I think I'd prefer #2, but at this point... I'll take what I can get! :-) TIA, Larry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Using-the-assembly-plugin-to-build-a-stand-alone-application-tf2670816s177.html#a7448665 Sent from the Maven - Users mailing list archive at Nabble.com. - 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]
