Classpath woes ...
I'm using Maven to do a number of things and I'm unable to obtain access to a jar dependency using two plugins to accomplish my purpose. First I use maven to jar my application and it writes an executable JAR file and a manifest that contains my needed Jar file for log4j. I then use the maven-exec-plugin to execute the jarred application from the command line using using "mvn exec:exec". I have tried all combinations of configurations and ... my goal is not to have to copy the log4j jar into my target directory. That's the only way I can see the jar on the classpath. The maven-exec-plugin site says that the jars will be seen on the classpath automatically. And, I'm "USING" maven because I build and do everything else using Maven. Does anyone have any suggestions as to the *BEST* way to run an executable JAR made by Maven and needing a project dependency? Thanks, David Here's the manifest Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven Built-By: piratepete Build-Jdk: 1.5.0_08 Package: org.appfuse Main-Class: org.appfuse.ApplicationMain Class-Path: junit-3.8.1.jar log4j-1.2.13.jar And, the project's pom http://maven.apache.org/POM/4.0.0"; xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> 4.0.0 org.appfuse quickstart jar AppFuse QuickStart 1.0-SNAPSHOT 2006 http://appfuse.dev.java.net 2.0.4 The Apache Software License, Version 2.0 http://www.apache.org/licenses/LICENSE-2.0.txt repo dlwhitehurst David Whitehurst [EMAIL PROTECTED] CIBERsites ADM US -6 install maven-compiler-plugin 1.5 1.5 org.apache.maven.plugins maven-jar-plugin org.appfuse.ApplicationMain org.appfuse true org.codehaus.mojo exec-maven-plugin exec java -jar -classpath log4j target/quickstart-1.0-SNAPSHOT.jar maven-eclipse-plugin org.springframework.ide.eclipse.core.springnature org.springframework.ide.eclipse.core.springbuilder true true 1.0 maven-idea-plugin true true true false central http://repo1.maven.org/maven2 maven-snapshots http://snapshots.repository.codehaus.org junit junit ${junit.version} true log4j log4j ${log4j.version} ant ant 1.6.5 maven-checkstyle-plugin org.codehaus.mojo cobertura-maven-plugin maven-javadoc-plugin maven-jxr-plugin maven-pmd-plugin maven-surefire-report-plugin 3.8.1 1.2.13
Re: Examples of using Spring with JUnit
Mick: Take a look at the source for appfuse2 David On 11/9/06, Mick Knutson <[EMAIL PROTECTED]> wrote: I am wondering if anyone has some examples of calling a test Spring resource (test/resources/applicationContext.xml) from JUnit to run when Maven is running my Unit tests... -- Thanks DJ MICK http://www.djmick.com http://www.myspace.com/mickknutson
Calling parameters
What am I doing wrong? I've created additional goals for a plugin for Maven and when I call the goal, I don't get the property. Is my syntax wrong? e.g. mvn myplugin:mygoal -Dmypropertyfile=properties.xml Is this correct syntax? David
Re: JDK 1.5 Problem
David: You stated that you're moving "from" maven2 to ant. You need to be sure that the proper version of java is set on your path. If you type "$java -version" and it's not what you expect, then the Ubuntu java symbolic link is probably in place and an old version is installed somewhere. Do a "which java" on the command line and you'll get the path to $JAVA_HOME/bin as it's set right now. You can leave the old java installed if you like by just deleting the symbolic link and recreating it pointing the $JAVA_HOME/bin of your choice. Reply with any other questions if this doesn't work for you. Thanks David W On 11/8/06, David Lund <[EMAIL PROTECTED]> wrote: JDK Problem : Im using Ubuntu Dapper Drake v6.06. I have an existing project that I'm trying to convert to maven2 from ant. However, I'm having JDK issues, basically its compiling in JDK 1.3 rather than 1.5, see error below: LinkGroup.java:[16,25] generics are not supported in -source 1.3 (try -source 1.5 to enable generics) public Collection getEntities(); I have set the JAVA_HOME variable to point to JDK 1.5, however the interesting thing is I dont have java 1.3 installed so I dont know where its picking that version up from. Could this be a Unbuntu problem, as I noticed Maven2 hadn't been tested on it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 1.0.2
Scott: It sounds as if you're looking for the ground that I'm always looking for. I think you're going to find that you have to create some play projects and try it out. I don't think any books have done it justice. I would roll up the sleeves and try it out. David On 11/6/06, Scott Purcell <[EMAIL PROTECTED]> wrote: Hello, I need to understand how Maven works in order to properly evaluate it for my own needs, and also it appears I am getting more Maven2 type of applications that I need to deploy. So, last week, I ordered the Maven 'A Developers Notebook' and got to around chapter 3 over the weekend. Anyway, it is of course based on Maven 1.0.2. I also downloaded the large PDF from Mergere. The PDF, seemed a bit daunting ... and chapter 1, 2 of the Developers Notebook were pretty simple. Anyway, should I stay the course and get through the book "A Developers Notebook" or should I strike that off, and head for the new? Thanks for any input. Sincerely Scott
Re: Maven 2.0.4 Project Creationm Problem
mvn archetype:create -DarchetypeGroupId= -DarchetypeArtifactId= \ -DarchetypeVersion= -DgroupId= -DartifactId= Also be sure that you use the -DarchetypeVersion= ... that's probably your problem David On 11/6/06, Orangeskool <[EMAIL PROTECTED]> wrote: Hi I am trying to create my first Maven project as guided in the "Maven GettingStarted Guide" This is my first step after installing Maven 2.0.4 and confi.(mirrors,profiles,proxy..) mvn archetype:create -DgroupId=com.test.app -DartifactId=my-test-app But I get the following errors. [INFO] Scanning for projects... [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [archetype:create] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Cannot execute mojo: create. It requires a project with an existing pom.xml, but the build is not using one. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: < 1 second [INFO] Finished at: Mon Nov 06 16:50:46 IST 2006 [INFO] Final Memory: 1M/3M [INFO] I try with following diffrent option : mvn -U archetype:create -DgroupId=com.test.app -DartifactId=my-test-app mvn -U -e archetype:create -DgroupId=com.test.app -DartifactId=my-test-app mvn -X archetype:create -DgroupId=com.test.app -DartifactId=my-test-app Regards, Pk. -- View this message in context: http://www.nabble.com/Maven-2.0.4-Project-Creationm-Problem-tf2581919s177.html#a7197288 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: We need some explanation ...
Franz: Yes, recipes or prescriptions for doing various types of projects. David On 11/5/06, franz see <[EMAIL PROTECTED]> wrote: Good day to you, David, Hhmmm...I'm not sure I understand your message. What do you mean by "neutral to maven or any specific plugin" ? Regading the more specific builds, im guessing you want to create a cookbook. If so, then you can may want to contribute your recipes in the wiki (see [1]) or in the maven site (see [2]). To contribute to the maven site, checkout the source from [3] using SVN. Then modify the source of the docu that you want to change. Afterwhich, create a jira issue in [4] and submit your patch. Btw, the format of the documentation is in APT (see [5]) Cheers, Franz [1] http://docs.codehaus.org/display/MAVENUSER/Home [2] http://maven.apache.org/run-maven/cookbook/index.html [3] http://svn.apache.org/repos/asf/maven/site/trunk/ [4] http://jira.codehaus.org/browse/mng [5] http://maven.apache.org/guides/mini/guide-apt-format.html David Whitehurst wrote: > > Franz: > > This is excellent discussion. This was what I was looking for. I had > seen > the intro to the lifecycle link before but that seems out there somewhat > for > most folks. I'm looking to put together more documentation that is > neutral > to maven or any specific plugin and try to focus on e.g. J2EE packaging. > If > I wanted to put together a project for a web service and package that > service for JBoss, the information for using Maven or the corresponding > plugin is scarce. I want to define my project and package it and I don't > want to spend all my time trying to figure out how to use Maven2 even > though > I might have used Maven1 a little years past. > > Does that make sense? There is a lot of information, but it has very > little > organization. Most of it's complicated and seems to run me away instead > of > convincing me to give it a try. I know better so I want to figure things > out more and document it for others. > > Thanks, > > David Whitehurst > > On 11/5/06, franz see <[EMAIL PROTECTED]> wrote: >> >> >> Good day to you, David, >> >> The generate-sources, phase is used for auto code generation. An example >> for >> this would be the maven-modello-plugin (see [1]) which allows the >> creation >> of Xpp3 Readers, Writers and the corresponding models. Running an XDoclet >> maven goal would most probably be bound here if that goal produces source >> codes. >> >> For the process-sources, its the phase used when what you're processing >> (prior to compilation) is the sources themselves. hhmm..can't think of a >> good example though... >> >> The generate-resources phase on the other hand, is like the >> generate-sources >> phase, except that this auto generates resources (i.e. xmls, property >> files) >> instead of codes. An example which uses that is the maven-eclipse-plugin. >> the eclipse:eclipse goal which generates the .classpath and .project >> resources is bound to that phase (see [2] for the released documentation >> and >> for [3] for the staged unreleased documentation). And if you have an >> XDoclet >> goal which produces resources such as schemas, that goal would most >> likely >> be bound to this goal. >> >> And as for the process-resources phase, this phase handles the >> resources-related processes prior to compilation. An example of this is >> the >> maven-resources-plugin, which filters and copies resources (see [4] for >> the >> released documentation and for [5] for the staged unreleased >> documentation). >> And example of a resource would be a property file. >> >> For more information about the lifecycle, kindly see [6]. And if you want >> to >> suggest somethings or have some feebdacks or something, you might want to >> create a jira issue in [7] under the "Documentation: Introduction" >> component. >> >> In relation to the eclipse plugin, only one goal (that i know of that >> works) >> is bound to a lifecycle phase, and that's the eclipse:eclipse goal which >> is >> bound to the generate-resources phase. >> >> And with regards to the goals, the current plugin documentations now have >> their goals documented. However, not all of these new plugin >> documentations >> have been released yet (plugin documentations released after Oct 16, 2006 >> are probably the latest ones..since it was the last time [8] was >> updated). >> But nonetheless, if you have any comments about the plugin documentation, >> you can create a jira issue under that
Re: We need some explanation ...
Franz: This is excellent discussion. This was what I was looking for. I had seen the intro to the lifecycle link before but that seems out there somewhat for most folks. I'm looking to put together more documentation that is neutral to maven or any specific plugin and try to focus on e.g. J2EE packaging. If I wanted to put together a project for a web service and package that service for JBoss, the information for using Maven or the corresponding plugin is scarce. I want to define my project and package it and I don't want to spend all my time trying to figure out how to use Maven2 even though I might have used Maven1 a little years past. Does that make sense? There is a lot of information, but it has very little organization. Most of it's complicated and seems to run me away instead of convincing me to give it a try. I know better so I want to figure things out more and document it for others. Thanks, David Whitehurst On 11/5/06, franz see <[EMAIL PROTECTED]> wrote: Good day to you, David, The generate-sources, phase is used for auto code generation. An example for this would be the maven-modello-plugin (see [1]) which allows the creation of Xpp3 Readers, Writers and the corresponding models. Running an XDoclet maven goal would most probably be bound here if that goal produces source codes. For the process-sources, its the phase used when what you're processing (prior to compilation) is the sources themselves. hhmm..can't think of a good example though... The generate-resources phase on the other hand, is like the generate-sources phase, except that this auto generates resources (i.e. xmls, property files) instead of codes. An example which uses that is the maven-eclipse-plugin. the eclipse:eclipse goal which generates the .classpath and .project resources is bound to that phase (see [2] for the released documentation and for [3] for the staged unreleased documentation). And if you have an XDoclet goal which produces resources such as schemas, that goal would most likely be bound to this goal. And as for the process-resources phase, this phase handles the resources-related processes prior to compilation. An example of this is the maven-resources-plugin, which filters and copies resources (see [4] for the released documentation and for [5] for the staged unreleased documentation). And example of a resource would be a property file. For more information about the lifecycle, kindly see [6]. And if you want to suggest somethings or have some feebdacks or something, you might want to create a jira issue in [7] under the "Documentation: Introduction" component. In relation to the eclipse plugin, only one goal (that i know of that works) is bound to a lifecycle phase, and that's the eclipse:eclipse goal which is bound to the generate-resources phase. And with regards to the goals, the current plugin documentations now have their goals documented. However, not all of these new plugin documentations have been released yet (plugin documentations released after Oct 16, 2006 are probably the latest ones..since it was the last time [8] was updated). But nonetheless, if you have any comments about the plugin documentation, you can create a jira issue under that plugin ([9] for maven-eclipse-plugin, [10] for maven-resources-pluign, etc). And lastly, goals are plugin-specific (a plugin consists of 1 or more goals). Phases are were a goal can bind to so that you can use a lifecycle (sequence of phases) to execute your goals in a specific manner. At least, these are my notes. :-) Did I answer your question? Cheers, Franz [1] http://modello.codehaus.org/ [2] http://maven.apache.org/plugins/maven-eclipse-plugin/ [3] http://people.apache.org/~epunzalan/maven-eclipse-plugin/ [4] http://maven.apache.org/plugins/maven-resources-plugin/ [5] http://people.apache.org/~aramirez/maven-resources-plugin/ [6] http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html [7] http://jira.codehaus.org/browse/mng [8] http://docs.codehaus.org/display/MAVEN/Maven+Plugin+Documentation [9] http://jira.codehaus.org/browse/MECLIPSE [10] http://jira.codehaus.org/browse/MRESOURCES David Whitehurst wrote: > > After the message about the documentation, I kind of felt the same way. I > like ANT because I can look at my build.xml file and see what each target > will do exactly. Maven2 is much different but it's more standard. That's > good because we all can begin to learn each goal and then know as we issue > the keystroke what's going to happen and what to expect. > > I started moving around some of the texts on the Maven User WIKI at > http://docs.codehaus.org/display/MAVENUSER/Home > > As long as my interest holds, I plan to keep working on the basic > documentation for using Maven. I'm interested in Appfuse now and they've > moved to Maven2 and away from my old friend ANT. This mess
We need some explanation ...
After the message about the documentation, I kind of felt the same way. I like ANT because I can look at my build.xml file and see what each target will do exactly. Maven2 is much different but it's more standard. That's good because we all can begin to learn each goal and then know as we issue the keystroke what's going to happen and what to expect. I started moving around some of the texts on the Maven User WIKI at http://docs.codehaus.org/display/MAVENUSER/Home As long as my interest holds, I plan to keep working on the basic documentation for using Maven. I'm interested in Appfuse now and they've moved to Maven2 and away from my old friend ANT. This message is a request to get some answers on some goals that I'm not exactly familiar with yet. I'm using the Maven plugin for Eclipse and I figured that I would start with explanation of the lifecycle phases. Let's document through mvn compile. - Initialize -Generate sources -Process sources -Generate resources -Process resources -compile I understand initialize and compile. Can someone relate the ones in between for me in relation to doing things e.g. running xdoclet, moving properties files, building schema, etc.? The official documentation discusses validate, compile, and test. I understand these, but the eclipse plugin has more. We should document goals that are used the most for various types of projects. If this was ANT, I'd know what these goals did exactly. Can someone tell me what the above goals will do when I run them in eclipse? Also, I imagine some of them may or may not be there. That would be worth documenting for folks on the WIKI. Thanks, David Whitehurst
Re: Maven rant
Excellent thoughts! I want to adopt maven2 and in-fact we are debating the issue at work. And the cons are the lack of documentation and the fact that ANT is easier to customize. And, that's what we all do, customize everything to support our needs. I WIKI everything and I wish I had a public WIKI to write in that I felt comfortable that would stay there for all to see and wouldn't change. So, what we need is the maven folks (whomever's in charge) to open a WIKI and leave it alone. I think that maven:site is fine for projects outside of maven and those that someone wants to play webmaster. But, the Maven site should be more open and if we get folks that provide wrong documentation, then boot them or remove their submissions (moderate). I'm new here, but this is like going to church and the message is always "this is how we do things here". It's a community or gathering and if it's not comfortable to speak up and say I have something to say, then it's not a public thing. I agree with you because it's not easy to figure out how to get involved. Also, a portion or area of the server was out yesterday beause of a bug and it was very difficult for me to determine if this was a ditched effort or that someone was keeping the public away from something until a problem was fixed. So when the WIKI opens up for assistance, let me know because I'm ready to share my notes. E.g. once I find out how to build plugins and debug them easily, I'll document everything. And, do I keep this for myself or does the community want my notes? I started a book for a publisher and didn't finish it due to timing, but I do have a chapter that clearly describes the installation and daemonizing and windows service installation for JBoss. Should I keep this since I didn't get published for sale? Or should I share it? I want to share it, but I can't host from my house due to my ISP setup. If I had a public hosting, I would drop it there immediately. I hope folks speak up to your email because I wholeheartedly agree. I do think, to speak for the Maven "boys" that everyone just wants things to be permanent and standard. And, that's very difficult to sustain I imagine. Good email, David On 11/5/06, franz see <[EMAIL PROTECTED]> wrote: Good day to you all, fellow Maven Users, I agree that right now, maven documentation is scattered. We have the apache maven site ([1]), the docus you can build with the source code (checkout the source and do mvn site [2]...and btw, the maven site can be checked out as well [3]), the mailing list [4], BBWM ([5]), the wiki, and other 3rd party sources. Furthermore, the maven users community must be able to participate in maven's documentation. Maven is an open source project, and just like any other open source project, it's only as good as the community backing it up. So how do we get more involvment from the maven users community? MAVEN SITE A suggestion make the apache maven site wiki-like, so that users can be involved in the documentation as well. Maybe we can lobby this with the maven developers. Currently though, if a non-committer wants to contribute something to the documentation, the process would be to create a JIRA issue, create a patch, and submit that patch. However, you won't see the changes until the patch gets approved. So it would be nice if we can have a staging site if we can't make teh maven site wiki-like. These staging site can be linked to actual page itself for easy access. Furthermore, links to the mailing list and wiki should be move visible. This will make the maven site the center of all these documentations. DOCS FROM SOURCE CODES For those docs that are build from the checked-out code, they're already incorporated in the maven site. For those that are not included in the maven site, that means that those built docs are for the current unreleased versions. The docs found in the maven site are for the released. So if you're using a snapshot and you want to find the docs for it, try doing mvn site. if something comes, good for you. if none, oh well. IMO, docs should only be updated every before release anyway (which is currently happening wit the apache maven plugins). MAILING LIST As for the mailing list, as of now, if we want something from the mailing list, we have to search for existing information (which may or may not be updated or true), or ask it. I'm not sure, but i don't think there's a "pin thread" option here. Also, there are no subcategories (for the maven-users) for easy searching. What we could probably do is to create subcategories (subforums). As to what these subcategories are, im not sure...any suggestions? Also, maybe we can provide a wiki section for each category, so that we can store there important information...sort of a maven users notes. Furthermore, going back to the maven site is now possible thanks to the new skin of the maven forums in nabble. BBWM Maybe this can be one of the subcategories (subforum)..and of course, with
Re: Can't get project.xml to work ...
John: Thanks. I got things to run. It didn't pick up my source and compile, but it did find e.g. the jdom.jar I went to their site to get the goodies and use in the dependency tag. I have to now figure why the JAR got build with only my jars inside, the src did not compile nor did the classes get built and put in the JAR. Anyhow, I am closer. I like what Maven can do because we have a new Open Source project on java.net and I want to do the Maven thing on my server and then mail a letter, with links to the Maven reports daily. Excellent idea. Thanks David John Casey wrote: You may need to read a little more in-depth on the maven purpose. The idea is that everything in your /lib directory will not actually be stored with your project, at least w.r.t. version management. Instead, these dependency libraries should be maintained in a central repository (or set of repositories...), where the owner of each project can post his/her artifacts (jars, etc.) for all to use. Then, when you use maven to build your project, it will pick up the information on each dependency (from the element structure), download it, and add it to the build classpath. When you use maven to build a binary distribution, it will bundle these jars with the rest. I really can't do justice to the elegance of this system, though. Reading the docs (don't forget the WIKI...it's pretty important, too) is really the only way to properly understand the goals of maven. It is not simply a drop-in replacement for Ant; it encapsulates and enforces a lot more of the best practices out there for maintaining working codebases. At first it may seem hard to get the hang of, but once you do you'll probably realize like most of the rest of us that this thing is pretty revolutionary... Cheers, john On Sun, 2004-01-25 at 23:02, David Whitehurst wrote: I'm confused, what does my project depend on other than the JAR's that are in my /lib folder, but that's on CVS too along with /src. Am I supposed to be looking for the java sdk jar? I only depend on the /lib jars and the /conf folder, but each are on CVS, where would I download that from? I'm really confused now. David John Casey wrote: - This would do the trick...this is actually a section in which you're supposed to list the dependencies upon which your project...well...depends. As such, it should be a set of entries that look something like this: commons-jelly common-jelly-tags-xml 20030211.142729 or some such. The group id is a grouping mechanism, which helps to determine the directory structure on the remote repository where the dependency jar can be downloaded. The artifact id is the the name of the jar file itself, minus the version and the '.jar' suffix. The above specification would translate to the following download URL on the remote repository: http://the.remote.repository.url/base/path/commons-jelly/jars/commons-jelly-tags-xml-20030211.142729.jar Leaving any of the above element bodies empty will no doubt result in a NPE, since there is literally no value for something that expects one. Hope that helps. -john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can't get project.xml to work ...
I'm confused, what does my project depend on other than the JAR's that are in my /lib folder, but that's on CVS too along with /src. Am I supposed to be looking for the java sdk jar? I only depend on the /lib jars and the /conf folder, but each are on CVS, where would I download that from? I'm really confused now. David John Casey wrote: - This would do the trick...this is actually a section in which you're supposed to list the dependencies upon which your project...well...depends. As such, it should be a set of entries that look something like this: commons-jelly common-jelly-tags-xml 20030211.142729 or some such. The group id is a grouping mechanism, which helps to determine the directory structure on the remote repository where the dependency jar can be downloaded. The artifact id is the the name of the jar file itself, minus the version and the '.jar' suffix. The above specification would translate to the following download URL on the remote repository: http://the.remote.repository.url/base/path/commons-jelly/jars/commons-jelly-tags-xml-20030211.142729.jar Leaving any of the above element bodies empty will no doubt result in a NPE, since there is literally no value for something that expects one. Hope that helps. -john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Can't get project.xml to work ...
Hi: I installed maven, point to /bin and MAVEN_HOME is there too. I can run "maven test' it downloads a bunch of things, but creates no classes or docs, just folders in target dir. I setup a project.xml in my workspace/DBPirate dir for my project. When I run I keep getting the following error: java.lang.NullPointerException at org.apache.maven.project.Project.standardToLegacyId(Project.java:1566 I changed the project name, and the cvs point, because my project is on java.net at /cvs level but the project is actually at /cvs/dbpirate/DBPirate because my web is at /cvs/dbpirate/www. I use no JUnit yet, but I installed that too. Anyhow, heres my project.xml ... I'm stumped. 1 dbpirate dbpirate 1.0a - PiratePete Software Group http://www.piratepetesoftware.com/ 2003 com.piratepete.dbpirate - DBPirate is a Multi-Database Query and Browsing Tool Later a description will be provided. https://dbpirate.dev.java.net/ localhost /var/www/html/maven/ /var/www/html/builds/ - - cvs:pserver:[EMAIL PROTECTED]:/cvs:dbpirate - https://dbpirate.dev.java.net/source/browse/dbpirate/DBPirate/ - - 1.0a 1.0a DBPirate v1.0a - 1.0a 1.0a HEAD - - DBPirate User List [EMAIL PROTECTED] [EMAIL PROTECTED] - http://www.mail-archive.com/[EMAIL PROTECTED]/ - Maven Developer List [EMAIL PROTECTED] [EMAIL PROTECTED] - http://www.mail-archive.com/[EMAIL PROTECTED]/ - - David Whitehurst piratepete [EMAIL PROTECTED] - Jeremy Whitlock jcscoobyrs [EMAIL PROTECTED] - - - [EMAIL PROTECTED] /src - - - - - - ${basedir}/lib - *.zip *.jar Thanks for any help, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]