Setting up Distribution Management inside of the pom.xml file
When you do a mvn deploy, Maven looks for a distributionManagement section of your POM. I would like to be able to move this distributionManagement section out of each project's POM. My developers shouldn't have to worry about it. I'd like to be able to put this in my build user's settings.xml file or in the settings.xml file inside the Maven home directory of my build system. That way, when we change the location of our release repository, I don't have to change all the various project POM files. Is this even possible? What about doing this in the company wide Super POM? I keep hearing about instituting a company wide Super POM, but can't find where this is suppose to go. My understanding is that the Super POM is inside the Maven JAR. Am I suppose to unjar the Maven JAR, modify the Super POM and then rejar the Maven JAR file? Or, is the company'e Super POM suppose to go somewhere else? -- David Weintraub qazw...@gmail.com
Re: zipping the outputDirectory using Assembly plugin
I had a similar issue. The easiest way to do this is with the antrun plugin. This will allow you to zip up these files before Maven does the package stage. On Mon, Oct 26, 2009 at 6:57 AM, singh_rajeev singhrajee...@gmail.comwrote: Hi I've the following lines of code in my assembly.xml moduleSet sources includeModuleDirectoryfalse/includeModuleDirectory fileSet directorysql/directory outputDirectoryconfig/schemas/outputDirectory includes include*.sql/include /includes /fileSet /fileSets /sources /moduleSet This creates a folder schemas in config file when I package it using mvn assembly plugin. Instead of a folder I want to create a zip file containing the same folder structure as specified in outputDirectory. I know how to do it in Ant but don't know how to do it in Maven. Any help will be appriciated. Thanks, Rajeev. -- View this message in context: http://www.nabble.com/zipping-the-outputDirectory-using-Assembly-plugin-tp26057622p26057622.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 -- David Weintraub qazw...@gmail.com
Re: Why are repositories usually separated into releases and snapshots?
No one has answered the basic question: Why two repositories? I know the differences between a release and snapshot. but that doesn't explain why the releases and snapshots are in two separate repositories. Why not keep both snapshots and releases in the same repository. We know something is a snapshot simply because it has the word SNAPSHOT appended to it. Because of the dual repository structure, I have to configure everything with two separate repository names, two separate repository URLs, and two sets of accounts and passwords. So, why not simply have a single repository which can store both snapshots and releases? These are the only reasons I can think of: * Administration: Backing up a release repository is extremely important. Backing up snapshots -- not so much. But, is this actually true? * Who can see what. I might want my snapshot repository available to my developers, but not to the world. However, this would be more of something my repository management software should be able to do. * Releases should only be added to the release repository by a release manager, and not by any developer. However, snapshots would be added by developers. Again, this seems better handled via my repository management software. So, what is the reason to have two separate and distinct repositories for snapshots and for releases? On Thu, Oct 22, 2009 at 4:43 AM, Costin Caraivan ccarai...@axway.comwrote: Hello, I saw that most repositories are separated into releases and snapshots. And that most repository managers recommend using releases and snapshots. Now, I know what each of them is: 1. release - stable version, will be uploaded only once, when you want to change something you make a new release. 2. snapshots - development version, usually overwritten (you can keep multiple snapshots, but it's not usually done) What are the benefits of having 2 separate repos? Cons pros. Pros cons :) -- View this message in context: http://www.nabble.com/Why-are-repositories-usually-separated-into-releases-and-snapshots--tp26006147p26006147.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 -- David Weintraub qazw...@gmail.com
Skinny War Possible Solution?
I have been struggling with the Skinny War issue. The problem is that you have to manually track your libraries in each war, then go through your ear to get the libraries working. This is the anti-thesis of what Maven is suppose to be doing. I understand the complexities of the issue. When a project builds the wars, it doesn't know what libraries each war will be dependent upon. When the ear is built, it is too late for the ear to try to calculate what are the duplicate jars. However, I believe I found a possible solution to this issue. The solution would be to create ultra-skinny wars which contain no jar files at all. Instead, all jar files will be stored in the ear. It's not exactly the solution we are looking for, but it does work. What we would need is the directory location where the wars will store their jar files and where the ear will pick up these jarfiles. Duplicates are handled by the fact that since all the jars are in a single directory, if a war downloads a jar that another war has already downloaded, the second war will simply replace that jarfile with a duplicate jarfile. This could be done with a property in the project's root pom.xml. When a war is built, and this property is set, the war will download its dependencies to this directory instead of putting them into the WEB-INF/lib directory. When the ear is built, and this property is set, the ear project will include the downloaded jars in this directory when the ear is built. There will have to be changes in the maven-ear-plugin and the maven-war-plugin to recognize this property. Plus, there may have to be further configurations for stating whether this war is suppose to be skinny or not, the changes in the classpath in the MANIFEST.MF file, etc. However, I believe these would be relatively minor. In the end, you eliminate the duplicate jars without having to go through all sorts of manipulation in the dependencies settings of your wars and ear. Do you think this will work? -- David Weintraub qazw...@gmail.com
Re: Skinny War Possible Solution?
On Tue, Oct 13, 2009 at 5:13 PM, Jörg Schaible joerg.schai...@gmx.dewrote: David Weintraub wrote: Too complicated, especially since you skip Maven's dependency version resolution by this directory where you collect the wars. I don't see how I skip the dependency version resolution. The wars are still calculating those dependencies and tracking them in the MANIFEST.MF classpath and in the pom.xml they store in the META-INF directory. For a skinny war don't configure the jar location and use the packagingExcludes parameter to skip the webapp/WEB-INF/lib. In the ear declare now both artifacts. The jar will ensure that all transitive deps are included also. If you do not use skinny wars, only declare the war. This is the entire problem. I am manually doing all of this stuff that Maven was suppose to cure. We're building the ear, looking at the wars, figuring out the duplicates, tweak the poms, repeat and rinse. Now, if we use a new version of a jar or add a new jar dependency, I have to start the whole process from scratch. I'm told this problem stems from the fact that Maven treats all of my wars as separate projects when they build. They simply cannot communicate with each other. The ear builds after the wars, so it cannot clean up this mess. The packagingExcludes is not a solution, but the symptom of the problem. -- David Weintraub qazw...@gmail.com
Why is this jar downloading?
I am trying to trace the dependency upon a particular jarfile: btm-1.3.3-RC2.jar, and trying to find out why it is downloading. I've ran mvn with the --debug flag and got this: com.solbright.aim:core:jar:2.1.2-SNAPSHOT (selected for null) [DEBUG] org.apache.ibatis:ibatis-sqlmap:jar:2.3.4.726:compile (selected for compile) [DEBUG] opensymphony:quartz-all:jar:1.5.2:compile (selected for compile) [DEBUG] junit:junit:jar:4.5:test (selected for test) [DEBUG] log4j:log4j:jar:1.2.15:compile (selected for compile) [DEBUG] javax.mail:mail:jar:1.4:compile (selected for compile) [DEBUG] javax.activation:activation:jar:1.1:compile (selected for compile) [DEBUG] javax.jms:jms:jar:1.1:compile (selected for compile) [DEBUG] com.sun.jdmk:jmxtools:jar:1.2.1:compile (selected for compile) [DEBUG] com.sun.jmx:jmxri:jar:1.2.1:compile (selected for compile) [DEBUG] commons-logging:commons-logging:jar:1.1.1:compile (selected for compile) [DEBUG] commons-dbcp:commons-dbcp:jar:1.2.2:compile (selected for compile) [DEBUG] commons-pool:commons-pool:jar:1.3:compile (selected for compile) [DEBUG] Retrieving parent-POM: org.apache.commons:commons-parent:pom:9 for project: commons-collections:commons-collections:jar:3.2.1 from the repository. [DEBUG] commons-collections:commons-collections:jar:3.2.1:compile (selected for compile) [DEBUG] commons-lang:commons-lang:jar:2.4:compile (selected for compile) [DEBUG] commons-beanutils:commons-beanutils:jar:1.7.0:compile (selected for compile) [DEBUG] commons-logging:commons-logging:jar:1.0.3:compile (removed - nearer found: 1.1.1) [DEBUG] org.aspectj:aspectjrt:jar:1.6.2:compile (selected for compile) [DEBUG] org.aspectj:aspectjweaver:jar:1.6.2:compile (selected for compile) [DEBUG] org.springframework:spring:jar:2.5.5:compile (selected for compile) [DEBUG] org.springframework:spring-aspects:jar:2.5.5:compile (selected for compile) [DEBUG] org.aspectj:aspectjrt:jar:1.6.0:compile (removed - nearer found: 1.6.2) [DEBUG] org.aspectj:aspectjweaver:jar:1.6.0:compile (removed - nearer found: 1.6.2) [DEBUG] org.springframework:spring-beans:jar:2.5.5:compile (selected for compile) [DEBUG] org.springframework:spring-core:jar:2.5.5:compile (selected for compile) [DEBUG] com.oracle:classes12:jar:10.2.0.2.0:compile (selected for compile) [DEBUG] org.codehaus.btm:btm:jar:1.3.3-RC2:compile (selected for compile) [DEBUG] Retrieving parent-POM: org.apache.geronimo.specs:specs:pom:1.1 for project: null:geronimo-jms_1.1_spec:jar:1.0.1 from the repository. [DEBUG] Retrieving parent-POM: org.apache:apache:pom:1 for project: org.apache.geronimo.specs:specs:pom:1.1 from the repository. [DEBUG] Adding managed dependencies for unknown:geronimo-jms_1.1_spec [DEBUG] org.apache.geronimo.specs:geronimo-activation_1.0.2_spec:jar:1.1 [DEBUG] org.apache.geronimo.specs:geronimo-commonj_1.1_spec:jar:1.0 [DEBUG] org.apache.geronimo.specs:geronimo-corba_3.0_spec:jar:1.1 [DEBUG] org.apache.geronimo.specs:geronimo-corba_2.3_spec:jar:1.1 [DEBUG] org.apache.geronimo.specs:geronimo-ejb_2.1_spec:jar:1.0.1 [DEBUG] org.apache.geronimo.specs:geronimo-j2ee_1.4_spec:jar:1.1 [DEBUG] org.apache.geronimo.specs:geronimo-j2ee-connector_1.5_spec:jar:1.0.1 [DEBUG] org.apache.geronimo.specs:geronimo-j2ee-deployment_1.1_spec:jar:1.0.1 [DEBUG] org.apache.geronimo.specs:geronimo-j2ee-jacc_1.0_spec:jar:1.0.1 [DEBUG] org.apache.geronimo.specs:geronimo-j2ee-management_1.0_spec:jar:1.0.1 [DEBUG] org.apache.geronimo.specs:geronimo-javamail_1.3.1_spec:jar:1.1 [DEBUG] org.apache.geronimo.specs:geronimo-jaxr_1.0_spec:jar:1.0.1 [DEBUG] org.apache.geronimo.specs:geronimo-jaxrpc_1.1_spec:jar:1.0.1 So, what is generating this dependency on btm-1.3.3-RC.jar? Is there a better way to figure this out? -- David Weintraub qazw...@gmail.com
War packaged in ear. How to exclude shared jars
We have multiple modules in this configuration: root aim core web* war* aimwebservices* projects ear** adinventory base jar hibernate-har ui *Builds a warfile and not a jar ** Builds the earfile that contains everything. Our module aim/web is dependent upon aim/core and that is dependent upon springframework:core. When we build, the aim.war file gets a copy of the springframework:core jarfile. However, this file is also in the ear project where an ear that contains all the jars and wars are packaged. Our developers don't want the aim:web warfile to contain the springframework:core jarfile since it is already in the overall earfile. We know we can specifically mention the dependency on springframework:core, then give its type as provided, but I am looking at an overall strategy: If a warfile will contain a jarfile that is already in the ear, we don't want it packaged in our warfile. Is that possible? -- David Weintraub qazw...@gmail.com
Need to include another assembly in another
We have two separate projects: One is a single module called DSP, and the other is a multiple module project called adinventory. Both build assemblies. The adinventory project looks like this: projects adplanning base jboss_init ear (This is where the assembly is built) apps.war aimwebservices.war What we want to do is add in the dsp project into the adinventory project. The dsp project will now have dependencies upon the adinventory project, and we want to release everything in one big happy assembly. The new project will look like this: projects adplanning base jboss_init dsp * target dsp-2.1.2-SNAPSHOT-bin.tar.gz* apps.war aimwebservices.war ear *target adinventory-2.1.2-SNAPSHOT.tar.gz* What we want to do is include the dsp-2.1.2-SNAPSHOT-bin.tar.gz inside the adinventory-2.1.2-SNAPSHOT.tar.gz assembly. DSP is an optional component of Adinventory, and is actually installed separately from the rest of adinventory . However, DSP will have dependencies upon the adinventory project, and because of dependency issues, we really want them released together as a single tarball. How can I refer to the dsp assembly inside my ear's bin.xml assembly definition? -- David Weintraub qazw...@gmail.com
Build Works on my machine. Not on build (maven-antrun-plugin)
I have a multi-module build that depends upon the maven-antrun-plugin. This module has to take a zip file and unzip it to a particular directory inside the war. It's pretty straight forward, and it works fine on my machine. Unfortunately, on our build system, the same build structure on the same source code doesn't unzip the zipfile to the needed directory. As far as I can tell, it does nothing. There are several differences on the build machine and mine which might make a difference. I am running Maven 2.1.0 while my build system is running Maven 2.0.8. I am also using Subversion 1.6 while the build machine uses 1.3. My version of Ant is 1.7.1 while the build machine's version of Ant is 1.7. Any idea what the issue could be? -- David Weintraub qazw...@gmail.com pom.xml.tar.gz Description: GNU Zip compressed data - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Build Works on my machine. Not on build (maven-antrun-plugin)
I updated Maven on the build system to Maven 2.2.0, and that seemed to take care of this issue. The antrun tasks are running. On Mon, Aug 10, 2009 at 12:11 PM, David Weintraub qazw...@gmail.com wrote: I have a multi-module build that depends upon the maven-antrun-plugin. This module has to take a zip file and unzip it to a particular directory inside the war. It's pretty straight forward, and it works fine on my machine. Unfortunately, on our build system, the same build structure on the same source code doesn't unzip the zipfile to the needed directory. As far as I can tell, it does nothing. There are several differences on the build machine and mine which might make a difference. I am running Maven 2.1.0 while my build system is running Maven 2.0.8. I am also using Subversion 1.6 while the build machine uses 1.3. My version of Ant is 1.7.1 while the build machine's version of Ant is 1.7. Any idea what the issue could be? -- David Weintraub qazw...@gmail.com -- David Weintraub qazw...@gmail.com
Re: deploying project jars on maven repo
If you want, you can deploy JARs in your own Maven repository. There are several public Maven repositories out there which are more or less open to any open source project. The biggies like Codehaus or maven.org have there own projects. You can see how to make your project a CodeHaus project here: http://codehaus.org/customs/selection.html . Basically, most companies have their own Maven repoitries, and your local copy of Maven is configured to look for Jars there. Some companies have s corporate POM all projects reference. What are you looking for? Just the ability to share jars between local projects or do you have an open source project you want to share with the world? -- David Weintraub da...@weintraub.name Sent from my iPhone while riding in my Ferrari. (Jealous?) On Aug 7, 2009, at 4:39 PM, Ricky ricky...@gmail.com wrote: Hi, What is the process a project has to go through if it wants to get its jars deployed on a maven repo? (so that they can then be referenced on POM using dependency / tag). Any guidelines / suggestions? Rick - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Exploding a ZIP in a resource directory
On Tue, Aug 4, 2009 at 6:57 PM, Alexander the.malk...@gmail.com wrote: You could declare these documentaion as dependecy. Then use dependency plugin for unpacking this module. [?] See http://maven.apache.org/plugins/maven-dependency-plugin/unpack-mojo.html On Tue, Aug 4, 2009 at 8:39 PM, Brian Fox bri...@infinity.nu wrote: http://www.sonatype.com/people/2008/04/how-to-share-resources-across-projects-in-maven/ Well, this isn't quite a shared dependency. The documentation is only for this particular module and is irrelevant anywhere else. Do I need to have the techwriters zip up the documentation and download it into our Maven repository, and then when I do a build, download it, and unzip it? Is it possible to use the maven-dependency-plugin just to merely do the unzipping? Otherwise, I'll have to give our techwriters access to the repository, and let the developers know they have to coordinate the version numbering of the documentation in the pom.xml. Maybe I am better off just using the antrun mojo to do the unzipping during the packing phase. -- David Weintraub qazw...@gmail.com
Filtering assembly, but with command line value
We have a single file called aim_version.properties. In it is a string @VERSION@ which is replaced with a property that I get from the command line. I am building an assembly, and I need to change the @VERSION@ string with a value of a property that I either get from the command line, or I get as the default property in the pom.xml. I looked up the assembly descriptor, and it tells me how to do filtering via an already built properties file, but I don't want to do that. Instead, I simply want to take the value of the property and filter this one file with that property. How do I do that while I build the assembly? I know how to specify this one file when building the assembly, and I see how to do the filtering if the value I want is in a properties file, but I need to take the value off the command line. -- David Weintraub qazw...@gmail.com
Re: Filtering assembly, but with command line value
I just want to clarify:
If I need to change this aim_version.properties file to use ${version} or
whatever, that's fine with me. If I need to change the name or move this to
another location, that's fine too. If we have to make this an XML file
instead of a properties file, that's fine too.
We use Hudson as our build system, and we simply need the Hudson build
number in this file. We also need this file to sit outside the generated EAR
which is why we use an assembly. (We also have a bunch of other
configuration files and shell scripts that sit outside the ear too, so
having an assembly isn't a problem).
If this was a file inside a JAR or WAR, I could use resource filtering, but
this file has to be easily accessible, so our tech services people can
verify the installation.
I simply need a way to put the Hudson build number (which I can pick up from
the command line) into a file that is easily accessible to our tech services
guys.
On Tue, Aug 4, 2009 at 12:47 PM, David Weintraub qazw...@gmail.com wrote:
We have a single file called aim_version.properties. In it is a string
@VERSION@ which is replaced with a property that I get from the command
line. I am building an assembly, and I need to change the @VERSION@ string
with a value of a property that I either get from the command line, or I get
as the default property in the pom.xml.
I looked up the assembly descriptor, and it tells me how to do filtering
via an already built properties file, but I don't want to do that. Instead,
I simply want to take the value of the property and filter this one file
with that property.
How do I do that while I build the assembly? I know how to specify this one
file when building the assembly, and I see how to do the filtering if the
value I want is in a properties file, but I need to take the value off the
command line.
--
David Weintraub
qazw...@gmail.com
--
David Weintraub
qazw...@gmail.com
Exploding a ZIP in a resource directory
We have a series of HTML based help files that sit inside our src/main/resource/help directory. Right now, we store these files as html files, and everything is fine. The problem is that the people who build these files create the files in Microsoft Word, then use a PC program called Robohelp to generate them. Every time they generate the files, we get a completely different version of all HTML and GIFS no matter how small the change. We use Subversion, and each time we generate new help files, the people who maintain them basically delete the entire Subversion help tree, then re-add in the new set of files. This causes problems with our developers who now end up downloading and updating hundreds of files whenever the help changes. I would like to simply store these help files as a single zipfile in our source archive, and then unzip these files when I do a build. Is this possible in Maven? -- David Weintraub qazw...@gmail.com
Re: Creating multiple artifacts for a single project
Take a look at assemblies. That will allow you to package your source in a jar or tarball. To create an assembly, you need the assembly plugin in your pom.xml, and you need to define an assembly file which describes what will be in your assembly (usually stored in /src/main/assembly. Optionally, you can redefine the package lifecycle to build the assembly for you. Otherwise, it will only build if you do mvn assembly:assembly. See http://maven.apache.org/plugins/maven-assembly-plugin/ On Tue, Jul 21, 2009 at 1:09 PM, Chetan Sarvache...@milabra.com wrote: Hi, I've got a single pom.xml from which I want to create multiple artifacts. I want to package the source as a JAR (so other projects can mark it is as a dependency) as well as a WAR for deploying directly. I'm able to create 2 packages currently, but when I try to include the JAR into another project, it seems to grab the WAR file instead. How can I set different artifact id's for each artifact so that I can select the correct one? chetan -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Hi,guys! I am a new one in Maven. I try to run maven .but get the error message .
Try: *C:\DOCUME~1\ADMINI~1 mvn archetype:generate * * *Instead of the archetype:create. The archetype:generate is the newer plugin, and you don't need to worry about providing it with any command line parameters that might cause errors. There could be several issues. Are you using Java 1.5 or higher? What version of Maven are you using? ** On Sun, Jul 12, 2009 at 2:17 AM, 白鹏 bill.peng@gmail.com wrote: C:\DOCUME~1\ADMINI~1mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app FATAL ERROR: Unable to start the embedded plexus container who can tell me why this happen ?? Thanks a lot! -- David Weintraub qazw...@gmail.com
Re: mvn assembly:assembly won't package jars and ears, but mvn package will
-Dversion=2.1.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=com.solbright.adinventory.projects.base -DartifactId=jar -Dversion=2.1.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) com.solbright.adinventory.projects.base:servlet:jar:2.1.2-SNAPSHOT 2) com.solbright.adinventory.projects.base:jar:jar:2.1.2-SNAPSHOT -- 1 required artifact is missing. for artifact: com.solbright.adinventory.projects.base:servlet:jar:2.1.2-SNAPSHOT from the specified remote repositories: snapshot (http://aladdin.solbright.com:8082/nexus/content/repositories/snapshots/ ), production (http://aladdin.solbright.com:8082/nexus/content/repositories/releases/ ), Nexus (http://aladdin.solbright.com:8082/nexus/content/groups/public) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 9 seconds [INFO] Finished at: Thu Jul 09 12:10:15 GMT-05:00 2009 [INFO] Final Memory: 29M/194M [INFO] Why does the build suddenly fail when I run the assembly:assembly lifecycle, yet the same setup succeeds when I do mvn package? For convinence, the pom files I use are at http://files.getdropbox.com/u/433257/pom.tar. I've also attached it to this message. -- David Weintraub qazw...@gmail.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 -- David Weintraub qazw...@gmail.com
Re: mvn assembly:assembly won't package jars and ears, but mvn package will
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
mvn assembly:assembly won't package jars and ears, but mvn package will
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 -Dversion=2.1.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file* * Alternatively, if you host your own repository you can deploy the file there: * * mvn deploy:deploy-file -DgroupId=com.solbright.adinventory.projects.base -DartifactId=jar -Dversion=2.1.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]* * Path to dependency: * * 1) com.solbright.adinventory.projects.base:servlet:jar:2.1.2-SNAPSHOT* * 2) com.solbright.adinventory.projects.base:jar:jar:2.1.2-SNAPSHOT* *--* *1 required artifact is missing.* *for artifact: * * com.solbright.adinventory.projects.base:servlet:jar:2.1.2-SNAPSHOT* *from the specified remote repositories:* * snapshot ( http://aladdin.solbright.com:8082/nexus/content/repositories/snapshots/),* * production ( http://aladdin.solbright.com:8082/nexus/content/repositories/releases/),* * Nexus (http://aladdin.solbright.com:8082/nexus/content/groups/public)* *[INFO] * *[INFO] For more information, run Maven with the -e switch* *[INFO] * *[INFO] Total time: 9 seconds* *[INFO] Finished at: Thu Jul 09 12:10:15 GMT-05:00 2009* *[INFO] Final Memory: 29M/194M* *[INFO] * Why does the build suddenly fail when I run the assembly:assembly lifecycle, yet the same setup succeeds when I do mvn package? For convinence, the pom files I use are at http://files.getdropbox.com/u/433257/pom.tar. I've also attached it to this message. -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Why Don't Certain Dependencies Get included in my WAR?
groupIdcom.wutka/groupId artifactIdjox/artifactId version1.16/version /dependency dependency groupIdjavax.mail/groupId artifactIdmail/artifactId version1.4.1/version /dependency dependency groupIdcom.oracle/groupId artifactIdojdbc14/artifactId version10.2.0.2/version scopeprovided/scope /dependency dependency groupIdlog4j/groupId artifactIdlog4j/artifactId version1.2.12/version /dependency dependency groupIdorg.log4j/groupId artifactIdlog4j/artifactId version0.0.1/version /dependency dependency groupIdcom.oreilly/groupId artifactIdservlet-cos/artifactId version05Nov2002/version /dependency dependency groupIdorg.springframework/groupId artifactIdspring/artifactId version1.2.9/version /dependency dependency groupIdxerces/groupId artifactIdxerces/artifactId version2.0.1/version /dependency dependency groupIdcom.oracle/groupId artifactIdxsu/artifactId version1.2/version /dependency dependency groupIdde.dankomannhaupt/groupId artifactIdjdbcappender/artifactId version2.1.01/version dependency groupIdjunit/groupId artifactIdjunit/artifactId version4.5/version scopetest/scope /dependency /dependencies /project -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven - Property files Question
On Mon, Jul 6, 2009 at 5:03 PM, mavenusrsundarva...@gmail.com wrote: Thanks. Yes. My property files aren't part of the JAR. so again my question is, if i change the property files, will the JAR automically pickup the change without the need for rebuilding it? No. If none of the files that make up your jar file are changed, the jar file simply isn't rebuilt. Maven is really extremely good at this. Much better than Ant. However, if you build an assembly (that is you package that jar file with your properties files in a tarball or a zipfile), the assembly will be rebuilt! I mention this because I explained how to build an assembly back in my reply to you on June 26. That makes perfect sense. Jar file isn't rebuilt because none of the files in it are changed. Assembly flie is rebuilt because the properties file in it was changed. Now, by default, Maven doesn't build assemblies on the package lifecycle -- only the jar flie. So, by default, if you do: $ mvn package And, you changed your properties file, but nothing else, the mvn package won't do anything except print out a lot of garbage. If you changed your properties file, but not any of the files that make up the jar, and you do this: $ mvn assembly:assembly The assembly will be rebuilt. The jar file won't be, but a new assembly tarball or zip file will be rebuilt. The only reason I'm mentioning this is that you can change Maven's default behavior by telling Maven to build the assembly on the package lifecycle step. Again, I mentioned how to do this in my June 26 reply to you. Therefore, if you changed your pom.xml file to build your assembly on the package stage of your development lifecycle, doing this: $ mvn package Will do something: It won't rebuild your jar file, but it will rebuild your assembly. -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven - Property files Question
On Mon, Jul 6, 2009 at 3:29 PM, mavenusrsundarva...@gmail.com wrote: one last question. If i want to update the property files, will my jar file picksup the updates automatically or do i need to build it again? Um... I thought the properties file wasn't in your JAR. If you put the properties file in another directory besides the resources directory, or if you exclude the properties files from the jar, but the properties files are still in the /src/main/resources directory, then your JAR will not rebuild if someone changes the properties files. HOWEVER, if the properties files are included in your jarfile. Yes, your jarfile will rebuild. Basically, whether your jar file rebuilds or not depends if any of the files inside the jar are changed. I've found Maven pretty good at keeping track of those types of things. -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
org.codehaus.mojo:axistools-maven-plugin
artifactIdmaven-compiler-plugin/artifactId configuration source1.6/source target1.6/target /configuration /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.4.2/version /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId configuration archive addMavenDescriptorfalse/addMavenDescriptor manifest addClasspathtrue/addClasspath /manifest /archive /configuration /plugin /plugins /build dependencies !-- Not listed for space savings -- /dependencies /project -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven - Property files Question
the application, the property files which are under src/main/resources is also getting included. I need to place this outside the jar file so that the application can pickup when ever i make any changes to the property. currently i need to package again whenever a small change is made. please help. Thanks, Sundar -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven - Property files Question
change is made. please help. Thanks, Sundar -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven with Hibernate/Multiple POM files
1/ A POM is not a programming language, but a project description. It is
pointless to define the properties section in the top of the file in the
hope that Maven sees the values first before you use them. You can
call mvn help:effective-pom to see what Maven actually uses for the
project description in the end.
It could be that I simply don't understand how to do something. We
have a continuous build system, and label each of our builds with a
build number. We like that build number to part of the maven artifact
itself. For example, aim-2.1.2-D-32-bin.tar.gz where 2.1.2-D-32 is our
build number.
However, there is no need to put these builds into our Maven
repository since our continuous build system makes them available and
manages them. Otherwise, I would have to do a constant purge our our
Maven repository since we can do 10 to 20 builds each day.
This is why I have the product's version as a property. I can pass it
into the pom when a build is done. At the same time, I need to allow
developers to run the builds themselves, and not have
aim-${aim.version}-bin.tar.gz as the name of the maven artifact. In
order to avoid this, I put the property inside of the POM. I could put
this anywhere directly under the project/, but putting it at top
allows the developers to easily find it when they do want to change
the default (such as when we start work on version 2.1.3).
So, what is the correct way to set my projects in order to be able to
have a default version number, yet allow me to override it on the
command line?
That also doesn't cover my other problem: I am using
net.sf.maven-har:maven-har-plugin which requires me to have my service
file called jboss-service.xml living in the resource's META-INF
directory. Unfortunately, our service file is called
hibernate-service.xml.
Is it possible to somehow redefine the name of this file in your
pom.xml? If I was writing this code from scratch, I would simply use
the default name. But, I have to make sure that the structure of my
Maven artifact matches the output of our current build artifact.
Where can I at least find documentation on this plugin? I got the
basic POM structure by doing a mvn archetype:generate and requesting a
har project.
--
David Weintraub
qazw...@gmail.com
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven with Hibernate/Multiple POM files
The base directory's POM.xml:
project
modelVersion4.0.0/modelVersion
properties
base.version2.1.2-SNAPSHOT/base.version
/properties
groupIdcom.solbright/groupId
version${base.version}/version
artifactIdbase/artifactId
packagingpom/packaging
namebase/name
modules
modulejar/module
moduleservlet/module
modulehar/module
/modules
dependencyManagement
dependencies
dependency
groupIdcom.solbright.base/groupId
artifactIdjar/artifactId
version${base.version}/version
typejar/type
/dependency
dependency
groupIdcom.solbright.base/groupId
artifactIdservlet/artifactId
version${base.version}/version
typejar/type
/dependency
dependency
groupIdcom.solbright.base/groupId
artifactIdhar/artifactId
version${base.version}/version
typehar/type
/dependency
/dependencies
/dependencyManagement
/project
The JAR directory pom:
project
modelVersion4.0.0/modelVersion
groupIdcom.solbright.base/groupId
artifactIdjar/artifactId
packagingjar/packaging
namejar/name
version${base.version}/version
parent
groupIdcom.solbright/groupId
artifactIdbase/artifactId
version${base.version}/version
/parent
build
finalNamebase/finalName
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
configuration
archive
manifest
addClasspathtrue/addClasspath
/manifest
/archive
/configuration
/plugin
/plugins
/build
dependencies
...
/dependencies
And, finally the HAR pom.xml
project
modelVersion4.0.0/modelVersion
groupIdcom.solbright.base/groupId
artifactIdhar/artifactId
packaginghar/packaging
namehar/name
version${base.version}/version
parent
groupIdcom.solbright/groupId
artifactIdbase/artifactId
version${base.version}/version
/parent
build
finalNamebase-hib/finalName
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
configuration
archive
manifest
addClasspathtrue/addClasspath
/manifest
/archive
/configuration
/plugin
plugin
groupIdnet.sf.maven-har/groupId
artifactIdmaven-har-plugin/artifactId
version0.9/version
extensionstrue/extensions
/plugin
/plugins
/build
dependencies
dependency
groupIdcom.solbright.base/groupId
artifactIdjar/artifactId
version${base.version}/version
/dependency
dependency
groupIdorg.hibernate/groupId
artifactIdhibernate/artifactId
version3.1.3/version
/dependency
...
/dependencies
/project
On Wed, Jun 24, 2009 at 7:36 AM, Baptiste MATHUS m...@batmat.net wrote:
Well, could you give us at least an excerpt of your pom?
I'm guessing you want to use some jar and didn't acknowledge the local maven
repository existence, but I might be wrong.
In fact you seem to be trying to directory use some given jar that's been
produced by another projet.
But this is all suppositions and I might be wrong, please let us see your
poms.
Cheers.
2009/6/22 David Weintraub qazw...@gmail.com
I have a project (it's actually a sub-project of another project, so
it will get interesting).
We build three items: base.jar, base-ui.jar, and base-hib.har. These
each are in their own sub-directory, and I can treat them like
projects. I was able to get the whole thing working. However, the
base-hib.har uses Hibernate, and I couldn't find any information on
setting up a project
Re: beyond Properies and Resource Filtering
This should help:
http://maven.apache.org/plugins/maven-resources-plugin/examples/include-exclude.html
And over here:
http://maven.apache.org/plugins/maven-resources-plugin/copy-resources-mojo.html
(Note the Examples links on the left side. They can provide you with
specific pom.xml examples).
I find that the reference at http://maven.apache.org/plugins/ is the
best way to find information. I'm not too impress with any of the
books I've seen. Most talk about how to setup a pom.xml for a specific
type of application, but not about exactly how everything works, or
where you can find more information.
You can define command line properties to define exactly which
directory you want:
$ mvn -Dconfig-type=foo package
build
resources
resource
directorysrc/main/resources/directory
/resource
resource
directorysrc/main/${config-type}-resources/directory
/resource
/resources
/build
If you use the above examples, you'll have to move those two
directories to where you really want those the mySpringBean.xml file
to be located when copied. For example, if they go into the META-INF
directory, you'll need to have the two files in:
src/main/foo-resources/META-INF/mySpringBean.xml
and
src/main/bar-resources/META-INF/mySpringBean.xml
On Tue, Jun 23, 2009 at 3:00 PM, Robert Gloverrobertglove...@yahoo.com wrote:
I have read chapter 13 of Maven: The Definitive Guide and did not find my
question answered there.
Here is what I need to do. I have two subdirectories as follows:
src/main/resources/foo
src/main/resources/bar
I have the same file in each of those two directories:
src/main/resources/foo/mySpringBean.xml
src/main/recourse/bar/mySpringBean.xml
What I need to do is specify on the command line (or in a Profile or in
settings.xml) which of those two directories should have it's contents copied
to target/classes. The other directory should not have its contents copied
into target/classes.
Thank you in advance! (hope hope).
Robert
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
David Weintraub
qazw...@gmail.com
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Maven with Hibernate/Multiple POM files
I have a project (it's actually a sub-project of another project, so it will get interesting). We build three items: base.jar, base-ui.jar, and base-hib.har. These each are in their own sub-directory, and I can treat them like projects. I was able to get the whole thing working. However, the base-hib.har uses Hibernate, and I couldn't find any information on setting up a project that uses Hibernate. I was able to generate a Hibernate pom.xml using archetype:generate, but it seems like that the POM requires a service file to be named jboss-service.xml. Unfortunately, ours is named hibernate-service.xml, and I couldn't find anyway to configure this in the POM. Another question: I build the base.jar file, and the other two projects depend upon that file. I've setup the POMs to show this dependency: Everything builds, but when I run analyze:dependency, it tells me it is missing base.jar -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to create many jars in package phase?
/include
/includes
excludes
exclude**/pkg2/MyClass.class/exclude
/excludes
/configuration
/execution
/executions
/plugin
The generated jar will be copied o your repository. Then, when you
need
to
use the jar from another project, you can include the dependency like
this
dependency
groupId${project.groupId}/groupId
artifactIdtheJarName/artifactId
versiontheJarVersion/version
classifiermy-client/classifier
/dependency
More information at:
http://maven.apache.org/plugins/maven-jar-plugin/index.html
http://maven.apache.org/plugins/maven-jar-plugin/index.html
--
View this message in context:
http://www.nabble.com/How-to-create-many-jars-in-package-phase--tp23646150p24070227.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
--
David Weintraub
qazw...@gmail.com
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
David Weintraub
qazw...@gmail.com
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
David Weintraub
qazw...@gmail.com
mvn dependency:analyze missing dependency?
I am converting yet another Ant build to a Maven build. This time, I purposefully laid out the directory tree, so when we do the conversion, it would be much simpler. I've finally found all of my dependencies, added them into the pom.xml, and got everything to compile and build the jar. (whether the jar actually works is another question). I did a dependency:analyze, and got the following result: [INFO] [dependency:analyze] [WARNING] Unused declared dependencies found: [WARNING]com.wutka:jox:jar:1.16:compile [WARNING]junit:junit:jar:3.8.1:test [INFO] [INFO] BUILD SUCCESSFUL [INFO] I know the junit would be because this jar has no tests. However ,the com.wutka.jox is used in a particular program, and if I remove this dependency from the pom.xml, the program won't compile. Why am I getting this message? -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to create many jars in package phase?
Thanks. It took me a while to figure this out. At first, I tried to create a
separate plugin for each client. However, only the first one executed.
Then, I tried to add a new execution definition to the maven-jar-plugin
artifact, but kept getting errors. I finally realized that each execution
needed its own id.
This created the separate jars that were needed. Now, I have to create an
assembly for each of these clients.
On Wed, Jun 17, 2009 at 5:45 AM, losa mgl...@hotmail.com wrote:
You can use the maven-jar-plugin for generating more than one jar file
filtering the classes you want to include.
Example:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
executions
execution
phasepackage/phase
goals
goaljar/goal
/goals
configuration
classifiermy-client/classifier
includes
include**/pkg1/MyClass.class/include
/includes
excludes
exclude**/pkg2/MyClass.class/exclude
/excludes
/configuration
/execution
/executions
/plugin
The generated jar will be copied o your repository. Then, when you need to
use the jar from another project, you can include the dependency like this
dependency
groupId${project.groupId}/groupId
artifactIdtheJarName/artifactId
versiontheJarVersion/version
classifiermy-client/classifier
/dependency
More information at:
http://maven.apache.org/plugins/maven-jar-plugin/index.html
http://maven.apache.org/plugins/maven-jar-plugin/index.html
--
View this message in context:
http://www.nabble.com/How-to-create-many-jars-in-package-phase--tp23646150p24070227.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
--
David Weintraub
qazw...@gmail.com
Re: How to create many jars in package phase?
Yes, this is an Ant project going over to Maven by order of High Lord of All
Matters Important. One of the things I have to do is keep the final output
as close to the Ant build's output as possible. Since I am the Maven
maven, I am the one stuck with this task and not the developer.
There are separate jarfiles for each client, and a core jarfile that
contains only the common jars. I was originally thinking of creating
directories for each client and treating them as modules, but the developers
vetoed the idea of moving the java files into each client. They want the
Java files all together.
Treating each client's jar as an assembly made things a bit simpler since I
can build each Jar with the required classfiles in separate execution
sections. Otherwise, I would have to define separate directories for each
client, and then try to define a pom.xml which would build the jarfile for
that client from the compiled code that is in the main project's directory.
I finally created an assembly file that defined the zipfile into a similar
format the original Ant build produced.
On Wed, Jun 17, 2009 at 2:42 PM, Anders Hammar and...@hammar.net wrote:
Only so that you don't forget, the general Maven rule is one project,
one artifact. You could use classifiers to create more than one
artifact for a project, but I don't really see the benefit. Have
several projects is not bad (I think), it makes your code base
structured. Changes to one customer's code will then only affect that
customer's project and making it possible to make a new release for
just that customer. If you mix all customers' code in one project you
will get a new version for all customers (while only one of them has
really changed). Not very clean I think.
The assemblies goes in separate projects.
Just my two cents,
/Anders
On Wed, Jun 17, 2009 at 19:41, David Weintraubqazw...@gmail.com wrote:
Thanks. It took me a while to figure this out. At first, I tried to
create a
separate plugin for each client. However, only the first one executed.
Then, I tried to add a new execution definition to the maven-jar-plugin
artifact, but kept getting errors. I finally realized that each
execution
needed its own id.
This created the separate jars that were needed. Now, I have to create an
assembly for each of these clients.
On Wed, Jun 17, 2009 at 5:45 AM, losa mgl...@hotmail.com wrote:
You can use the maven-jar-plugin for generating more than one jar file
filtering the classes you want to include.
Example:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
executions
execution
phasepackage/phase
goals
goaljar/goal
/goals
configuration
classifiermy-client/classifier
includes
include**/pkg1/MyClass.class/include
/includes
excludes
exclude**/pkg2/MyClass.class/exclude
/excludes
/configuration
/execution
/executions
/plugin
The generated jar will be copied o your repository. Then, when you need
to
use the jar from another project, you can include the dependency like
this
dependency
groupId${project.groupId}/groupId
artifactIdtheJarName/artifactId
versiontheJarVersion/version
classifiermy-client/classifier
/dependency
More information at:
http://maven.apache.org/plugins/maven-jar-plugin/index.html
http://maven.apache.org/plugins/maven-jar-plugin/index.html
--
View this message in context:
http://www.nabble.com/How-to-create-many-jars-in-package-phase--tp23646150p24070227.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
--
David Weintraub
qazw...@gmail.com
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
David Weintraub
qazw...@gmail.com
Multiple *.jar files from one project
We have a source tree in this format: src/main/java/com/solbright/aim/etlf/core src/main/java/com/solbright/aim/etlf/customer_1 src/main/java/com/solbright/aim/etlf/customer_2 And so on for each customer. My developers want a separate jar file for each and every customer. Not only that, but a separate assembly package for each and every customer. Do I need to create a pom.xml for each and every customer, or can I specify multiple jars in a single pom.xml? -- David Weintraub qazw...@gmail.com
axis:axis:1.4 vs. org.apache.axis:axis:1.4
I mentioned this before, but received no reply. We have a project that was using the org.apache.axis:axis:1.4 artifact. This was not downloading axis-saaj-1.4.jar even though axis-1.4.jar is dependent upon that particular jar (and it ends up axis-jaxrpc-1.4.jar too). When I switched to the artifact axis:axis:1.4, it downloads the same axis-1.4.jar, but now also downloads the axis-saaj-1.4.jar and the axis-jaxrpc-1.4.jar too. Which artifact is the correct one to use: axis:axis:1.4 or org.apache.axis:axis:1.4? When I use axis:axis:1.4, I get a message that it has been moved to org.apache.axis:axis:1.4. Yet, org.apache.axis:axis:1.4 doesn't seem to download the dependent jars that axis-1.4.jar needs. Is this an error in the org.apache.axis:axis:1.4 POM? -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
axis:axis:1.4 vs. apache.org:axis:1.4 and saaj-.1.4.jar
We recently ran into an issue in our project. Our project converts WSDL files into Java files and compiles them. To handle this, we use org.codehaus.mojo:axistools-maven-plugin:1.2. We also specify the dependencies on artifacts org.apache.axis:axis:1.4, org.apache.axis:axis-jaxrpc:1.4 in our pom.xml. Everything was fine until one day our Hudson builds started failing. We were getting the error cannot access javax.xml.soap.SOAPMessage file javax/xml/soap/SOAPMessage.class not found. This is from using inMsg.getSOAPPartAsSTring which is in the class org.apache.axis.AxisFault which is documented in use of the axis-1.4.jar. We quickly discovered that the build will work with JDK1.6, but not JDK1.5 (which is what we were using) or JDK1.4. We traced this down to a missing classfile found in axis-saaj-1.4.jar. After further work, we suddenly discovered that the build was once again working no matter which JDK we were actually using for compiling. I decided to clean out the $HOME/.m2/repository directory to see what was downloading, and noticed that axis-saaj-1.4.jar was downloading. We looked at the pom files for artifacts org.apache.axis:axis-1.4.pom and org.apache.axis:axis-jaxrpc:1.4., but found no dependency on axis-saaj-1.4.jar stated there. We then realized that both axis:axis:1.4 and apache.org.axis:axis.1.4 were both being downloaded into the $HOME/.m2/respository directory but couldn't find any difference in the two axis-1.4.jars. However we then examined the poms and found a difference: axis:axis:1.4 has a dependency on axis-saaj-1.4.jar while org.apache.axis:axis:1.4 does not. Further research found what was actually downloading axis-saaj-1.4.jar. It was org.codehaus.mojo:axistools-maven-plugin:1.2 which states its dependency upon the artifact axis:axis:1.4 and not org.apache.axis:axis:1.4. (This mojo also does not state a dependency upon the axis-saaj-1.4.jar, but uses the axis:axis:1.4 artifact to declare that dependency) More interesting is this comment found in the axistools-maven-plugin's POM file. POM under org.apache.axis groupId doesn't declare meta-datas and cannot be overriden in plugindependencies to use an older axis release. So, what is going on? Should we be using axis:axis:1.4 as our dependent artifact instead of org.apache.axis:axis:1.4? Why did the compilation stop working for a day? Why the two different ways to state the same axis-1.4.jar? Where can I find any documentation mentioning using the artifact axis:axis:1.4 vs. org.apache.axis:axis:1.4? -- David Weintraub qazw...@gmail.com All attachments have been scanned for viruses and have been found to be virus free. So, just go ahead and open them. Go ahead... Just click on it... Trust me. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to perform a deploy only
On Wed, Mar 25, 2009 at 10:17 PM, Jim McCaskey jim.mccas...@pervasive.com wrote: Hello all, I have several components all built from a top level pom. This works great for accelerating users to be able to build a lot of stuff quickly but is giving me some fits when trying to deploy. Up to this point I have been using deploy:deploy-file to get built components into our local repository after a full build is successful, but this is labor intensive. Have you looked at the Promotion Plugin? It looks like it does exactly what you want. When you set up a promotion, you can have it triggered manually, or when a certain set of downstream artifacts get deployed. You can then have it email you, do tagging, or deploy your artifacts to the Maven repository. -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Executing maven build from ant build
There are Maven tasks for Ant, but I find them extremely difficult to use. The documentation is just plain awful. The official Maven Ant page simply lists where you can download the JAR file, and that's it. I simply wanted Ant to run an existing pom.xml, but could find no way to do this. So, I simply did an exec to Maven instead. On Tue, Mar 24, 2009 at 3:33 PM, eyalg1972 eyal_go...@bmc.com wrote: Hi, I need to know how to run maven from ant. Especially- if the pom.xml is in different directory - can you give the maven the location of the pom.xml as a parameter? (I always run it from the exact directory). Do you use the ant exec task? Did someone did it- and can give me an example of how it is done (Including- parsing the result- success of failure)? Thanks -- View this message in context: http://www.nabble.com/Executing-maven-build-from-ant-build-tp22687975p22687975.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 -- -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Un-mavenize a Maven2 project ?
On Fri, Feb 27, 2009 at 1:44 PM, Mark Struberg strub...@yahoo.de wrote: but ant must be installed also before it can be used. And installing ant is the same effort than installing maven. So this will not add anything to his problem. Ant is included when you install Eclipse. It's one of the reasons our developers aren't exactly on board with our conversion to Maven. They don't have to install Ant, and Maven's configuration isn't exactly straight forward because of the changes you have to make to the settings.xml file in order to use our local repository. I publish the settings.xml, and I have a preconfigured Maven install, but you can't beat something that's already included when you download Eclipse. -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Un-mavenize a Maven2 project ?
Would Ant be okay to use? You don't have to demavenize a thing -- just add a build.xml to your project. We converted many of our projects from Ant to Maven, but still have both the build.xml and pom.xml in the root directory. I even removed the third party jars from our repository. Instead, I added Ant's get task to the build.xml to fetch the needed jars. It is up to the tech leads to decide whether to use Maven or Ant in our continuous build process although more and more projects are now being built with Maven. Then again, installed Maven, set the settings.xml in the Maven directory, then tarred it up and pass it out to the students. It's pretty self contained. All they need to do is untar it somewhere, and put a link to the mvn script into their PATH. That will allow the students to learn Maven while they are at it. Might as well let your students learn how to use Maven now while their brains are still soft and moist rather than wait a few years after brain hardening has started to set in. On Fri, Feb 27, 2009 at 2:19 AM, Alessio Pace alessio.p...@gmail.com wrote: Hi, a project I'm working on is built by Maven2. It is a single module, it uses M2 merely for dependency managament. I have to let some students play with it as part of a lab project. Their machines just have plain Eclipse, and the users are Maven-unaware, and I can't afford to make them pre-install Maven or install it during the lab session (too few hours). What I wanted to do is to un-mavenize the project, creating a separate source tree in the old fashion: without the pom.xml but with a libs directory filled with all the jars my project depends on. Possibly also with the Eclipse .project and .classpath files already configured (ok ok, this is optional). Thanks in advance for any suggestion on how to achieve that, or with comments if you ever had to deal with such a situation (and possibly if you want me to discourage to go with the un-mavenize process) Regards, Alessio Pace. -- -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to copy resource files to target/classes directory?
Okay, you know where those resources should be. Why is it so difficult to move the resource files to their correct directory? If you are using a version control system, and worry about moving files that other users might be working on, do a copy first, then let everyone get use to the new place. After that, delete them from the src/main/java directory. The whole process shouldn't take more than a day or two. It is possible to tell Maven to tell Maven to copy those resources from your src/main/java directory. Clovis has given you the solution, but one of the advantages of Maven is that there's a standard Maven way everything works. You know where to find the files because of the standardized directory structure. Let the developers learn the correct place where resource files should be stored, so they get use to Maven and use those job skills on their next assignment. On Thu, Feb 26, 2009 at 8:11 AM, youhaodeyi youhaod...@gmail.com wrote: I have may XML files in src/main/java directory and its sub directory. When I run mvn compile, these XML files will not be copied to the target/classes directory. I know I can put these files in src/main/resources directory but it is really hard work for me. How can I let maven do this? -- View this message in context: http://www.nabble.com/How-to-copy-resource-files-to-target-classes-directory--tp3747p3747.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 -- -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing Existing Project Part Deux
Sorry to get late into this conversation, but I am wondering if there might be a way to do a gentler migration path. For example, let's say you modify the current directory structure bit-by-bit into the standard Maven directory structure, then once you have setup in a way Maven likes it, convert the build over to Maven. Of course, the whole thing depends on how standard are your current projects. Our main project is a mess of enterprise beans, various frameworks, and an infrastructure that was hacked together into a mish-mosh of one of the biggest messes you've ever seen. The software was developed about a decade ago by a bunch of developers who worry about such things as planning or architecture. To move over to Maven is almost impossible because it may require massive structural changes in our project. However, other projects we had were quite easy. They produced a standard JAR file or WAR file and the whole process was pretty straight forward. And, unlike the previous monstrous project I described, these were actually buildable in Eclipse, so there may be hope for you. If I remember, you're talking about a rather small shop of three developers and about 10 projects. It may simply be a matter of moving your source to emulate Maven's structure, then moving resources to where they're suppose to go. Once that is done, you can generate a POM via the mvn: archetype:generate and put it into your Eclipse project. Once you're able to get your project to build with Maven, simply remove the jarfiles you have in your revision control system. This is a similar path we took with our smaller projects. We moved the source files around while still doing our Ant builds, then created the POM. Once we got things working, we simply moved Hudson from using Ant to Maven, and removed the jarfiles from Subversion. Each project took a couple of days. No branching or merging. On Mon, Feb 23, 2009 at 7:53 PM, Steve Cohen stevec...@comcast.net wrote: OK, after extensive discussion in earlier thread about the best way to go about Mavenizing Existing Project(s) in my, shall we say, unusual environment (see that thread for details, don't want to recapitulate them here) I have decided to try to move forward. First I have to learn this tool. I have used maven before, but mainly in the way of building from someone else's POM. Just type maven install or some such and bingo, the world is built. Now my goal is to have pre-existing non-Maven projects be mavenized. I am prepared to throw the first one away. I also want to take this opportunity to start from a m2eclipse platform, so I have now installed that, even to the point of installing Ganymede because I couldn't get it to install in Europa. Although I know there is benefit to the command line tools, I'd like to start from eclipse, understanding that I can take the POM I produce and install it with command line tools. So my first question is this: How do I convert a non-Maven project into a Maven project? 1) Is there some way to change natures? 2) Create a new Maven project, place in SVN, then move stuff to the right places? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: basic question about maven
The standard command to create a new Maven project is: $ mvn archetype:generate This will give you a list of 41 different project types. Select your project type, and answer the questions. This will build the directory structure and skeletal pom.xml to use. I think you want to select #18 from the list: A simple Java Webapp. On Thu, Feb 26, 2009 at 12:56 PM, nani2ratna nani2ra...@gmail.com wrote: Hi, I just want to develop one small application for a trust. I want to set up a framework struts 2, spring, hibernate, acegi and maven. I know we got our excellent Appfuse, but i don't know much about templates and velocity I want to use tlds and tiles. And i set up maven nicely in my system. But my main doubt is --- whether we have to write a script for war creation or is there any command for creating folders for srs---main web/java. If is there any command please give me that command because in the Getting started guide of maven, they have given one command to create srs and test folders. Is there anything like that for web projects. Thanks in advance Ratna -- View this message in context: http://www.nabble.com/basic-question-about-maven-tp9864p9864.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 -- -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing existing project
On Mon, Feb 23, 2009 at 3:51 PM, Steve Cohen sco...@javactivity.org wrote: You should also look at continuous build systems like Hudson or CruiseControl. We're probably too small for those sorts of systems. No one is too small for Hudson! Hudson installs in five minutes. All you need is JDK 1.5 or higher. If you're running Eclipse or Maven, you've already satisfied that requirement. Hudson contains its own server using winestone. It is a self contained JAR. You simply run a single Java command, and it's up and running. Setting up a build project in Hudson is completely intuitive. Its graphical with a complete help system. It integrates with CVS, Subversion, Ant, Maven, and even Jira and Bugzilla. The only thing I suggest is that you have enough diskspace to store builds. Or, you can tell Hudson to delete builds older than a certain age or if there only save the X most recent builds. Try Hudson: https://hudson.dev.java.net/. You'll find it is an absolutely wonderful tool. And, I think it is one of the best run open source projects I have ever seen. They support is wonderful, and the developers behind it are very responsive to suggestions. -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing existing project
I am fairly new to Maven, so maybe there are things that I simply don't know the correct way of doing things. However, we did Mavenize one project, and we simply found that it wasn't worth the effort. We had a strong Ant build process and things were working very well there. The idea to Mavenize came from above. We rearranged our directory structure, but then realized that we were doing a few things that weren't quite standard. Getting these to work took a lot of time and effort. It involved modifying some code and changing the way we deployed. We had times when we were sure everything was okay with our Maven build, but then testing found holes that we didn't realize were there. After three weeks, we finally got the Maven build working.In the end, we have angry developers, a steep learning curve to learn how to work on a project that developers knew in and out, and a build process that isn't much better than what we had. As a result, we have decided not to Mavenize all of our projects. All new projects will use Maven. Some of the simpler projects may be mavenized, but we'll carefully evaluate them. That doesn't mean we didn't learn some neat tricks in the process. The biggest concerns having project A build a jarfile that project B requires. In the pre-Maven days, that meant checking in that built JAR into Subversion, then using svn:export to pick up that jar from the other project. Checking in JARs several times a day into our Subversion repository proved difficult in both process and room. Now that we have a Maven repository, we now use the deploy:deploy-file mojo to deploy that Jar to our Maven repository. If the receiving project is a Maven project, we can now pick it up using the standard dependencies methods in the pom.xml, and we are converting many of these dependent projects into Maven because here's a real advantage Maven does have for us. And for the few dependent projects that we cannot easily Mavenize, I now use Ant's get task to download the jars from the Maven repository. It isn't as clean as the way Maven does it, but it has proven easier to do than to Mavenize these difficult projects. So Mavenizing old projects isn't just a blanket thing to do. You have to evaluate what you have now, and what you expect to gain with Maven. Some projects are pretty straight forward, but if you have an older project with a complex build process, and a build process that fairly rigorous, moving to Maven simply doesn't buy you all that much. On Sun, Feb 22, 2009 at 9:04 AM, Steve Cohen sco...@javactivity.org wrote: I am consideringMavenizing a pre-existing project. This project consists of a Web Application (WAR file) and a server side JAR module, built from several Eclipse projects, some of which are dependencies of both modules, as well as many third party jars, both open source (many of which themselves use Maven, of course) and proprietary. Current build process is very rudimentary. The Eclipse projects do not currently use Maven naming standards for directories. To do builds, the simple Eclipse Export menu options are currently used. Deployment is manual and there are some annoying manual post-export tasks that must be run. Version control uses subversion, including a big ugly project containing static copies of binary jars. These are my main reasons for considering conversion to Maven. Questions: 1. Are there articles around detailing war stories about making the kind of move I am contemplating? I would like to read such before I get started. I have just purchased Maven: The Definitive Guide, and while the information there is very good, it tends to assume a start from scratch. I would like to keep the history in the Subversion respository if possible. 2. Would I be better served by renaming directories at the start to Maven Convention over Configuration standards or by overrriding the defaults all the way down the line? 3. Would I be better off building a local network repository containing both the open source and proprietary code needed or would it be better to create a local repository only for the proprietary stuff and get the open source stuff from a remote repository. Thanks. Steve Cohen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mavenizing existing project
The issue to us was fairly simple: We had a working build process. The developers knew the project. Everything was fine and dandy. We moved to Maven and lost three weeks of work. Developers don't understand the new process as well as the old process, we've fallen behind schedule. We had a strong build process. Granted, we spent a long time working with Ant to make the process strong and stable, but moving to Maven wouldn't give me back the time we spent. Maven gave us a standard way we setup a project, so developers will be familiar with it, but we already had that. Yes, new developers will have to learn the quirks, but now the current developers are stuck learning the new Maven way in a project they knew backwards and forwards. So, where did moving to Maven in this particular project benefit us? Was it worth the bad will generated? Was it worth the time we took which could have been spent doing actual coding? In our evaluation, the costs outweighed the benefits. We didn't get a better build process out of it. It didn't make our project easier to work with. And, it ended up costing us a lot of time and effort. We aren't abandoning Maven. We are still using it for new projects. We are still moving some older projects off of our old system and onto Maven. Sooner or later, those older projects we decided not to move to Maven will be rearchitected. At that time, we'll probably insist they convert over to Maven. On Mon, Feb 23, 2009 at 11:19 AM, Jon Georg Berentsen jon.georg.berent...@objectware.no wrote: -Original Message- From: David Weintraub [mailto:qazw...@gmail.com] Sent: 23. februar 2009 16:58 To: Maven Users List Subject: Re: Mavenizing existing project I am fairly new to Maven, so maybe there are things that I simply don't know the correct way of doing things. However, we did Mavenize one project, and we simply found that it wasn't worth the effort. We had a strong Ant build process and things were working very well there. The idea to Mavenize came from above. We rearranged our directory structure, but then realized that we were doing a few things that weren't quite standard. Why was this a bad thing? Getting these to work took a lot of time and effort. It involved modifying some code and changing the way we deployed. We had times when we were sure everything was okay with our Maven build, but then testing found holes that we didn't realize were there. Again, why was this bad? After three weeks, we finally got the Maven build working.In the end, we have angry developers, a steep learning curve to learn how to work on a project that developers knew in and out, and a build process that isn't much better than what we had. Not good. But the time spent will pay off. And 3 weeks is normal for å enterprise project. As a result, we have decided not to Mavenize all of our projects. All new projects will use Maven. Some of the simpler projects may be mavenized, but we'll carefully evaluate them. That doesn't mean we didn't learn some neat tricks in the process. The biggest concerns having project A build a jarfile that project B requires. In the pre-Maven days, that meant checking in that built JAR into Subversion, then using svn:export to pick up that jar from the other project. Checking in JARs several times a day into our Subversion repository proved difficult in both process and room. Now that we have a Maven repository, we now use the deploy:deploy-file mojo to deploy that Jar to our Maven repository. If the receiving project is a Maven project, we can now pick it up using the standard dependencies methods in the pom.xml, and we are converting many of these dependent projects into Maven because here's a real advantage Maven does have for us. And for the few dependent projects that we cannot easily Mavenize, I now use Ant's get task to download the jars from the Maven repository. It isn't as clean as the way Maven does it, but it has proven easier to do than to Mavenize these difficult projects. So Mavenizing old projects isn't just a blanket thing to do. You have to evaluate what you have now, and what you expect to gain with Maven. Some projects are pretty straight forward, but if you have an older project with a complex build process, and a build process that fairly rigorous, moving to Maven simply doesn't buy you all that much. Yes. Maven is a complex thing to learn, but it is better than anything I have seen. On Sun, Feb 22, 2009 at 9:04 AM, Steve Cohen sco...@javactivity.org wrote: I am consideringMavenizing a pre-existing project. This project consists of a Web Application (WAR file) and a server side JAR module, built from several Eclipse projects, some of which are dependencies of both modules, as well as many third party jars, both open source (many of which themselves use Maven, of course) and proprietary. Current build process is very rudimentary. The Eclipse projects do not currently use Maven naming
Re: Mavenizing existing project
-mail: users-h...@maven.apache.org -- -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven, offline use and source control
Get Nexus http://nexus.sonatype.org/ for your Maven repository. It's free, and is a true Maven repository. Originally, I was using my own repository using SCP, but a true Maven repository has features that Maven clients can't emulate alone. The big difference between Ant and Maven is that Ant describes how you do a build and Maven describes the project and its dependencies. In Ant, you need to figure out your dependencies on their own and make sure they are locally available. Maven is suppose to work out its dependency matrix. For example, you may know you need foo.jar, and that foo.jar depends upon bar.jar which depends upon fubar.jar and barfoo.jar. In Ant, you would have to have all of these available before you do a build. In Maven, you merely state that you need version 1.2 of foo.jar, and Maven understands that you also need the other jars and what versions. Unlike Ant, Maven assumes you have some sort of Maven Repository, and that it's normally network accessible. In Maven, you don't check in JARs and other binaries .You version them and store them in a Maven repository for fetching. They are downloaded when you need them. Yes, they might be cached in your ~/.m2 directory or maybe stored locally on a internal repository. In Maven you always need a repository. This could be your ~/.m2 directory, so if you are not connected to the Internet, you could download all the Jars you might need into your ~/.m2 repository. I guess you could even create a Subversion repository for a ~/.m2/repository directory structure to allow people to check out the needed Jars and create an ~/.m2/repository directory. But normally, Maven assumes Internet connectivity of some sort when it needs something that isn't already cached. On Thu, Feb 12, 2009 at 11:24 AM, John Willemin j...@buttdynoracing.com wrote: Alright - I am pretty new to Maven and have some newbie questions. It's a little wierd for me coming from seven years of Ant. I have read through the definitive guide (mostly skimming) and set up a simple web application using archetype:create. I like that it tries to enforce directory structure as well as build lifecycle. I have added a few dependencies to the application and I'm trying to figure out how folks use Maven in a mostly-offline environment. We have a situation where the developers all have laptops. At work, these are not hooked up to the Internet. If we want to check stuff into Subversion, we need to go home. In a Maven project, is it assumed that the jars are not going to be checked in with the source code and that they'll just be auto-snagged over the Internet during a build? If you want to move your Maven project to a different network, where you won't have internet access, do you copy your local .m2 directory as well as the project, or do you set up a new central repository on that network? That's a starting point until I get my head better wrapped around this :) Thanks, John - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Deployment of non-Maven Files into Maven Repository
We have a project that produces about a dozen separate JAR files. These JARS are in turn used by a project that is built with Maven. I can do the deployment like this: $ mvn deploy:deploy-file -DrepositoryId=snapshot \ -Durl=http://aladdin.solbright.com:8082/nexus/content/repositories/snapshots/; \ -Dfile=_build/tmp/api-lib/adbilling.jar \ -DgroupId=com.solbright -DartifactId=adbilling \ -Dversion=1.0-SNAPSHOT \ -Dpackaging=jar -DgeneratePom=true For each one. That works. It goes into my Maven repository, and my Maven project can do the download. However, I am using Hudson which makes it a bit difficult to use a shell script (not impossible, but difficult). It would be nicer if I could use a pom.xml to set all of these settings. Actually, what I really want is a way in a POM file where I can specify all of these files at once. That is, specify in the pom all of the files that need to be deployed. Is that possible without specifying multiple POM files? -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: nexus can't find maven-archetype-plugin?
Have you tried logging in as the user running Hudson, then cd to the ~/.hudson/jobs/$PROJECT/workspace directory and building it manually? Most of the time, this will help pin point out the type of errors you're getting. It sounds like Maven isn't setup to point to the Maven repositories. BTW, why would Hudson be running the architype-plugin anyway? This is used to setup an initial work area for a Maven project. It requires command line input which I suspect may be the problem. On Wed, Jan 28, 2009 at 4:16 AM, Jens Rapp tec_la...@gmx.de wrote: hi, i'm playing around with nexus as repository manager and now have a little problem: the maven-archetype-plugin can't be found. most of the other plugins work maven uses the standard public repository group in nexus. what do i have to do for being able to use em all??? -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Assemblies
. http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_fileSet You should take a look at the filemode ... Hm. under which user are you running maven ? I actually am using filemode, and it is setting the file mode for these files. However, it seems that the username and usergroup are being set to 0/0. I don't think this is due to the filemode parameter because this was happening before I used it. And, yes, the username and groupname are being set on the lib folder to the username and groupname I am logged in as. But, the question is why does the lib folder get set to build/users while the bin and conf get set to 0/0? And, how can I set this? In Ant, there were parameters in the tar task that allowed me to set the user and group. I didn't see anything in the Maven assembly parameters.. 2). My boss wants to know why is the assembly file called bin.xml. I told him because the assembly file is a bin type, and you name the assembly file after the assembly type. He wants to see documentation to this effect. Is there such documentation? I know you can call your assembly file anything you want, but if this is the Maven standard, I want to stick with it. First you can call it the way you like but there are some defaults in there http://maven.apache.org/plugins/maven-assembly-plugin/assembly-mojo.html#descriptorRefs Or in Maven: The definitive Guid at section Predefined Assembly Descriptors...you can see things linke bin are referenced... Once I saw what Assemblies were, I was able to search for assembly files that happen to be on the Internet. I found a lot of examples, and it became obvious that they were named bin.xml. After a while, I realized why since you can have multiple assemblies, and this assembly is a bin type. Unfortunately, my boss thought the name was confusing. I pointed out this was standard practice and he wanted to see the actual written standard. I think I convinced him why it is done that way. I pointed out that the file is already stored in a directory called assemblies, and that projects can have multiple assembly files (for example, source code distribution, and tarball distribution. He was reasonably happy with that. -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven Assemblies
I'm building a JAR file that needs to be packaged with some shell scripts and some configuration files. The shell scripts will be in a bin directory, the configuration files will be in a conf directory, and I'd like the jar in the lib directory with any of the dependency jars mentioned in the POM. I've read about Assemblies in Maven -- The Definitive Guide, but I am a little confused about them. It looks like the Assembly is separate from the POM. Is this true? If it is separate from the POM, where is it suppose to live, and how does the POM refer to it? I figure this is a pretty standard setup for a standalone JAR application, but I haven't seen any examples of this particular setup. -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Assemblies
USt.IdNr: DE191347579 52146 Würselen http://www.soebes.de - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- -- David Weintraub qazw...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Dependency Relationships in EARs
I've just started using Maven, and I'm struggling with a few things. I took one our our components I build with Ant, and created a Maven build for it. This is a set of foundation classes that several of our projects use, so I called it foundation.jar. So far, so good, I specified a set of JARS that this foundation.jar was dependent upon, and Maven downloaded the other 3rd party jars that were needed. This whole thing packaged itself all nice and neat. I downloaded this to our internal Maven Repository, and created a new EAR project. The project was an empty skeleton, but I specified it needed this foundation.jar. The ear packaged with the foundation.jar, but without any of the 3rd party JARS that foundation.jar needs in order to work. So, how do I get Maven to package all the needed 3rd party JARs that foundation.jar needs? -- -- David Weintraub [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependency Relationships in EARs
Sure: Here's the POM for the Foundation: project xmlns=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; modelVersion4.0.0/modelVersion groupIdcom.solbright/groupId artifactIdfoundation/artifactId packagingjar/packaging version0.1/version namefoundation/name urlhttp://maven.apache.org/url dependencies dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopetest/scope /dependency dependency groupIdjboss/groupId artifactIdjboss-j2ee/artifactId version4.0.0/version /dependency dependency groupIdlog4j/groupId artifactIdlog4j/artifactId version1.2.4/version /dependency dependency groupIdjdom/groupId artifactIdjdom/artifactId versionb7/version /dependency dependency groupIdjavax.servlet/groupId artifactIdjsp-api/artifactId version2.0/version /dependency dependency groupIdorg.log4j/groupId artifactIdlog4j/artifactId version0.0.1/version /dependency dependency groupIdcom.enterprisedt/groupId artifactIdedtFTPj/artifactId version1.5.3/version /dependency dependency groupIdcom.oracle/groupId artifactIdojdbc14/artifactId version10.2.0.2/version /dependency dependency groupIdde.dankomannhaupt/groupId artifactIdjdbcappender/artifactId version2.1.01/version /dependency dependency groupIdcom.oracle/groupId artifactIdxsu/artifactId version1.2/version /dependency dependency groupIdorg.springframework/groupId artifactIdspring-jdbc/artifactId version1.2.8/version /dependency dependency groupIdcom.lowagie/groupId artifactIditext/artifactId version1.3/version /dependency dependency groupIdnet.sourceforge/groupId artifactIdjox/artifactId version1.17b3/version /dependency dependency groupIdorg.apache.xmlgraphics/groupId artifactIdfop/artifactId version0.20.4/version /dependency dependency groupIdgnu-regexp/groupId artifactIdgnu-regexp/artifactId version1.1.4/version /dependency dependency groupIdcom.oreilly/groupId artifactIdservlet-cos/artifactId version20Nov2000/version /dependency dependency groupIdcommons-beanutils/groupId artifactIdcommons-beanutils/artifactId version1.6/version /dependency dependency groupIdjavax.activation/groupId artifactIdactivation/artifactId version1.1/version /dependency /dependencies /project And here's the sample EAR: project xmlns=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; modelVersion4.0.0/modelVersion groupIdcom.solbright/groupId artifactIdtest-ear/artifactId packagingear/packaging version1.0-SNAPSHOT/version nametest-ear/name urlhttp://maven.apache.org/url dependencies dependency groupIdcom.solbright/groupId artifactIdfoundation/artifactId version0.1/version /dependency dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopetest/scope /dependency /dependencies /project There's nothing in the EAR except for this dependency of foundation.jar which is stored in our company's remote repository. I saw that the pom.xml for Foundation is stored in the foundation.jar, and I thought that's where it gets the dependency list from. I'm thinking that the problem isn't in the POM as much as it is in the repository setup. On Thu, Apr 10, 2008 at 4:49 PM, Wayne Fay [EMAIL PROTECTED] wrote: The dependencies of your dependencies are called transitive dependencies. Normally, Maven2 is able to figure out what you need and build/package things properly. So, you must be doing something wrong to get these results. Can you send the 2 pom.xml files you created, 1 for foundation, and 1 for the EAR? I imagine you are doing something wrong with the scope. Wayne On 4/10/08, David Weintraub [EMAIL PROTECTED] wrote: I've just started using Maven, and I'm struggling with a few things. I took one our our
Re: Dependency Relationships in EARs
Whoops, this was a local repository error. I am manually doing the repository, and copying the JARS, creating the POMs, etc. I accidently called the POM for the foundation JAR file, foundation-0.1.xml instead of foundation-0.1.pom and that caused the problem. Changing the name fixed the issue. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
