Re: Standard Directory Layout , src/main/config, and profiles
I agree with creating a more detailed document regarding directory
conventions. I like the conventions documented so far, but there do seem to
be some ambiguities and holes. I too have been unsure of the purpose of
src/main/config. However, I have been putting design-time and build-time
configuration files there. Here are some specific examples of what I have
done:
src/main/config/cactus
cactus-web.xml
jspRedirector.jsp (questionable)
src/main/config/checkstyle
checkstyle-header.txt
checkstyle-suppressions.xml
checkstyle.xml
src/main/config/jalopy
jalopy.xml
src/main/config/pmd
ruleset.xml
src/main/config/xdoclet
(XDoclet merge files)
Here are the corresponding properties in project.properties:
cactus.src.mergewebxml=${basedir}/src/main/config/cactus/cactus-web.xml
maven.checkstyle.header.file=${basedir}/src/main/config/checkstyle/checkstyle-header.txt
maven.checkstyle.properties=${basedir}/src/main/config/checkstyle/checkstyle.xml
maven.checkstyle.suppressions.file=${basedir}/src/main/config/checkstyle/checkstyle-suppressions.xml
maven.pmd.rulesetfiles=${basedir}/src/main/config/pmd/ruleset.xml
maven.xdoclet.webdoclet.mergeDir=${basedir}/src/main/config/xdoclet
There is no property for Jalopy here because I use the jalopy.xml file with
the Jalopy plugin for Eclipse.
I hope that helps.
-- Chuck
On 1/11/06, Stephen Duncan [EMAIL PROTECTED] wrote:
I've got a few questions on the Standard Directory Layout described
here:
http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
For the most part I assume that what makes them standard is having a
maven plugin (i.e. one that works out of the box without a prefix for
definitions sake...) that uses said directory as a default. By that
logic, src/main/webapp needs to be on the list, and to the effect,
I've opened a JIRA issue:
http://jira.codehaus.org/browse/MNG-1953
My question, though, is what is src/main/config used for? Does any
plugin use that directory? I've seem some suggestion that
configuration files for build profiles be put here. I've also seen
that suggested as src/main/profiles/profile-name Is there guidance
on this?
Additionally, for questions like this, can we indicate some difference
between suggested guidelines for directories vs. actually used default
directories?
I think I'd like to see a document (possibly just modifying the
current one) to indicate for each standard directory which plugins use
it as a default. Maybe this should go into a directory guide, which
would be longer and more detailed than the current Introduction.
Any ideas?
--
Stephen Duncan Jr
www.stephenduncanjr.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Advanced File Modification Plugins (XSLT, XSLT Replacement, Regular Expression Replacement)
Stephen, Which app server are you using? I know that Tomcat allows you to override settings in web.xml with an environment-specific file (can't recall the name of the file). This allows you to deploy the same web.xml to each environment, but provide environment-specific overrides within each environment. This then obviates the need to do any sort of filtering during your build process. I believe WebLogic also provides an override mechanism. I would imagine that other app servers do as well. Therefore, my suggestion is to do a little research regarding this capability for your app server. If the capability exists, I would exploit it and scrap the need for filtering your web.xml file. -- Chuck On 1/11/06, Stephen Duncan [EMAIL PROTECTED] wrote: I've got the typical need to be able to build a war for different target environments where the difference between each environment is a few strings in configuration files for database dialect, logging levels, etc. Obviously, the typical solution is filtering, which is well supported in Maven. However, I prefer to develop my webapp by deploying to my web server straight from my source directory. So I use war:inplace, I have an inplace profile for my eclipse settings to target my output to src/main/webapp/classes, etc. Therefore I need to have some default value set in the source code, rather than a filter-string to be matched against by the resources plugin. Most of the files I care about are XML, so XSLT replacement would be ideal. I'd rather not maintain the XSLT files though, so I don't want a generic XSLT plugin so much (I think there's one of these in the Codehaus SVN). I want a plugin that uses XSLT or some other XML parsing to replace a given element in an XML file. That way I just configure the XPath expresion to match to replace against, and the new value. Obviously regular expression replacement is another option, though I'm more comfortable targetting using XPath. Does anybody else have better alternative suggestions, or know of plugins in existence or being developed to handle this? If it were to be developed, would it best belong in its own plugin, or would anybody support adding XPath replacement to the resources plugin to sit at the same level as basic filtering? Looking forward to any ideas or feedback. -- Stephen Duncan Jr www.stephenduncanjr.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Plugin package naming
Hi All, I am creating a plugin that I plan to eventually make available on ibiblio. In reading the instructions on creating an upload bundle (see http://maven.apache.org/maven-1.x/reference/repository-upload.html), I see that new projects must follow the package name rules and that the name must be a domain name I control. Unfortunately, I don't have a domain name and I don't want use my employer's domain name (and legally I probably can't anyway). Any guidelines on creating an acceptable name I can use? Thanks, Chuck
Re: Plugin package naming
Thanks Brett, that sounds reasonable regarding the naming. Thanks also for pointing me to mojo.codehaus.org, but this is an m1 plugin. It looks like that's only for m2 plugins. Regarding setting up the maven site docs on java.net, I noticed another posting on this list (although related to m2) about difficulties in putting the maven site docs on java.net because java.net expects to decorate all pages, conflicting with maven's expectation that the generated site pages are master pages. Any ideas on how to deal with that? On 1/9/06, Brett Porter [EMAIL PROTECTED] wrote: net.java.project-name seems appropriate. I am currently in discussions with some folks about creating a sync form the java.net maven repository (though its only for m1 at this point). - Brett On 1/10/06, Charles Daniels [EMAIL PROTECTED] wrote: Apache License 2.0, source will be available, documentation will be on java.net (currently planning to host the project there), planning to notify users on this mailing list when it is available. On 1/9/06, Brett Porter [EMAIL PROTECTED] wrote: How will the plugin be licensed? Is it intended to just be a binary distribution or will the source be available? Where will be the documentation be? How will people find out about it? I think your choice is probably influenced by these questions. One option, of course, is to propose it to mojo.codehaus.org if you want to and can share the code. HTH, Brett On 1/10/06, Charles Daniels [EMAIL PROTECTED] wrote: Hi All, I am creating a plugin that I plan to eventually make available on ibiblio. In reading the instructions on creating an upload bundle (see http://maven.apache.org/maven-1.x/reference/repository-upload.html), I see that new projects must follow the package name rules and that the name must be a domain name I control. Unfortunately, I don't have a domain name and I don't want use my employer's domain name (and legally I probably can't anyway). Any guidelines on creating an acceptable name I can use? Thanks, Chuck - 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: aspectj
Nothing is wrong with the build. You can ignore the message. Unfortunately, the message is an internal AspectJ message that cannot be avoided, at least not as far as I am aware. I suppose you could create a copy of aspecjtrt-1.2.jar in your maven local repository and name the copy aspectjrt.jar, then add jaraspectjrt.jar/jar to your aspectj dependency. Perhaps that would satisfy the internals of AspectJ so that is does not generate that annoying message. However, this approach is not exactly convenient since it would require all of your team members to do the same manual step of renaming the jar file in the repository. On 8/1/05, Torsten Curdt [EMAIL PROTECTED] wrote: Hm... I am currently trying to get aspectj properly working with maven. Maybe someone here has an idea what's going on. I've created a very simple project. A simple maven jar works just fine. Then I've added the dependency to the aspectj runtime dependency groupIdaspectj/groupId artifactIdaspectjrt/artifactId version1.2/version urlhttp://www.eclipse.org/aspectj/url properties war.bundletrue/war.bundle /properties /dependency and pointed maven to the aspects build sourceDirectorysrc/java/sourceDirectory aspectSourceDirectorysrc/aspect/aspectSourceDirectory /build In the maven.xml I've attached the aspectj goal to the java:compile goal project preGoal name=java:compile attainGoal name=aspectj:compile/ /preGoal /project When I call maven clean jar I get warning couldn't find aspectjrt.jar on classpath, checked: compiling [snip]/aop/App.java compiling [snip]/aop/logging/LogAspect.aj java:compile: aspectj:init: aspectj:compile: [iajc] Copied 1 empty directory to [snip]/target/classes Strangely enough the generated jar seems to include the aspects and does work :-/ ...but what's wrong with the build? cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: trying to have the hello plugin work...
If you follow the link http://www.ibiblio.org/maven2/org/apache/maven/maven-script-marmalade/, you will see that there is no subdirectory named 2.0-beta-1-SNAPSHOT, but there is one named 2.0-SNAPSHOT. Change the dependency version to match. On 7/17/05, ah2 sur communication-langages-et-systemes.com [EMAIL PROTECTED] wrote: Hello, I followed the hello plugin with marmalade instruction on page : http://maven.apache.org/maven2/developers/developing-plugins-with-marmal ade.html PLUS, the mailing list help : http://marc.theaimsgroup.com/?l=turbine-maven-user http://marc.theaimsgroup.com/?l=turbine-maven-userm=112066315327635w= 2 m=112066315327635w=2 so I suppressed the id tag, added a parameter... and added the dependencies given in this post : dependencies dependency groupIdorg.apache.maven/groupId artifactIdmaven-plugin-api/artifactId version2.0-beta-1-SNAPSHOT/version /dependency dependency groupIdmarmalade/groupId artifactIdmarmalade-core/artifactId version1.0-alpha-4/version /dependency dependency groupIdmarmalade/groupId artifactIdmarmalade-el-commons/artifactId version1.0-alpha-3/version /dependency dependency groupIdmarmalade/groupId artifactIdmarmalade-tags-io/artifactId version1.0-alpha-3/version /dependency dependency groupIdorg.apache.maven/groupId artifactIdmaven-script-marmalade/artifactId version2.0-beta-1-SNAPSHOT/version /dependency /dependencies that is when it still not works: When starting M2 -e hello:hello, the error seems to be : M2 cannot find the maven-script-marmalade-2.0-beta-1-SNAPSHOT.pom file in the repository of http://repo1.maven.org/maven2, http://repo1.maven.org/maven2/plugins see the stacktrace under... thanks for help... Antoine ... ... Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-script-marmalade/2. 0-beta-1-SNAPSHOT/maven-script-marmalade-2.0-beta-1-SNAPSHOT.pom [WARNING] Unable to get resource from repository http://repo1.maven.org/maven2 Downloading: http://repo1.maven.org/maven2/plugins/org/apache/maven/maven-script-marm alade/2.0-beta-1-SNAPSHOT/maven-scr ipt-marmalade-2.0-beta-1-SNAPSHOT.pom [WARNING] Unable to get resource from repository http://repo1.maven.org/maven2/plugins [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Diagnosis: Error configuring plugin for execution of 'hello:hello'. [INFO] [ERROR] Cause: org.apache.maven.plugin.MojoExecutionException: Error configuring plugin for execution of 'hello:hello'. at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginMa nager.java:378) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Default LifecycleExecutor.java:169) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoa l(DefaultLifecycleExecutor.java:150) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultL ifecycleExecutor.java:133) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifec ycleExecutor.java:103) at org.apache.maven.DefaultMaven.processProject(DefaultMaven.java:261) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:180) at org.apache.maven.cli.MavenCli.main(MavenCli.java:269) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:303) at org.codehaus.classworlds.Launcher.launch(Launcher.java:243) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:416) at org.codehaus.classworlds.Launcher.main(Launcher.java:363) Caused by: org.apache.maven.plugin.PluginConfigurationException: Cannot resolve plugin dependencies at org.apache.maven.plugin.DefaultPluginManager.ensurePluginContainerIsComp lete(DefaultPluginManager.java:608) at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPl uginManager.java:493) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginMa nager.java:373) ... 15 more Caused by: org.apache.maven.artifact.resolver.TransitiveArtifactResolutionException : Unable to read the metadata file org.apache.maven:maven-script-marmalade:2.0-beta-1-SNAPSHOT:jar from the specified remote repositories: http://repo1.maven.org/maven2, http://repo1.maven.org/maven2/plugins
Re: Unit testing verbosity
maven.junit.usefile=false On 7/15/05, Dan Bradley [EMAIL PROTECTED] wrote: I'm new to Maven, but can't find an resolution to this problem: unit tests don't run with enough verbosity to be useful. When I run unit tests that fail, there is nothing reported other than that the tests failed. For example: [junit] Running com.foo.FooTest [junit] Tests run: 4, Failures: 0, Errors: 4, Time elapsed: 1.875 sec [junit] [ERROR] TEST com.foo.FooTest FAILED If I want to see the reason the test failed I have to generate the site and then look at the HTML output, which takes a lot longer, but does provide the full reason for failure: Error creating bean with name 'com.foo.FooTest' defined in null: Unsatisfied dependency expressed through bean property 'fooManager': There are 2 beans of type [class com.foo.FooTest] for autowire by type. There should have been 1 to be able to autowire property 'productManager' of bean 'com.foo.FooTest'. Is there a way to get the failure reason on the command line? In a separate problem, when I run test:ui it appears to have a different classpath than when running test. Is there a way to make sure these are the same? When running the Swing test runner from Maven I get classpath-related errors in my unit tests that don't appear when I run the console tests. Thanks Dan Bradley [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: maven + cactus problem (Missing Cactus property [cactus.contextURL] but I have set cactus.contextURL in cactus.properties)
Add the following settings to your project.properties file: cactus.sysproperties=cactus.contextURL cactus.contextURL=http://localhost:8080/test On 5/31/05, sheep [EMAIL PROTECTED] wrote: hi. I have a problem when i do a servlet test anybody who can help me. //- maven+cactus do servlet test.but it always report miss cactus.contextURL.I put cactus.contextURL=http://localhost:8080/test in cactus.properties and System.setProperty(cactus.contextURL,http://localhost:8080/test); in Test***() method but it seem no work.what place should i placed this property. :( maybe i can put cactus.properties to other palce ? //-error message-- Testsuite: servlet.TestAdminServlet Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.801 sec Testcase: testGetCommandOK(servlet.TestAdminServlet): Caused an ERROR Missing Cactus property [cactus.contextURL] org.apache.cactus.util.ChainedRuntimeException: Missing Cactus property [cactus.contextURL] at org.apache.cactus.internal.configuration.BaseConfiguration.getContextURL(BaseConfiguration.java:59) at org.apache.cactus.internal.configuration.AbstractWebConfiguration.getRedirectorURL_aroundBody0(AbstractWebConfiguration.java:46) at org.apache.cactus.internal.configuration.AbstractWebConfiguration.getRedirectorURL_aroundBody1$advice(AbstractWebConfiguration.java:306) at org.apache.cactus.internal.configuration.AbstractWebConfiguration.getRedirectorURL(AbstractWebConfiguration.java) at org.apache.cactus.internal.client.connector.http.DefaultHttpClient.callRunTest(DefaultHttpClient.java:159) at org.apache.cactus.internal.client.connector.http.DefaultHttpClient.doTest_aroundBody0(DefaultHttpClient.java:80) at org.apache.cactus.internal.client.connector.http.DefaultHttpClient.doTest_aroundBody1$advice(DefaultHttpClient.java:306) at org.apache.cactus.internal.client.connector.http.DefaultHttpClient.doTest(DefaultHttpClient.java) at org.apache.cactus.internal.client.connector.http.HttpProtocolHandler.runWebTest(HttpProtocolHandler.java:159) at org.apache.cactus.internal.client.connector.http.HttpProtocolHandler.runTest_aroundBody0(HttpProtocolHandler.java:80) at org.apache.cactus.internal.client.connector.http.HttpProtocolHandler.runTest_aroundBody1$advice(HttpProtocolHandler.java:306) at org.apache.cactus.internal.client.connector.http.HttpProtocolHandler.runTest(HttpProtocolHandler.java) at org.apache.cactus.internal.client.ClientTestCaseCaller.runTest(ClientTestCaseCaller.java:144) at org.apache.cactus.internal.AbstractCactusTestCase.runBareClient(AbstractCactusTestCase.java:215) at org.apache.cactus.internal.AbstractCactusTestCase.runBare(AbstractCactusTestCase.java:133) // //-my work env dir:(eclipse + maven + cactus)- .classpath .project build.properties cactus.logging.config cactus.properties logging_client.properties logging_server.properties project.properties project.xml .settings org.eclipse.jdt.core.prefs bin .project src java servlet AdminServlet.class AdminServlet.java test-cactus servlet TestAdminServlet.class TestAdminServlet.java webapp lib aspectjrt-1.2.1.jar cactus-1.7.jar cactus-ant-1.7.jar cactus.properties commons-httpclient-2.0.2.jar commons-logging-1.0.4.jar httpunit-1.6.jar jasper-compiler-4.1.30.jar jasper-runtime-4.1.30.jar junit-3.8.1.jar nekohtml-0.9.1.jar org.mortbay.jetty-4.2.17.jar servletapi-2.3.jar WEB-INF cactus-web.xml web.xml target classes servlet AdminServlet.class servlet lib aspectjrt-1.2.1.jar cactus-1.7.jar cactus-ant-1.7.jar cactus.properties commons-httpclient-2.0.2.jar commons-logging-1.0.4.jar httpunit-1.6.jar jasper-compiler-4.1.30.jar jasper-runtime-4.1.30.jar junit-3.8.1.jar nekohtml-0.9.1.jar org.mortbay.jetty-4.2.17.jar servletapi-2.3.jar WEB-INF cactus-web.xml web.xml test-cactus-classes servlet TestAdminServlet.class test-cactus-reports resin2x test-classes servlet TestAdminServlet.class
Re: Building webapp help
Put those files under src/webapp/WEB-INF and the war goal will put them in the right place. On 5/24/05, Vinicius Carvalho [EMAIL PROTECTED] wrote: Hello. As I said in a past email (from a different account though :P) I'm starting with maven. And I'm migrating from ant, so I'm doing everthing in baby steps. Ok I got maven eclipse just fine, now I have maven war (which resolves my dependency problems, oops, I know maven is not only about that). I've set a preGoal to run the hibernate-doclet and webdoclet from ant and so far everthing is fine. In my src folder I have 4 files (3 xmls + txt) which I'd like to exclude from the WEB-INF/classes and instead move them to WEB-INF? How can one accomplish that? Thanks Vinicius - 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: [database] Where do I put my database Scripts.
And where would be a good place for the data itself? Specifically, I have files that contain some records that I want to import in order to create my initial, minimal data set required for my application to function. The records are similar to CSV files and can be imported by the import tool that I use. So, along with my sql scripts for creating my schema, I have data files that should be imported after the schema are created. Would the data files perhaps reside in src/main/data? For test data, perhaps in src/test/data? On 5/13/05, Thomas Van de Velde [EMAIL PROTECTED] wrote: http://www.codeczar.com/products/maven-sql-plugin/ uses src/sql and Google thinks chipoter means to haggle but I'd say to mess around Cheers, Thomas On 5/13/05, Vincent Massol [EMAIL PROTECTED] wrote: -Original Message- From: Laurent Forêt [mailto:[EMAIL PROTECTED] Sent: vendredi 13 mai 2005 17:53 To: Maven Users List Subject: Re: [database] Where do I put my database Scripts. Maybe I chipote (what's the translation for chipote), To quibble I think. but in the new convention (http://maven.apache.org/reference/conventions.html) it has been introduce the main folder. I don't understand exactly why for instance, but I am too much young maven user to have any judgement. You're right. I meant: src/main/database src/main/scripts scr/main/sql Unless there are DB scripts for testing in which casae they would go in src/test/database, etc. [snip] -Vincent - 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: Location of non-distributed resource files
Seems reasonable. So we could have src/conf/checkstyle, src/conf/xdoclet, src/conf/cactus, etc.? How can we have this approach (or any suggested alternatives) considered for inclusion in the Maven conventions/best practices? On 5/22/05, Jeff Jensen [EMAIL PROTECTED] wrote: Nice analysis. I have some further thoughts for you to consider on the build time resources, e.g. the conf dir location. For a given product, there are the source files and the build files. Every file falls into one or the other category (can anyone disprove that assertion? :-) Source files are those files that require manual creation vs generated from a tool (e.g. compiler, xdoclet, javadoc, etc.). Also, all source files belong under source control. Therefore, make the top two directories reflect this, e.g. src and target or src and build. Under the src dir, organize the source files. Since the config files in question (both runtime and build ones) are original vs generated, the config dir(s) belong in src. Also, keeping every source file under one dir makes source control tool interactions much cleaner/easier, keeping generated files completely separate. It gives confidence to clean. -Original Message- From: Charles Daniels [mailto:[EMAIL PROTECTED] Sent: Sunday, May 22, 2005 8:16 PM To: Maven Users List Subject: Re: Location of non-distributed resource files It looks like we have 2 types of resources: (a) those that are used during the build process, and (b) those that are used during runtime. Those that are used at runtime are further classified as either main or test resources. According to existing Maven conventions, it appears that the latter type (runtime) are organized within the src/main/resources and src/test/resources directories, for main and test resources, respectively. My original question refers to the former type of resources (buildtime) and there are some good suggestions for organizing them. I am leaning towards Jeff Jensen's most recent suggestion to use src/conf/tool, where tool may be the tool name, such as checkstyle or xdoclet. This goes along with Brett's original suggestion of using the tool or plugin name as the name of the subdirectory. At first glance, I preferred the use of src/main/xdoclet (as Brett suggested) over the use of src/conf/xdoclet (as Jeff suggested) since the src/conf directory has seem to have gone by the wayside. However, that may only be because the use of src/conf appears to never have been clearly defined. However, there is one problem I see with taking Brett's approach of using src/main/xdoclet. The problem is that buildtime testing resources should then be placed under src/test/plugin and this seems to cause at least one conflict that I can see. The particular case I have in mind here is the use of the cactus web.xml file that cactus uses to merge into a final web.xml file during the cactifywar task. According to convention (at least the convention I understand to exist and which I am following), sources for cactus tests should exist under src/test/cactus. If we also adhere to the convention implied by Brett's suggestion, my cactus-web.xml file should also exist under src/test/cactus. I would think we wouldn't want such a file at the root of our cactus test code. Rather, it would seem we might want to put cactus-web.xml under src/conf/cactus. Further, perhaps there is no need to separate main and test buildtime resources, since the use of the tool or plugin name provides the proper distinction. Since the resources are used only at buildtime, there is no need to keep parallel main and test structures. Taking this a step further, do we even need to keep such buildtime resources under the src directory? It seems to me that these resources warrant a new top-level directory, perhaps making conf top-level? If so, then we might want to consider conf/tool as the directory convention for buildtime resources. This might lead to directories, such as conf/checkstyle, conf/xdoclet, conf/cactus, etc. Thoughts? Cheers, Chuck On 5/21/05, Jeff Jensen [EMAIL PROTECTED] wrote: I have a typical structure of a src/conf/, with subdirectories containing the respective area/tool's files. E.g. src/conf/checkstyle. This provides for clear where are the config files, yet easy to select the ones for distribution. And also moving to a different location in the build as necessary. E.g. Struts wants resource bundles on the classpath. I consider xdocs not config info, but content. So src/xdoc. Also have a src/doc for documentation. This can include src/doc/javadoc for overview.html. Everything that is an original file for the product goes under the src dir. All of the src dir goes into source control. Everything else that is a generated file goes under the target dir at build time. Usually, project management files are not under src, but in their own projectdocs
Re: Location of non-distributed resource files
in the classpath : I use /src/resources/ojb, /src/resources/spring... to categorise them by nature. I like this way in M1 but I don't find how to do it in M2 (in fact I don't search) 4/ Resource to include in a specific dir : web resource like generate struts-config.xml, deployment files, .bat or .sh script to start an application... 5/ And of course tests resource that can be all the type before. I really think there is a need of convention here. In my case I use the /src/main/resources for the 1/ (not allways like for checkstyle), 2/, 3/,4/... I don't like it : the resources nature is too differant but I am probably to strict with directory layout of a project ;-) I'd like to have the other feelling about this... Nicolas On 5/21/05, Brett Porter [EMAIL PROTECTED] wrote: I do remember seeing it and forgetting to answer :) Personally, I would opt for src/main/xdoclet in this case (ie, src/main/plugin-name). Anyone else have any thoughts? I think this would be a good thing to include in the standards. - Brett On 5/21/05, Charles Daniels [EMAIL PROTECTED] wrote: Hi All, I thought I posted this question to the list a couple of days ago, but I haven't seen it appear anywhere, so I am resending. Please forgive me if this is a duplicate posting. I'm following the latest conventions for project layout and I am wondering if there is a convention for separating resources based on whether or not they are to be distributed/deployed. For example, if I understand the convention correctly, files such as properties files that are to be included in a jar file should reside under src/main/resources (perhaps with the appropriate package directory structure). However, what about other resources that are NOT to be included in the distribution. Are such resources also supposed to be placed under src/main/resources? For example, I am using the xdoclet plugin to generate my web.xml file. The plugin allows me to specify files to be merged into the resulting web.xml file. One example is servlets.xml, where I can specify third-party servlets to list in web.xml in addition to the servlets from my own code base. Obviously servlets.xml is used by the xdoclet plugin only for generating web.xml and servlets.xml will never be distributed. Therefore, would I still put servlets.xml somewhere under src/main/resources (perhaps under src/main/resources/xdoclet), or is there a better place for such resources? Thanks, Chuck - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Location of non-distributed resource files
Hi All, I thought I posted this question to the list a couple of days ago, but I haven't seen it appear anywhere, so I am resending. Please forgive me if this is a duplicate posting. I'm following the latest conventions for project layout and I am wondering if there is a convention for separating resources based on whether or not they are to be distributed/deployed. For example, if I understand the convention correctly, files such as properties files that are to be included in a jar file should reside under src/main/resources (perhaps with the appropriate package directory structure). However, what about other resources that are NOT to be included in the distribution. Are such resources also supposed to be placed under src/main/resources? For example, I am using the xdoclet plugin to generate my web.xml file. The plugin allows me to specify files to be merged into the resulting web.xml file. One example is servlets.xml, where I can specify third-party servlets to list in web.xml in addition to the servlets from my own code base. Obviously servlets.xml is used by the xdoclet plugin only for generating web.xml and servlets.xml will never be distributed. Therefore, would I still put servlets.xml somewhere under src/main/resources (perhaps under src/main/resources/xdoclet), or is there a better place for such resources? Thanks, Chuck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven Best Practices
Hi All, The Maven documentation is looking great! I have read the section on Best Practices (http://maven.apache.org/using/bestpractices.html) and have a question regarding generating deployments. One bullet point states the following: Avoid the need to filter resources. While this can be useful in a development environment, it usually requires rebuilding of an artifact between different phases of deployment. The best alternative is to externalise the configuration - for example in J2EE (where this is a common occurrence), make sure all configurable information such as database connection properties are in the deployment descriptor, provided through JNDI outside of the webapp or other deployable item. This means the particular artifact can be deployed identically into different servers, with just the external configuration differing. Can somebody elaborate on how to achieve this? I certainly would love to be able to do this, as this is one of the pain points I have on my projects. Currently we have separate properties files containing settings for our separate deployment environments. When we build our webapps for deployment, we specify the target environment so that we filter resources with the corresponding properties file. This ensures that the configuration files deployed with the application contain the settings appropriate for the target environment. How can we use the best practice quoted above to avoid this? What do others do to address this issue? Thanks, Chuck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Best Practices
Oops! I accidentally replied directly to Arnaud rather than the list. For completeness, here is the additional dialog with Arnaud. If anybody has further input, please don't hesitate to provide it. Thanks again Arnaud! By the way, what is SGBD? Thanks Arnaud! That appears to be right on topic, as far as I am concerned! Hope this help ;-) My additional question may be off topic though, which is, how can I achieve the same thing using WebLogic and WebSphere? I imagine that these app servers must support something similar to the Tomcat context files. Can anybody point me in the right direction? I didn't use weblogic or websphere since several months... I remember that in weblogic it was possible to define external resources (SGBD, ..) in the management console. I think that there are some other solutions (http://edocs.beasys.com/wls/docs61/ConsoleHelp/webservices_ddehelp.html) but I never tried them [As an aside, since your Tomcat context files are specific to each environment, do you maintain them under source control? If so, where do you keep them within your project structure?] Personally we store them in src/deployment/tomcat But we didn't yet create a mechanism to deliver them automatically to our team It's on our todo list .. Arnaud On 5/12/05, Arnaud HERITIER [EMAIL PROTECTED] wrote: Hi, This is a little bit off topic but ... We often deploy my web applications on tomcat. What we do is to define some deployment parameters on our web applications (web.xml) : Some parameters context-param param-nameenvironment/param-name param-valueDevelopment environment/param-value /context-param context-param param-namescriptInterpreter/param-name param-value/bin/sh/param-value /context-param ... A SGBD : resource-ref descriptionOracle Datasource/description res-ref-namejdbc/mySQBD/res-ref-name res-typejavax.sql.DataSource/res-type res-authContainer/res-auth /resource-ref We deliver the war to others team (tests, production, ...) and they define the own deployment settings in tomcat with a context file : Context path=/ourWebApp docBase=ourWebApp.war debug=0 Parameter name=environment value=Integration environment override=false/ Resource name=jdbc/mySGBD auth=Container type=javax.sql.DataSource/ ResourceParams name=jdbc/mySGBD parameter namefactory/name valueorg.apache.commons.dbcp.BasicDataSourceFactory/value /parameter parameter namedriverClassName/name valueoracle.jdbc.driver.OracleDriver/value /parameter parameter nameurl/name valuejdbc:oracle:thin:@localhost:1521:mySGBD/value /parameter parameter nameusername/name valuemyUser/value /parameter parameter namepassword/name valuemyPassword/value /parameter parameter namemaxActive/name value20/value /parameter parameter namemaxIdle/name value10/value /parameter parameter namemaxWait/name value-1/value /parameter parameter nameremoveAbandoned/name valuetrue/value /parameter parameter nameremoveAbandonedTimeout/name value60/value /parameter parameter namelogAbandoned/name valuetrue/value /parameter parameter namevalidationQuery/name valueSELECT 1 FROM DUAL/value /parameter /ResourceParams /Context We filter resources only to copy pom informations in our web application (the current release for example). Arnaud -Message d'origine- De : Charles Daniels [mailto:[EMAIL PROTECTED] Envoyé : vendredi 13 mai 2005 01:10 À : users@maven.apache.org Objet : Maven Best Practices Hi All, The Maven documentation is looking great! I have read the section on Best Practices (http://maven.apache.org/using/bestpractices.html) and have a question regarding generating deployments. One bullet point states the following: Avoid the need to filter resources. While this can be useful in a development environment, it usually requires rebuilding of an artifact between different phases of deployment. The best alternative is to externalise the configuration - for example in J2EE (where this is a common occurrence), make sure all configurable information such as database connection properties are in the deployment descriptor, provided through JNDI outside of the webapp or other deployable item. This means the particular artifact can be deployed identically into different servers, with just the external configuration differing. Can somebody elaborate on how to achieve this? I certainly would love to be able to do this, as this is one of the pain points I have on my projects. Currently we have separate properties files containing settings for our separate deployment environments. When
Re: [M1] Embedding maven genapp in my own plugin
Here is how I do it in my plugin.jelly:
goal name=myplugin:genapp
genapp:generate
maven.genapp.template.repository=${plugin.resources}/templates/
/goal
This allows me to do:
maven myplugin:genapp
When I specify a template, it will look for the directory under my
plugin's templates directory.
--- Laurent PETIT [EMAIL PROTECTED] wrote:
Hello,
I'm unsuccessfully trying to cleanly call maven genapp from my own
plugin.
My aim is to create a plugin that will hide my templates location from
the user, so all the user needs to do is do a plugin:download when new
versions of my plugin are available (my plugin will at the end contain
much more goals than a genapp wrapper).
For the moment, I managed to do that with the following tricks :
My goal in plugin.jelly looks like this :
ant:delete dir=${maven.home.local}/template/simple-webapp/
ant:copy todir=${maven.home.local}/template/simple-webapp
preservelastmodified=true
ant:fileset dir=${plugin.resources}/template/simple-webapp/
/ant:copy
attainGoal name=genapp/
And I've set this property in my plugins.properties file :
maven.genapp.template.repository=${maven.home.local}/template
This works, but what I want to do is address directly the
${plugin.resources}/template subdirectory of my
${maven.home.local}/cache/myOwnPlugin directory.
But I was unable to make it recognized !
I tried setting maven.genapp.template.repository to
${plugin.resources}/template in my plugin.properties file but it seems
that the setting of the property is done too late for the plugin. Very
weird, since the same property set with ${maven.home.local} works !
Any idea please ?
Thanks in advance,
--
Laurent Petit
-
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: Defining a dependency on the JDK's tools.jar?
-Original Message-
From: Vincent Massol [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 23, 2005 9:33 AM
To: 'Maven Users List'
Subject: RE: Defining a dependency on the JDK's tools.jar?
-Original Message-
From: Michael Schuerig [mailto:[EMAIL PROTECTED]
Sent: mercredi 23 février 2005 15:12
To: Maven Users List
Subject: Re: Defining a dependency on the JDK's tools.jar?
On Wednesday 23 February 2005 13:19, Vincent Massol wrote:
[snip]
This isn't exactly elegant. So, is there a better, cleaner way?
Yep, using the ${tools.jar} default Maven property. I
don't think you
really wish to download it so there's no need to define it as a
dependency. Having a JDK installed is meant to be a prereq.
That's probably the key to the solution, but I don't quite
see how to
use it, yet. I need to have tools.jar on the classpath as
I'm writing a
javadoc taglet. Also, I'm using Eclipse and create its
.classpath with
the maven eclipse plugin, which needs to add in tools.jar, too.
Ah I see... Several possible use cases:
- you are the one writing a custom plugin or some maven.xml
code. You can
use ${tools.jar} as you wish
- you are using an existing plugin and this plugin does not
offer an easy
way to add some custom classpath. You can use this maven.xml
scriptlet (but
then I'm not 100% sure if it's better than your solution...):
ant:path id=mycp
ant:pathelement location=${tools.jar}/
/ant:path
maven:addPath id=maven.dependency.classpath refid=mycp/
-Vincent
I missed the earlier part of this thread, so forgive me if I'm repeating
a solution identified earlier. My suggestion would be to add the
following properties to project.properties:
maven.jar.override=on
maven.jar.tools=${tools.jar}
Then add the following dependency to project.xml:
dependency
idtools/id
/dependency
Again, if this soloution was already mentioned, forgive me.
Cheers,
Chuck
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Xdoclet web module classpath
You cannot explicitly add the webdoclet dependency to the webdoclet
taskdef because the xdoclet plugin does not list the webdoclet
dependency in its project.xml file. As I said, you must add the
webdoclet dependency to your OWN project.xml which then becomes part of
maven.dependency.classpath. This will allow the webdoclet taskdef to
find what it needs.
If you want to explicitly add the webdoclet dependency to the webdoclet
taskdef, you must add the dependency to the plugin's project.xml.
However, I recommend against modifying your plugin when a workaround is
possible, as in this case. Updating the xdoclet plugin in this manner
should be posted as a JIRA issue (if that's appropriate for the xdoclet
plugin).
-Original Message-
From: Ravi Hegde [mailto:[EMAIL PROTECTED]
Sent: Friday, January 21, 2005 3:07 AM
To: Maven Users List
Subject: RE: Xdoclet web module classpath
Adding the web module dependency path in the webdoclet
taskdef's classpath does not help because maven throws
up at the taskdef level itself. If at all it is
possible to add the module jar to the classpath, it
should be before the taskdef. I tried a preGoal to
xdoclet:webdoclet and that also did not help. Any
other technique possible ?
Thanks for the help :)
--- Charles Daniels [EMAIL PROTECTED] wrote:
If you look at the webdoclet taskdef in the xdoclet
plugin's
plugin.jelly file, you will find the following:
taskdef name=webdoclet
classname=xdoclet.modules.web.WebDocletTask
classpath
path refid=maven.dependency.classpath/
pathelement
path=${plugin.getDependencyPath('xdoclet:xdoclet')}/
pathelement
path=${plugin.getDependencyPath('xdoclet:xjavadoc')}/
pathelement
path=${plugin.getDependencyPath('xdoclet:xdoclet-xdoclet-module')}/
pathelement
path=${plugin.getDependencyPath('commons-collections:commons-
collection
s')}/
pathelement
path=${plugin.getDependencyPath('commons-logging:commons-logg
ing')}/
pathelement
path=${plugin.getDependencyPath('log4j:log4j')}/
/classpath
/taskdef
Because of the way the classpath is formed, you must
include the
xdoclet-web-module dependency in your own
project.xml file because
maven.dependency.classpath includes only those
dependencies from your
project.xml, not any of the dependencies from the
plugin's project.xml.
Dependencies from the plugin are included (as you
can see above) by
using plugin.getDependencyPath(dependency). Notice
that there is no
explicit reference to the xdoclet:webdoclet
dependency, which is why you
must include it in your own project.xml. Seems odd
to me that the
xdoclet:webdoclet dependency is not explicit, which
would eliminate the
need for you to specify it in your own project.xml.
Oh well.
-Original Message-
From: Ravi Hegde [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 20, 2005 8:34 AM
To: users@maven.apache.org
Subject: Xdoclet web module classpath
I was using xdoclet:webdoclet goal by adding the
following dependency to my project.xml.
dependency
groupIdxdoclet/groupId
artifactIdxdoclet-web-module/artifactId
version1.2/version
urlhttp://xdoclet.sf.net//url
/dependency
To avoid adding this dependency to each of my
projects, I tried to add this dependency in the
project.xml of xdoclet plug-in. It is not working
- I
get the error
taskdef class xdoclet.modules.web.WebDocletTask
cannot
be found
But, printing the plugin dependency classpath
before
the xdoclet:webdoclet goal by using a preGoal as
shown
below prints xdoclet-web-module-1.2.jar with
proper
path.
preGoal name=xdoclet:webdoclet
echo message=*** Dependency classpath =
${plugin.getDependencyClasspath()}/
/preGoal
Does that mean xdoclet-web-module-1.2.jar is in
plug-in's classpath and still the taskdef does not
find it ? Any clue(s) will be of great help.
__
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail
SpamGuard.
http://promotions.yahoo.com/new_mail
-
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]
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED
RE: Newbee
Same as it is in Ant: ${basedir}
-Original Message-
From: VALLA Samuel [mailto:[EMAIL PROTECTED]
Sent: Friday, January 21, 2005 10:04 AM
To: Maven Users List; Dion Gillard
Subject: RE: Newbee
Thankx, an other question !!!
I want to get the root directory where the project.xml is execute...
-Message d'origine-
De : Dion Gillard [mailto:[EMAIL PROTECTED]
Envoyé : vendredi, 21. janvier 2005 15:59
À : Maven Users List
Objet : Re: Newbee
j:if test=${ (a == 2) or (b == 3)}
|| also works
On Fri, 21 Jan 2005 14:48:30 +0100, VALLA Samuel
[EMAIL PROTECTED] wrote:
I want to execute a u:if test= with a OR in test ?
Have you an example ???
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
http://www.multitask.com.au/people/dion/
-
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: Xdoclet web module classpath
If you look at the webdoclet taskdef in the xdoclet plugin's
plugin.jelly file, you will find the following:
taskdef name=webdoclet classname=xdoclet.modules.web.WebDocletTask
classpath
path refid=maven.dependency.classpath/
pathelement path=${plugin.getDependencyPath('xdoclet:xdoclet')}/
pathelement
path=${plugin.getDependencyPath('xdoclet:xjavadoc')}/
pathelement
path=${plugin.getDependencyPath('xdoclet:xdoclet-xdoclet-module')}/
pathelement
path=${plugin.getDependencyPath('commons-collections:commons-collection
s')}/
pathelement
path=${plugin.getDependencyPath('commons-logging:commons-logging')}/
pathelement path=${plugin.getDependencyPath('log4j:log4j')}/
/classpath
/taskdef
Because of the way the classpath is formed, you must include the
xdoclet-web-module dependency in your own project.xml file because
maven.dependency.classpath includes only those dependencies from your
project.xml, not any of the dependencies from the plugin's project.xml.
Dependencies from the plugin are included (as you can see above) by
using plugin.getDependencyPath(dependency). Notice that there is no
explicit reference to the xdoclet:webdoclet dependency, which is why you
must include it in your own project.xml. Seems odd to me that the
xdoclet:webdoclet dependency is not explicit, which would eliminate the
need for you to specify it in your own project.xml. Oh well.
-Original Message-
From: Ravi Hegde [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 20, 2005 8:34 AM
To: users@maven.apache.org
Subject: Xdoclet web module classpath
I was using xdoclet:webdoclet goal by adding the
following dependency to my project.xml.
dependency
groupIdxdoclet/groupId
artifactIdxdoclet-web-module/artifactId
version1.2/version
urlhttp://xdoclet.sf.net//url
/dependency
To avoid adding this dependency to each of my
projects, I tried to add this dependency in the
project.xml of xdoclet plug-in. It is not working - I
get the error
taskdef class xdoclet.modules.web.WebDocletTask cannot
be found
But, printing the plugin dependency classpath before
the xdoclet:webdoclet goal by using a preGoal as shown
below prints xdoclet-web-module-1.2.jar with proper
path.
preGoal name=xdoclet:webdoclet
echo message=*** Dependency classpath =
${plugin.getDependencyClasspath()}/
/preGoal
Does that mean xdoclet-web-module-1.2.jar is in
plug-in's classpath and still the taskdef does not
find it ? Any clue(s) will be of great help.
__
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail
-
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: Taskdef problem
Your WebTesterTask probably requires additional dependencies that are missing from your project.xml. The error message is probably misleading in that it is not WebTesterTask that it cannot find, but some dependency that cannot be found. I suggest you run maven with the -e option so you can see the stack trace. When you look at the stack trace, it will probably indicate the actual class that cannot be found, which should point you to the correct dependency that you must add to project.xml. This may happen more than once. As you add a dependency, you may still get the same exception because there may be yet another dependency that is missing, so you may have to repeat this process until all dependencies are discovered. -Original Message- From: KLOPP Gerald [mailto:[EMAIL PROTECTED] Sent: Monday, January 17, 2005 9:55 AM To: users@maven.apache.org Subject: Taskdef problem Hello, I'd like to use the slimdog ant task in my maven.xml file. To do so : 1- I define a custom ant task in this way : taskdef name=webtest classname=org.jzonic.webtester.tasks.WebTesterTask classpathref=maven.dependency.classpath / 2- I add the dependency in my project.xml in this way : dependency groupIdslimdog/groupId artifactIdwebtester/artifactId jarwebtester.jar/jar url/url properties war.bundlefalse/war.bundle /properties /dependency When I run maven, I get the following exception : BUILD FAILED File.. /dvl/RG99_FS1/app/websdidv/jboss/maven/app/europarl/maven.xml Element... taskdef Line.. 62 Column 126 taskdef class org.jzonic.webtester.tasks.WebTesterTask cannot be found Looking the log file, The webtester jar file is added to the dependency classpath and the jar contains the org.jzonic.webtester.tasks.WebTesterTask class. Do you have any idea? Thanks, Gerald - 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: Maven not reading project.properties for Clover
For jar overrides, use the artifactId, not the groupId. In your case, you want to set the property maven.jar.clover-ant, not maven.jar.clover. -Original Message- From: Brian Wainwright [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 21, 2004 9:21 AM To: [EMAIL PROTECTED] Subject: Maven not reading project.properties for Clover Hello, I've just upgraded to version 1.6 of the clover plugin and am trying to override the plugin jar with my own licensed clover jar file (version 1.3.3). Unfortunately, no matter what I do, it appears that Maven isn't reading the properties I've set for the Clover plugin in project.properties: #CLOVER PLUGIN FOR MAVEN maven.clover.instrument.tests=true maven.clover.report.html=true maven.jar.override=on maven.jar.clover=/usr/local/clover/lib/clover.jar maven.clover.license.path= It insists on using the 1.3_01 version - even to the extent that it will go out and download it if I remove it from the repository and replace it with my licensed version. Here's the output I get when I run maven clover:on cactus or maven clean clover:on cactus... java:compile: [echo] Compiling to /Users/bwain/Documents/Vulcan/Projects/cvs/scape/target/clover/classes [javac] Compiling 354 source files to /Users/bwain/Documents/Vulcan/Projects/cvs/scape/target/clover/classes [javac] Clover Version 1.3_01, built on July 09 2004 [javac] loaded from: /Users/bwain/.maven/repository/clover/jars/clover-ant-1.3_01.jar [javac] [ERROR] No license file found. I'm using Maven version 1.0 on Mac OS X with Java version 1.4.2. Thanks for any suggestions. I'm kind of at a loss as to how to proceed as it appears to be an issue with the plugin and not with Clover. --Brian = Brian R. Wainwright Senior Developer Information Technology and Telecommunications WGBH Educational Foundation ph/fax:617.300.3450 e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Can anyone help with linkage Error
Try using xml-apis-1.0.b2.jar instead of xmlParserAPIs. If you look at the note at the bottom of http://www.ibiblio.org/maven/xml-apis/jars/, you will see that the use of xmlParserAPIs is not recommended. I don't know if this will correct the problem you are seeing, but it's worth a shot. -Original Message- From: Hal Arnold [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 07, 2004 10:35 PM To: [EMAIL PROTECTED] Subject: Can anyone help with linkage Error Hi, I've looked at all the Maven help lists I can find for the following problem, which I see others have had. I am trying to get Spring with Hibernate up in our environment using Maven. Works fine with Ant. My problem is with the test goal (I'm simply wrapping test:test at this point). I get the linkage error: Testcase: warning(junit.framework.TestSuite$1): FAILED Exception in constructor: testGetCustomer (java.lang.LinkageError: loader constraints violated when linking org/w3c/dom/Node class at org.springframework.beans.factory.xml.DefaultXmlBeanDefinition Parser.reg isterBeanDefinitions(DefaultXmlBeanDefinitionParser.java:176) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader. registerBe anDefinitions(XmlBeanDefinitionReader.java:170) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader. loadBeanDe finitions(XmlBeanDefinitionReader.java:129) at org.springframework.context.support.AbstractXmlApplicationCont ext.loadBe anDefinitions(AbstractXmlApplicationContext.java:144) and lots of others.. I'm assuming from reading other folks notes on this same issue, that I have a problem with the classloader, probably with an incompatibility with one of the xml jars. Several folks have suggested that the maven.junit.fork be set to true which I have done. The following is the dependency list (dare I assume that it comes out in some loading order?): [echo] is fork on: true [echo] ... [echo] depends on servletapi [echo] depends on regexp [echo] depends on oro [echo] depends on log4j [echo] depends on struts [echo] depends on db-ojb [echo] depends on commons-collections [echo] depends on commons-pool [echo] depends on commons-beanutils [echo] depends on commons-digester [echo] depends on commons-fileupload [echo] depends on commons-validator [echo] depends on commons-dbcp [echo] depends on commons-lang [echo] depends on commons-logging [echo] depends on jfreechart [echo] depends on ftpbean [echo] depends on ldap [echo] depends on flux [echo] depends on activation [echo] depends on mail [echo] depends on rowset [echo] depends on CocoDeploy [echo] depends on xalan [echo] depends on xercesImpl [echo] depends on xmlParserAPIs [echo] depends on Verisign [echo] depends on boldfish [echo] depends on asp [echo] depends on lucene [echo] depends on standard [echo] depends on jstl [echo] depends on saxpath [echo] depends on oscache [echo] depends on resin (I tried turning this off, as it's commonly a problem..no help tho) [echo] depends on xstream [echo] depends on spring [echo] depends on spring-orm [echo] depends on spring-aop [echo] depends on aopalliance [echo] depends on spring-mock [echo] depends on hibernate [echo] depends on dbunit [echo] depends on junit [echo] depends on jmock [echo] depends on jwebunit [echo] depends on module-platform (jar with only a simple interface, nothing dangerour here..) Can anyone suggest some help? I guess I could simply 'wrap' the ant task that works.. thanks, hba - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Trying to create developer group plugin
I recall setting typeplugin/type on a dependency was broken. It didn't actually cause the plugin to be installed properly. Has this been fixed? -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 08, 2004 3:34 PM To: Maven Users List Subject: Re: Trying to create developer group plugin Using a dependency with typeplugin/type will do this automatically. Or your users can manually use plugin:download and it will be available to all projects for them. Either way, when you publish it to the repository make sure you use plugin:repository-deploy, not jar:deploy as it must be in the /plugins/ directory. These are the only two ways I recommend doing it. Cheers, Brett - 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: Trying to create developer group plugin
Excellent! By the way, fantastic work on Maven. I am a die-hard fan! -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 08, 2004 3:56 PM To: Charles Daniels Cc: Maven Users List Subject: Re: Trying to create developer group plugin In Maven 1.0.1 (and hence 1.0.2) all known issues with this have been fixed. If you find another one, let us know! - Brett On Wed, 8 Dec 2004 15:39:58 -0700, Charles Daniels [EMAIL PROTECTED] wrote: I recall setting typeplugin/type on a dependency was broken. It didn't actually cause the plugin to be installed properly. Has this been fixed? -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 08, 2004 3:34 PM To: Maven Users List Subject: Re: Trying to create developer group plugin Using a dependency with typeplugin/type will do this automatically. Or your users can manually use plugin:download and it will be available to all projects for them. Either way, when you publish it to the repository make sure you use plugin:repository-deploy, not jar:deploy as it must be in the /plugins/ directory. These are the only two ways I recommend doing it. Cheers, Brett - 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: 1.0.2 startup slow
Same here. Unpacking plugin jars every time. Startup time for me is consistently 16 seconds. -Original Message- From: Joe Shomphe [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 07, 2004 10:40 AM To: Maven Users List Subject: Re: 1.0.2 startup slow Yeah, I am seeing the same thing here. Every time maven runs, it seems to be unpacking its jars to my local repo every time. I have tried removing my ~/.maven directory, but that didnt seem to work. Output from maven -X: Unpacking maven-announcement-plugin-1.3.jar to directory -- C:\Documents and Settings\joes\.maven\cache\maven-announcement-plugin-1.3 Invalidating plugin maven-announcement-plugin-1.3 removing dynataglib cache entry for uri announcement removing goal and plugin cache entry for goal announcement:generate removing goal and plugin cache entry for goal announcement:generate-all removing goal and plugin cache entry for goal announcement:mail removing goal and plugin cache entry for goal announcement:init removing goal and plugin cache entry for goal announcement:check-version removing goal and plugin cache entry for goal announcement removing dynatag dependency cache entry removing artifactId cache entry On Tue, 7 Dec 2004 10:28:23 -0700, Chad Brandon [EMAIL PROTECTED] wrote: Hi, First of all, great job on the 1.0.2 release! I just download the release this morning and have been using it, and I've noticed the startup time has dramatically increased. Startup time for just typing maven was between 2-3 seconds on my machine for versions prior to 1.0.2, but 1.0.2 seems to take around 25 seconds just to start up. Has anyone else noticed this? And is there anything I can do to improve the time? I know about the maven console plugin however I change directories a lot so it's not a great alternative unless I just stay in the same directory the entire time. Thanks! Chad - 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]
Aspectj IMessageHolder ignored by Maven
Hi All, Unfortunately, the AspectJ plugin for Maven does not support specification of an IMessageHolder implementation via the messageHolderClass attribute of the iajc Ant task. Therefore, I have added a goal to my maven.xml file that calls the iajc Ant task with the attribute, specifying my custom IMessageHolder implementation. Here is what it looks like: goal name=weave prereqs=java:compile taskdef resource=org/aspectj/tools/ant/taskdefs/aspectjTaskdefs.properties classpath refid=maven.dependency.classpath/ /taskdef iajc messageHolderClass=com.mypackage.MyMessageHolder classpathRef=maven.dependency.classpath debug=true deprecation=true destdir=target/woven-classes failonerror=false sourceroots pathelement location=src/java/ pathelement location=src/aspects/ /sourceroots /iajc /goal The problem is that MyMessageHolder is never used by the iajc task. Even if I change the class name to some class that does not exist, I never get a ClassNotFoundException. However, if I create an Ant target containing this identical task, MyMessageHolder *is* used, and if I specify a non-existent class, I get a ClassNotFoundException. Any ideas on why I am seeing behavior in Maven that is different from Ant for an identically configured task? Cheers, Chuck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: is maven.xdoc.distributionUrl working?
-Original Message- From: Michael Niemaz [mailto:[EMAIL PROTECTED] Sent: Thursday, November 25, 2004 4:47 AM To: Maven Users List Subject: is maven.xdoc.distributionUrl working? Hi, No matter what I affect to maven.xdoc.distributionUrl, the download page is always empty. It only gets something when I play with versions but then it only links to jar files ;-( Do you know how to generate this download page which would list the files contained in maven.xdoc.distributionUrl for download? In fact, I would like to produce exactly what's on the maven download page. Automatically of course ;-) That is precisely how things are supposed to work with maven.xdoc.distributionUrl. If you want to produce a download page similar to the Maven download page, then you must create your own download.xml file. This is exactly what is done in the Maven project itself. See the Maven CVS repository (xdocs/start/download.xml): http://cvs.apache.org/viewcvs.cgi/maven/xdocs/start/. Thanx, --mike Gezerk wrote: Set this property: maven.xdoc.distributionUrl From the site: Location where the artifacts are distributed. This property is optional. If it is not defined, then the Download report will not be added to the navigation menu. NOTE: In the future this information will be described in the POM. Usage example: maven.xdoc.distributionUrl=http://www.ibiblio.org/maven/maven /plugins. Info here: http://maven.apache.org/reference/plugins/xdoc/properties.html On Fri, 19 Nov 2004 13:23:26 +0200 (EET), Teemu Hiltunen [EMAIL PROTECTED] wrote: Greetings! Is there any automagical thing to create this Downloads page into the site? Like http://maven.apache.org/reference/plugins/dist/downloads.html for example. Thanks in advance, Teemu Hiltunen - 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 not run XDoclet
Looks like you do not have the maven xdoclet plugin installed. Notice that there is no Loading plugin 'maven-xdoclet-plugin-1.2.1' message in your output. The xdoclet plugin is not part of the maven installation. You must download it separately. The xdoclet repository is here: http://xdoclet.sourceforge.net/repository. -Original Message- From: Janos Mucsi [mailto:[EMAIL PROTECTED] Sent: Thursday, November 11, 2004 6:16 PM To: Maven Users List; Pascal Thivent Subject: can not run XDoclet Hi Pascal I appreciate your reply! I upgraded to Maven 1.0.1 and here is the trace: C:\temp\eclipse\PlutoApp\modules\everest-module-registrationmaven -X ejb:instal l __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.1 Initializing Plugins! Set plugin source directory to C:\maven-1.0.1\plugins Set unpacked plugin directory to C:\Documents and Settings\jmucsi\.maven\cache Set user plugin directory to C:\Documents and Settings\jmucsi\.maven\plugins Loading plugin cache Now mapping cached plugins Loading plugin 'maven-cruisecontrol-plugin-1.5' Loading plugin 'maven-multichanges-plugin-1.1' Loading plugin 'maven-checkstyle-plugin-2.5' Loading plugin 'maven-file-activity-plugin-1.5.1' Loading plugin 'maven-jellydoc-plugin-1.3.1' Loading plugin 'maven-jdepend-plugin-1.5' Loading plugin 'maven-ear-plugin-1.5' Loading plugin 'maven-pom-plugin-1.4.1' Loading plugin 'maven-jira-plugin-1.1.2' Loading plugin 'maven-jar-plugin-1.6.1' Loading plugin 'maven-developer-activity-plugin-1.5.1' Loading plugin 'maven-jboss-plugin-1.5' Loading plugin 'maven-faq-plugin-1.4' Loading plugin 'maven-dist-plugin-1.6.1' Loading plugin 'maven-javadoc-plugin-1.7' Loading plugin 'maven-linkcheck-plugin-1.3.3' Loading plugin 'maven-tasklist-plugin-2.3' Loading plugin 'maven-idea-plugin-1.5' Loading plugin 'maven-jcoverage-plugin-1.0.9' Loading plugin 'maven-junit-report-plugin-1.5' Loading plugin 'maven-plugin-plugin-1.5.2' Loading plugin 'maven-changelog-plugin-1.7.1' Loading plugin 'maven-jxr-plugin-1.4.2' Loading plugin 'maven-ashkelon-plugin-1.2' Loading plugin 'maven-announcement-plugin-1.3' Loading plugin 'maven-xdoc-plugin-1.8' Loading plugin 'maven-eclipse-plugin-1.9' Loading plugin 'maven-shell-plugin-1.1' Loading plugin 'maven-rar-plugin-1.0' Loading plugin 'maven-scm-plugin-1.4.1' Loading plugin 'maven-clover-plugin-1.6' Loading plugin 'maven-dashboard-plugin-1.5' Loading plugin 'maven-uberjar-plugin-1.2' Loading plugin 'maven-war-plugin-1.6.1' Loading plugin 'maven-simian-plugin-1.4' Loading plugin 'maven-ant-plugin-1.8.1' Loading plugin 'maven-ejb-plugin-1.5' Loading plugin 'maven-tjdo-plugin-1.0.0' Loading plugin 'maven-changes-plugin-1.5.1' Loading plugin 'maven-j2ee-plugin-1.5.1' Loading plugin 'maven-release-plugin-1.4.1' Loading plugin 'maven-abbot-plugin-1.1' Loading plugin 'maven-multiproject-plugin-1.3.1' Loading plugin 'maven-nsis-plugin-1.1' Loading plugin 'maven-license-plugin-1.2' Loading plugin 'maven-jdiff-plugin-1.4' Loading plugin 'maven-pmd-plugin-1.6' Loading plugin 'maven-repository-plugin-1.2' Loading plugin 'maven-jbuilder-plugin-1.5' Loading plugin 'maven-console-plugin-1.1' Loading plugin 'maven-webserver-plugin-2.0' Loading plugin 'maven-aspectwerkz-plugin-1.2' Loading plugin 'maven-test-plugin-1.6.2' Loading plugin 'maven-jetty-plugin-1.1' Loading plugin 'maven-docbook-plugin-1.2' Loading plugin 'maven-latka-plugin-1.4.1' Loading plugin 'maven-aspectj-plugin-3.2' Loading plugin 'maven-hibernate-plugin-1.2' Loading plugin 'maven-native-plugin-1.1' Loading plugin 'maven-site-plugin-1.5.2' Loading plugin 'maven-gump-plugin-1.4' Loading plugin 'maven-appserver-plugin-2.0' Loading plugin 'maven-java-plugin-1.4' Loading plugin 'maven-pdf-plugin-2.2.1' Loading plugin 'maven-html2xdoc-plugin-1.3.1' Loading plugin 'maven-jdee-plugin-1.1' Loading plugin 'maven-jalopy-plugin-1.3.1' Loading plugin 'maven-jnlp-plugin-1.4.1' Loading plugin 'maven-jdeveloper-plugin-1.4' Loading plugin 'maven-junit-doclet-plugin-1.2' Loading plugin 'maven-wizard-plugin-1.1' Loading plugin 'maven-artifact-plugin-1.4.1' Loading plugin 'maven-javacc-plugin-1.1' Loading plugin 'maven-antlr-plugin-1.2.1' Loading plugin 'maven-struts-plugin-1.3' Loading plugin 'maven-clean-plugin-1.3' Loading plugin 'maven-castor-plugin-1.2' Loading plugin 'maven-latex-plugin-1.4.1' Loading plugin 'maven-genapp-plugin-2.2' Loading plugin 'maven-caller-plugin-1.1' Loading plugin 'maven-vdoclet-plugin-1.2' Now loading uncached plugins Finished initializing Plugins! Using userBuildPropertiesFile: C:\Documents and Settings\jmucsi\build.properties Using projectPropertiesFile: C:\temp\eclipse\PlutoApp\modules\everest-module-reg istration\project.properties Using projectBuildPropertiesFile: C:\temp\eclipse\PlutoApp\modules\everest-modul e-registration\build.properties Using
RE: can not run XDoclet
That's not how you install a plugin. To manually install a plugin, place the plugin jar file in MAVEN_HOME/plugins. When you run maven, it will take care of expanding jar files from MAVEN_HOME/plugins into the .maven/cache directory. -Original Message- From: Janos Mucsi [mailto:[EMAIL PROTECTED] Sent: Thursday, November 11, 2004 6:55 PM To: Maven Users List Subject: can not run XDoclet Thanks, but how does Maven recognize a new plugin? After I created a directory called C:\Documents and Settings\jmucsi\.maven\cache\maven-xdoclet-plugin-1.2.1 I unzipped the 3 files (plugin.jelly, plugin.properties, project.xml) into it from maven-xdoclet-plugin-1.2.1.jar, the same thing happened. I do not see Loading plugin 'maven-xdoclet-plugin-1.2.1' Why? == Looks like you do not have the maven xdoclet plugin installed. Notice that there is no Loading plugin 'maven-xdoclet-plugin-1.2.1' message in your output. The xdoclet plugin is not part of the maven installation. You must download it separately. The xdoclet repository is here: http://xdoclet.sourceforge.net/repository. __ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Local dependencies
The url element of a dependency does not tell Maven where to obtain
the dependency. It is merely used in the error message when Maven
cannot locate the dependency in the local repository nor in any remote
repository. It is supposed to indicate where you should be able
manually download the dependency, as indicated in your output:
jxip.jar (try downloading from /home/popol/gkls/xip/lib/)
What you need to do is add the following to your project.properties:
maven.jar.override=on
maven.jar.jxip=${basedir}/xip/lib/jxip.jar
Your dependency can be reduced to the following:
dependency
groupIdjxip/groupId
artifactIdjxip/artifactId
/dependency
-Original Message-
From: Michael Niemaz [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 09, 2004 7:15 AM
To: Maven Users List
Subject: Re: Local dependencies
Recall the local dependency, I tried what you suggested and It did
not work:
Attempting to download jxip.jar.
WARNING: Failed to download jxip.jar.
The build cannot continue because of the following unsatisfied
dependency:
jxip.jar (try downloading from /home/popol/gkls/xip/lib/)
Total time: 1 seconds
Finished at: Tue Nov 09 15:11:14 CET 2004
Although the jar file jxip.jar is indeed located under
/home/popol/gkls/xip/lib/
;-(
Here's my project's dependencies declaration:
dependency
groupIdjxip/groupId
artifactIdjxip/artifactId
version/version
url${basedir}/xip/lib//url
jarjxip.jar/jar
/dependency
I even tried to put the jar fullpath in the jar element ...
Any ideas?
thx,
--mike
Brett Porter wrote:
The download report is based on the versions element in the
project.xml file, I believe.
On Tue, 09 Nov 2004 12:19:19 +0100, Michael Niemaz
[EMAIL PROTECTED] wrote:
Thanx a lot!
Also, I kind of have difficulties to deploy my stuff with the
download html link being updated. All it says is that there
is nothing
to download. Any idea? bug?
--mike
Bulent Erdemir wrote:
check out the jar tag in the dependency element. There you can
specify a jar file name. Also check out the maven.jar.override
directive.
On Tue, 09 Nov 2004 11:54:36 +0100, Michael Niemaz
[EMAIL PROTECTED] wrote:
Hi,
Is it possible to specify a local dependency instead
of a remote one?
The reason is that some resources that my project is
using are, for
the moment,
not to be acceesible by anyone from outside ... but
i'd still want
to use maven
to ease the ditribution process of my project.
I looked at the dependencies element but couldn't
figure out how
to specify a
local path.
Any idea?
Thanx,
--mike
--
---
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]
.
-
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: javac: target release 1.1 conflicts with default source release 1.5
-Original Message- From: Christopher L Merrill [mailto:[EMAIL PROTECTED] Sent: Friday, November 05, 2004 11:46 AM To: Maven Users List Subject: Re: javac: target release 1.1 conflicts with default source release 1.5 Feilpe Vieira Silva wrote: how can I fix that problem? I edited the maven-java-plugin-1.4.jar file... Open the the plugin.properties file and change the value of the maven.compile.target property to 1.5. Maybe this isn't the 'best' way to fix it, but it worked for me. It's definitely not the best way to fix it. You can override default values for plugin properties by adding the property to your project's project.properties file. -- -- --- Chris Merrill | http://www.webperformanceinc.com Web Performance Inc. | http://www.webperformancemonitoring.net Website Load Testing, Stress Testing, and Performance Monitoring Software -- --- - 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: javac: target release 1.1 conflicts with default source release 1.5
If you specify a value for maven.compile.memoryInitialSize, you must also specify a value for maven.compile.memoryMaximumSize, which must be at least as large as maven.compile.memoryInitialSize. -Original Message- From: Feilpe Vieira Silva [mailto:[EMAIL PROTECTED] Sent: Friday, November 05, 2004 2:23 PM To: Maven Users List Subject: Re: javac: target release 1.1 conflicts with default source release 1.5 almost there... I´m having problems with my build.properties values: maven.compile.memoryInitialSize 128M maven.compile.fork yes maven.compile.optimize yes maven.compile.target 1.5 java:compile: [echo] Compiling to C:\cvsRepository\schoolbus\schoolbus-quaestio/target/cla sses [javac] Compiling 1 source file to C:\cvsRepository\schoolbus\schoolbus-quae stio\target\classes [javac] Error occurred during initialization of VM [javac] Incompatible initial and maximum heap sizes specified =- HERE On Fri, 05 Nov 2004 15:27:24 -0500, Erik Husby [EMAIL PROTECTED] wrote: Feilpe Vieira Silva wrote: another issue: I´m trying to follow the great article at http://www-106.ibm.com/developerworks/java/library/j-maven/ this article suggested me to create a project tree such as: schoolbus | +- schoolbus-core +- schoolbus-quaestio and then to create a project file for each sub-project with the extends tag What you should do is schoolbus +-- core +-- quaestio +-- deployable application In schoolbus/project.xml -- no dependencies, just common information in core/project.xml -- extend schoolbus/project.xml in quaestio/project.xml -- extend schoolbus/project.xml, depend on core.jar in deployable application -- extend schoolbus/project.xml, depend on core.jar, quaestio.jar then you can do from schoolbus maven multiproject:install to build all installable artifacts in the correct order. -- Erik Husby Team Lead for Software Quality Automation Broad Institute of MIT and Harvard Rm. 2192 320 Charles St Cambridge, MA 02141-2023 mobile: 781.354.6669, office: 617.258.9227, [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: context root is missing from application.xml
The correct property name is ear.appxml.war.context-root
-Original Message-
From: Janos Mucsi [mailto:[EMAIL PROTECTED]
Sent: Friday, November 05, 2004 4:59 PM
To: Maven Users List
Subject: context root is missing from application.xml
Hi
in project.xml I have this:
dependency
groupIdeverest/groupId
artifactIdeverest-module-csrweb/artifactId
version${pom.currentVersion}/version
typewar/type
properties
ear.bundletrue/ear.bundle
ear.appxml.ear.context-root/foobar-online/ear.appxml.ear.co
ntext-root
/properties
However, after running maven ear application.xml
looks like this:
module
web
web-urieverest-module-csrweb-1.0.war/web-uri
context-root
/context-root
/web
/module
Any ideas? (I am using Maven 1.0 not 1.0.1)
Thanks.
Janos
__
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: maven test:test
Try adding these within build:
sourceDirectory${maven.src.dir}/sourceDirectory
unitTestSourceDirectory${maven.src.dir}/unitTestSourceDirectory
Notice that /com is not specified.
-Original Message-
From: Ben Anderson [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 03, 2004 5:24 AM
To: [EMAIL PROTECTED]
Subject: maven test:test
Hi,
I have this in my project.xml
build
sourceDirectory${maven.src.dir}/com/sourceDirectory
resources
resource
directory${maven.src.dir}/directory
includes
include*.xml/include
include*.dtd/include
/includes
/resource
/resources
unitTest
includes
include${maven.src.dir}/**/*Test*.java/include
/includes
excludes
exclude${maven.src.dir}/**/TestAll.java/exclude
exclude${maven.src.dir}/**/*Abstract*.java/exclude
/excludes
/unitTest
/build
my maven.src.dir I define elsewhere, but that's beside the point. I
have a Test file right along side the rest of my src code. When I do
java:compile, it gets compiled. But when I do test:test I get no
tests to run. I tried taking out the ${maven.src.dir} inside the
unitTest tags, but that didn't help. Any ideas what I'm doing
wrong?
Thanks,
Ben
-
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: Need help with upgrading a plugin
This is a known issue. Adding a plugin as a dependency doesn't quite work as you might expect. In fact, in my experience, adding a plugin as a dependency can cause other little problems. I suggest you remove the plugin as a dependency and manually download the plugin via the plugin:download goal. You should probably also manually delete the plugin jar files from your MAVEN_HOME/plugins directory prior to running plugin:download. If you simply stick to using plugin:download whenever you wish to upgrade to a newer plugin version, your older version will automatically be removed. -Original Message- From: Helck, Christopher [mailto:[EMAIL PROTECTED] Sent: Thursday, October 28, 2004 9:27 AM To: Maven Users List Subject: Need help with upgrading a plugin Note: This is a repost/rephrasing of an ealier question I sent out. Previous posts have led me to believe that I can upgrade a plugin by specifying the plugin in my POM. I've tried this and it partially works. The new plugin is downloaded and installed in my local repository, but Maven does not invoke the updated plugin. In this case I'm trying to use the latest version of the JXR plugin. Here's the relevent parts of my POM: dependencies dependency groupIdmaven/groupId artifactIdmaven-jxr-plugin/artifactId version1.4.2/version typeplugin/type /dependency ... /dependencies reports reportmaven-jxr-plugin/report ... /reports When I run maven site and it tries to build the java cross reference I get the error: BUILD FAILED File /home/chelck/.maven/cache/maven-jxr-plugin-1.4.1/plugin.jelly Version 1.4.2 of jxr is downloaded and in my cache next to 1.4.1. So why isn't 1.4.2 being used? Any ideas? Thanks, -c. helck The information contained in this e-mail is confidential. This e-mail is intended only for the stated addressee. If you are not an addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. if you have received this e-mail in error, please inform us immediately and delete it and all copies from your system. EBS Dealing Resources International Limited. Registered address: 55-56 Lincoln's Inn Fields, London WC2A 3LJ, United Kingdom. Registered number 2669861. EBS Dealing Resources, Inc, registered in Delaware. Address: 535 Madison Avenue, 24th Floor, New York, NY 10022, USA, and One upper Pond road, Building F - Floor 3, Parsippany, NJ 07054, USA. EBS Dealing Resources Japan Limited, a Japanese Corporation. Address: Asteer Kayabacho Bldg, 6th Floor, 1-6-1, Shinkawa, Chuo-Ku, Tokyo 104-0033, Japan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: sharing maven goals between projects?
Write your own Maven plugin :-) See http://maven.apache.org/reference/developers/developer-guide.html -Original Message- From: phillip rhodes [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 19, 2004 1:36 PM To: [EMAIL PROTECTED] Subject: sharing maven goals between projects? I am using maven for several of my projects. However, I am starting to copy large blocks of text that are similar between all my maven.xml files that are scattered around. I am hoping that I could centralize this goals into a central file and call out to them from my various maven projects. What is the easiest way to call out to another maven.xml file or declare some sort of inheritance? Thanks. Phillip - 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: hello anyone there
Be patient. We all have jobs (I think) and do this voluntarily. You may have to wait a day or so for an answer to your question. Don't expect an immediate reply. -Original Message- From: project member [mailto:[EMAIL PROTECTED] Sent: Thursday, October 14, 2004 8:53 AM To: [EMAIL PROTECTED] Subject: hello anyone there hello , but i am feeling very lonely out here. i have been sending mails for past 3 hrs almost i think and i didnt recieve a single reply. u.. i actually adds to my frustration. anyway , what do i say more . - Yahoo! Messenger - Communicate instantly...Ping your friends today! Download Messenger Now - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How do I test a schema
You may also want to check out XMLUnit (http://xmlunit.sourceforge.net). However, according to the docs, I think it may only support validation against a DTD, not a Schema. -Original Message- From: Ben Anderson [mailto:[EMAIL PROTECTED] Sent: Thursday, September 23, 2004 7:29 AM To: Maven Users List Subject: Re: How do I test a schema That's funny - I was trying to do this yesterday, but gave up. You'll need the validate plugin jar here: http://jakarta.apache.org/commons/jelly/libs/validate/index.html I'm not sure where you're supposed to stick these jars. I put it in $MAVEN_HOME/lib and that worked, but it's probably supposed to go somewhere else. There's also some documentation there, but no examples. Here's what I had thus far: goal name=validate !--we need to create a new java.io.File u:new ... v:verifier var=mySchema file=.../ v:validate var=isValid verifier=mySchema some xml - possibly importing a file somehow. /v:validate -- /goal of course this doesn't work. Maybe together we can figure it out. -Ben Quoting Helck, Christopher [EMAIL PROTECTED]: I'd like to automate testing a XML schema under maven, but I don't have a clue how to begin :-). I have a schema and some example XML files. I'd like to validate the files against the schema. Any help is appreciated. Thanks, C. Helck The information contained in this e-mail is confidential. This e-mail is intended only for the stated addressee. If you are not an addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. if you have received this e-mail in error, please inform us immediately and delete it and all copies from your system. EBS Dealing Resources International Limited. Registered address: 55-56 Lincoln's Inn Fields, London WC2A 3LJ, United Kingdom. Registered number 2633663. EBS Dealing Resources, Inc, registered in Delaware. Address: 535 Madison Avenue, 24th Floor, New York, NY 10022, USA, and One upper Pond road, Building F - Floor 3, Parsippany, NJ 07054, USA. EBS Dealing Resources Japan Limited, a Japanese Corporation. Address: Asteer Kayabacho Bldg, 6th Floor, 1-6-1, Shinkawa, Chuo-Ku, Tokyo 104-0033, Japan. - 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: Maven/Junit: printing test failure/error stack trace to stdout
This is documented under the test plugin (see http://maven.apache.org/reference/plugins/test/properties.html). Unfortunately, it is not documented under the junit-report plugin (other than what the default value is). -Original Message- From: Helck, Christopher [mailto:[EMAIL PROTECTED] Sent: Thursday, September 23, 2004 11:40 AM To: Maven Users List Subject: RE: Maven/Junit: printing test failure/error stack trace to stdout I think it is 'maven.junit.usefile' and not 'junit.usefile'. When I try it maven -Dmaven.junit.usefile=false test Works fine. Perhaps this should be put in the FAQ? I'd been wondering about this same problem for a while. Thanks. -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 22, 2004 4:38 PM To: Maven Users List Subject: Re: Maven/Junit: printing test failure/error stack trace to stdout try this: maven -Djunit.usefile=false test:test or put the following line in your project.properties file: junit.usefile=false HTH, john Omair-Inam Abdul-Matin wrote: Is it possible to print out the stack trace for tests that fail or raise an error. I would like more details that a failure/error count. Omair - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The information contained in this e-mail is confidential. This e-mail is intended only for the stated addressee. If you are not an addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. if you have received this e-mail in error, please inform us immediately and delete it and all copies from your system. EBS Dealing Resources International Limited. Registered address: 55-56 Lincoln's Inn Fields, London WC2A 3LJ, United Kingdom. Registered number 2633663. EBS Dealing Resources, Inc, registered in Delaware. Address: 535 Madison Avenue, 24th Floor, New York, NY 10022, USA, and One upper Pond road, Building F - Floor 3, Parsippany, NJ 07054, USA. EBS Dealing Resources Japan Limited, a Japanese Corporation. Address: Asteer Kayabacho Bldg, 6th Floor, 1-6-1, Shinkawa, Chuo-Ku, Tokyo 104-0033, Japan. - 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: No supported regular expression matcher found
Hi Brett, Yes, it's a regexp that Ant is looking for. I'm using the regexp mapper in a copy task. Thank you for the answer! I was not placing the classloader element within a properties element. Doing so fixed the problem. Out of curiosity, how will this be handled in the future since doing this is a deprecated technique (I think)? Thanks again, Chuck -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Thursday, September 23, 2004 7:08 PM To: Maven Users List Subject: Re: No supported regular expression matcher found is that one of the JARs that provides a regexp to Ant? When you added the classloader, was it inside a properties/ element? On Thu, 23 Sep 2004 12:55:57 -0400, Charles Daniels [EMAIL PROTECTED] wrote: Anybody have any suggestions on this? -Original Message- From: Charles Daniels [mailto:[EMAIL PROTECTED] Sent: Friday, September 17, 2004 8:35 AM To: Maven Users List Subject: No supported regular expression matcher found Hi All, I am trying to use the regexp matcher within the ant:copy task, but get the message No supported regular expression matcher found. I have tried adding the following dependency to my dependencies list: dependency groupIdregexp/groupId artifactIdregexp/artifactId version1.3/version /dependency However, this doesn't help. I've also tried it with classloaderroot/classloader, but that doesn't work either. I searched the archives, but couldn't find any postings regarding this issue. Does anybody know how to get the regexp mapper to see the regexp library using JDK 1.3? (Note: If I use JDK 1.4, there's no problem. However, I need this to work with JDK 1.3). Thanks, Chuck - 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: how to deploy file to repository without filename modified?
If you want to avoid having to change all of your taglib descriptors in your
JSPs when you decide to use a newer version of a tag library, you should use
logical URIs and create tag library mappings in your web.xml deployment
descriptor. For example, use a taglib descriptor of the following form:
%@ taglib prefix=mytags uri=http://www.company.com/taglibs/mytags;
%
The URL specified as the value of the URI does not have to exist. It's
simply a logical namespace used to distinguish tag libraries. Then place
the following in your web.xml:
taglib
taglib-urihttp://www.company.com/taglibs/mytags/taglib-uri
taglib-location/WEB-INF/tld/mytags-1.0.tld/taglib-location
/taglib
Now when you want to upgrade to a new version of the taglib, simply change
the entry in web.xml and redeploy. This allows you to see which version of
a tag library your application uses, without having to specify version
numbers within your JSPs.
Cheers,
Chuck
-Original Message-
From: Pak, Young-rok [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 22, 2004 7:40 AM
To: Maven Users List
Subject: Re: how to deploy file to repository without filename modified?
I want to deploy some tld files(JSP Tag Library Descriptor) to
repository and use that as dependencies in other project. for
example, the project 'mytag' produces mytag.tld and mytag.jar,
and other web project myweb uses both file. I want to deploy both
files using jar:deploy with some postGoal definition in maven.xml.
Why the name of tld files should not be changed is that their
file name will be used in JSP page like this:
%@ taglib uri=/WEB-INF/tlds/mytag.tld prefix=mytag %
mytag-1.0.tld seems not good name for tld file. and the name
should not change even if it versions up.
- Original Message -
From: Brett Porter [EMAIL PROTECTED]
To: Maven Users List [EMAIL PROTECTED]
Sent: Wednesday, September 22, 2004 8:20 PM
Subject: Re: how to deploy file to repository without filename modified?
This is intentionally not supported. Artifacts need versions in the
repository, especially with new features coming in Maven.
What problems will this cause you?
- Brett
On Wed, 22 Sep 2004 20:10:17 +0900, Pak, Young-rok
[EMAIL PROTECTED] wrote:
I want to deploy some files to repository without modifying
filename when deploying jar. for example, there is file to deploy
in my project like this:
src/tld/mytag.tld
and, I want to deploy to my repository like this:
mygroup/tlds/mytag.tld
so, I tried to use maven.xml like this:
postGoal name=jar:deploy
artifact:deploy artifact=src/tld/mytag.tld type=tld
project=${pom}/
/postGoal
but, failed. mytag.tld copied to:
mygroup/tlds/myproject-1.0.tld
this is not what I wanted. and found no other way. how can I
do that? if there is no way to do that, I think artifact plugin
must be extended to support that.
-
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: navigation.xml documentation
navigation.xml goes in your xdocs directory. See http://maven.apache.org/reference/plugins/xdoc/faq.html for details on what you can put in it. -Original Message- From: Kris Nuttycombe [mailto:[EMAIL PROTECTED] Sent: Friday, September 03, 2004 4:23 PM To: Maven Users List Subject: navigation.xml documentation Hi, all, Where can I find documentation about how to configure the navigation.xml file? I've found references to such a beast numerous places on the web, and there are some references to it on the Maven wiki but nowhere can I find information about where to actually place the navigation.xml file in the project hierarchy or what the schema of the XML file is! Can someone point me in the right direction? Thanks, Kris -- = Kris Nuttycombe Associate Scientist Geospatial Data Services Group CIRES, National Geophysical Data Center/NOAA (303) 497-6337 [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: default value for maven.scm.checkout.dir
The reason maven.scm.checkout.dir does not point to ${basedir} is so that
you can perform a clean build even if you have locally modified files. That
is, by setting maven.scm.checkout.dir to ${maven.build.dir}/checkouts, you
are able to checkout everything from your scm without getting things dirty
with your local changes. Otherwise, you would have to make sure you have
committed all of your changes in advance, which is not always desirable.
You may be in the middle of making changes that you are not ready to commit.
-Original Message-
From: Marcin Gurbisz [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 31, 2004 9:39 AM
To: Maven Users List
Subject: default value for maven.scm.checkout.dir
What is the reason for default value for property:
maven.scm.checkout.dir=${maven.build.dir}/checkouts
Please, give some example scenario.
More udnerstandable for me would be value ${basedir}
Thanks for help,
Marcin Gurbisz
-
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: plug-in directories
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 19, 2004 6:36 AM
To: Maven Users List
Subject: Re: plug-in directories
you can still put manually downloaded plugins into
{user.home}/.maven/plugins for them to persist across installations
That's good, but what about plugins that are downloaded using the
plugin:download goal? These get put into MAVEN_HOME/plugins, not
${user.home}/.maven/plugins, which means that they don't persist across
maven installations. Should this be a Jira issue?
On Wed, 18 Aug 2004 21:49:23 -0700, Andreas Guther
[EMAIL PROTECTED] wrote:
If I put manually downloaded plugin jars into
MAVEN_HOME/plugins than I have
to remember to copy them to the next installation, assuming that one is
not making
a newer installation over an older one, don't I?
Wouldn't it better to have a plugins directory external to the versioned
MAVEN_HOME/plugins?
I think that the previous solution was less dependent on the actual
installation of MAVEN.
Andreas
Charles Daniels wrote:
-Original Message-
From: Andreas Guther [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 18, 2004 1:05 PM
To: Maven Users List
Subject: plug-in directories
.
2. When I manually download a plug-in jar file, where do I have to put
it that maven picks it up? In previous
versions it was recommended to put the plug-in jar file in the
{user.home}/.maven/plugins folder. If this folder
is not used anymore,where should I put such manual downloads?
Place manually downloaded plugin jars into MAVEN_HOME/plugins.
-
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: Jars from the same repository location
Not that I'm aware of. You have to explicitly list each jar dependency. -Original Message- From: jeff mutonho [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 18, 2004 12:15 PM To: Maven Users List Subject: Jars from the same repository location Hi I'm trying to build a project that uses a lot of IBM jars and these jars are all in one directory.Is there a way of telling Maven to look in that folder for all the required jars , without having to do the following for the required jars : dependency groupIdibm/groupId artifactIdj2ee/artifactId version1.0/version jarj2ee.jar/jar groupIdibm/groupId artifactIdras/artifactId version1.0/version jarras.jar/jar /dependency jeff mutonho - Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: plug-in directories
-Original Message-
From: Andreas Guther [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 18, 2004 1:05 PM
To: Maven Users List
Subject: plug-in directories
Can anyone explain which directories of a maven installation are
used by the
plug-in management? I have a few general questions:
1. I believe that in older maven version (1.0) maven was storing
plug-ins in the {user.home}/.maven/plugins
folder. Is this folder still needed or could I delete it?
You can delete it. Plugins are now exploded into the
${user.home}/.maven/cache directory.
2. When I manually download a plug-in jar file, where do I have to put
it that maven picks it up? In previous
versions it was recommended to put the plug-in jar file in the
{user.home}/.maven/plugins folder. If this folder
is not used anymore,where should I put such manual downloads?
Place manually downloaded plugin jars into MAVEN_HOME/plugins.
Thanks in advance,
Andreas
-
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: disabling project documentation
I don't think that's quite what Nathan is looking for. Nathan see the last paragraph here: http://maven.apache.org/reference/user-guide.html Simply set maven.xdoc.includeProjectDocumentation=no -Original Message- From: Norbert Pabis' [mailto:[EMAIL PROTECTED] Sent: Monday, August 16, 2004 11:54 AM To: Maven Users List Subject: Re: disabling project documentation Deregister all reports. postGoal name=xdoc:register-reports attainGoal name=maven-xxx-plugin:deregister/ /postGoal Nathan Coast wrote: Hi, When executing the 'site' goal, is there any way to prevent the generation of the Project Documentation menu and related reports? I tried adding goal name=xdoc:register-reports/ to maven.xml and reports/ to project.xml but the reports are still generated. thanks Nathan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Norbert Pabis - 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: CVS Connection to CVSNT
-Original Message- From: Böhringer Jochen [mailto:[EMAIL PROTECTED] Sent: Thursday, August 12, 2004 5:57 PM To: [EMAIL PROTECTED] Subject: CVS Connection to CVSNT Hi, I try to connect to a CVSNT (Windows 2003 Server) to generate the changelogs during site:generate. The Connection string ist: scm:cvs:pserver:[EMAIL PROTECTED]:D:/cvsrepo/MavenTests:MavenTestWeb Every time I try to do so I get the following Exception indicating that something is wrong with the connection string. I think the : after the drive letter D is the problem. But I need it because the CVS is hosted on a Windows Server. Is there another syntax to use? Yes, there is. Use another character as your delimiter. For example, use a pipe (|) instead of a colon (:) to seperate the parts of the connection string. See http://maven.apache.org/reference/project-descriptor.html#repository. Alternatively, I highly recommend that you use a Repository Prefix option provided by CVSNT so that you can eliminate the need for supplying the drive letter in the path. For example, this is my setup: D:\cvs - root of all CVS stuff D:\cvs\cvsnt - CVSNT installation directory D:\cvs\cvsrepo - my CVSROOT D:\cvs\cvstemp - temp directory for CVSNT Using this structure, take the following steps, using the CVSNT control panel application: 0. Stop the CVSNT service, if it's running. 1. On the Repositories tab, check the Repository Prefix checkbox. 2. Click the browse button (the button with the 3 dots on it). 3. Choose the D:/cvs folder and click OK. 4. Click the Add button. 5. Enter D:/cvs/cvsrepo and click OK. 6. Click the Advanced tab. 7. Click the browse button (3 dots) next to Temporary Directory. 8. Select D:/cvs/cvstemp and click OK. 9. Click Apply and restart the CVSNT service on the Service Status tab. Now you can use /cvsrepo for your cvsroot path in the connection string (no need for including the D:/cvs/ prefix). Note that although you obviously don't have to use the structure I used, your cvsroot must NOT be a top-level directory on your hard drive. That is, to use the Repository Prefix feature of CVSNT you cannot use something like D:/cvsrepo as your cvsroot. It must be at least one directory deeper, as in my example. BUILD FAILED File.. D:\MavenHome\cache\maven-changelog-plugin-1.7.1\plugin.jelly Element... changelog:changelog Line.. 83 Column 15 cvs repository connection string doesn't contain six tokens Total time: 53 seconds Finished at: Thu Aug 12 18:58:33 CEST 2004 Thanks for your help. Jochen - 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: CVS Connection to CVSNT
-Original Message- From: Böhringer Jochen [mailto:[EMAIL PROTECTED] Sent: Thursday, August 12, 2004 7:33 PM To: Maven Users List Subject: RE: CVS Connection to CVSNT Alternatively, I highly recommend that you use a Repository Prefix option provided by CVSNT so that you can eliminate the need for supplying the drive letter in the path. Thanks for your recommendation. The problem is that I use Eclipse. If I turn on the Repository Prefix function in CVSNT Eclipse warns me, that it will turn off its extended functionalities because of problems in the Repository Prefix implementation of CVSNT:-( Not sure what you're doing, but I use Eclipse and have no such problems using a Repository Prefix. Jochen - 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: Use of maven.test.skip
-Original Message- From: Jeffrey D. Brekke [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 10, 2004 8:37 PM To: Maven Users List Subject: Re: Use of maven.test.skip I recommend you forget that the flag exists and make the tests faster. That doesn't necessarily help. If all of his tests take 0.1 second on average, but he has 1000 tests, it still takes 100 seconds to run them all, which may still be unacceptably long to wait when running frequently. On Tue, 10 Aug 2004 13:49:06 +0100, Kenny MacLeod [EMAIL PROTECTED] said: Folks, I currently have a project where the unit tests take a considerable amount of time to run (5 minutes or so), and as a result, running them every time I do a build is proving impractical. Initially, I just added the maven.test.skip flag to my project.properties, but this isn't a good solution, mainly because if I explicitly want to run the unit tests, I have to take the flag out again. What I want is for the unit tests not to be run when i do a build, but I do want them to run if I explicitly say so. The interactions between the Java and Test plugins don't seem to be flexible enough to allow this. My current solution is to move the unit tests out to a seperate project, but that seems like an arse-backwards way of going about it. Can anyone suggest a better approach? I think you may be onto something here. If they are so long, maybe they aren't unit tests and should be moved. -- = Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [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: developing doclets with maven (revised)
My suggestion would be your second solution. Then each developer need only
define the property tools.jar in his/her build.properties file. Although,
you may want to consider using a version number in the property name (e.g.,
tools14.jar) just in case a developer also wants to point to version 1.3 for
some other project. This way they can have two distinct properties that
they can put in ~/build.properties.
-Original Message-
From: Shinobu Kawai [mailto:[EMAIL PROTECTED]
Sent: Monday, August 09, 2004 6:45 AM
To: Maven Users List
Subject: developing doclets with maven (revised)
Hi!
I'm looking for a good way to develop doclets using maven. During
compilation, I need the Javadoc API, but I'm probably going to give up
putting the Javadoc 1.4 API in ibiblio.
cf.
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]
he.orgmsgNo=22207
Now I'm looking for alternatives. Right now, I can think of two
solutions:
1. Make the jar myself (or use tools.jar) and put it in the local
repository or a private remote repository. Of course, I need tell
other developers that their repositories have to be manually added.
2. Use the maven.jar.override property and point the dependency to such
a jar file. I can expect this to work anywhere as long as maven is
running under the right version of java.
maven.jar.override = on
maven.jar.javadoc = ${tools.jar}
Any suggestions? or other alternatives?
Best regards,
-- Shinobu Kawai
--
Shinobu Kawai [EMAIL PROTECTED], [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: Plugin taglibs
--- Nigel Magnay [EMAIL PROTECTED] wrote: Hello I have a plugin where I have declared a taglib by doing define:taglib uri=myuri define:tag name=yadayada etc etc I can do plugin:install fine However, when I try and use it in my script, with project xmlns:mine=myuri ... goal. ... mine:yadayada / I get Tag library requested that is not present: 'myuri' in plugin 'null' I'm evidently missing something here.. how do I 'register' my plugin? I've examined the other plugins in the cache and I can't figure it out... If you have installed your plugin at least once prior to adding your taglib, it may be a cache issue. I have noticed similar behavior when defining a new goal in a plugin that I have already installed. To resolve this, first run plugin:uninstall to clear your plugin from the cache, then run plugin:install again. Your taglib should then be recognized. Cheers, Nigel - 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: [ANN] Maven FindBugs Plugin 0.8.2 released
How about posting the errors you are getting? -Original Message- From: Colin Chalmers [mailto:[EMAIL PROTECTED] Sent: Monday, August 02, 2004 6:22 PM To: Maven Users List Subject: Re: [ANN] Maven FindBugs Plugin 0.8.2 released Hi, I am interested in adding this to our reports but couldn't quite get it to work. I tried adding it to the reports section of my project.xml but I got an error. Then I tried to run it by hand and got the message that it wasn't registered :-( Any ideas what's going wrong? Colin Jerome Lacoste wrote: On Sat, 2004-07-31 at 13:48 +0200, Eric Pugh wrote: I have updated the docs at http://maven-plugins.sourceforge.net/maven-findbugs-plugin/index.html to include the findbugs report that is used while testing the plugin itself. This will give you a feeling for what the report looks like... Just a note for anyone who will be searching the report in the Project Reports section. It's not there but located in the Overview / sample report. Jerome - 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: Maven Eclipse Plugin Question/Feature Request?
See the documentation for the plugin:
http://maven.apache.org/reference/plugins/eclipse/properties.html
The section below the table of properties describes exactly how to add
dependencies from another project.
-Original Message-
From: Joe Shomphe [mailto:[EMAIL PROTECTED]
Sent: Monday, August 02, 2004 6:00 PM
To: Maven Users List
Subject: Maven Eclipse Plugin Question/Feature Request?
In eclipse 3.0, there are various types of classpath entries. For
example, If I want to include a classes directory from another eclipse
project in my workspace, I can right click on my project and choose
Add Class Folder from the java build path. This adds an entry in
the projects .classpath referencing classpathentry kind=lib
When I run the eclipse plugin on my project, specifying the same
classes folder in maven.eclipse.classpath.include, The folder will
appear as an eclipse dependency, but with kind=src.
I popped open classpath.jelly and see that the kind=src is hardcoded:
!-- add extra directories to be included in the classpath --
j:forEach var=res items=${maven.eclipse.classpath.include.split}
classpathentry kind=src path=${res}/
/j:forEach
Is there any way to generate a classpath entry of kind=lib?
Thanks
-
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: List all dependencies or only main ones?
Stijn, You must explicitly include B and C dependencies in project D's project.xml. As mentioned earlier in this thread, Maven 2 will support what is called transitive dependencies, meaning that in the future, you will not have to explicitly specify these implicit dependencies. However, for now, you must explicitly specify them. -- Chuck -Original Message- From: Stijn de Witt [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 03, 2004 11:57 AM To: Maven Users List Subject: Re: List all dependencies or only main ones? Hi Reddy, Let me show it with an example Project a is a maven project, using two jars, B-1.0.jar and C-1.0.jar. Projects B and C are plain jars Project D is a maven project, using 1 jar, A.1.0.jar. A: project.xml .. dependencies dependency groupIdB/groupdId artifactIdB/artifactId version1.0/version properties / /dependency dependency groupIdC/groupdId artifactIdC/artifactId version1.0/version properties / /dependency /dependencies .. D: project.xml .. dependencies dependency groupIdA/groupdId artifactIdA/artifactId version1.0/version properties / /dependency /dependencies .. The final program (D) will need all 4 jars to run, but does that mean that I have to add the dependencies from project A to D, or will maven be able to determine from project A's pom that it has to include B-1.0.jar and C-1.0.jar to? ...why don't you try using remote repository call them in project A (project.xml) instead of calling in each and every project. This sounds like an interesting possibility, could you explain some further? Thanks, -Stijn - Original Message - From: Reddy MVS [EMAIL PROTECTED] To: 'Maven Users List' [EMAIL PROTECTED] Sent: Tuesday, August 03, 2004 12:37 PM Subject: RE: List all dependencies or only main ones? Hi Stijn, I am not sure. Let me do some research let you know the status, why don't you try using remote repository call them in project A (project.xml) instead of calling in each and every project. The compilation needs all the dependencies in local repository. I think it doesn't worry about weather you call all the dependencies in Project A or Project B if it's depending on other project. If you run alone you need to call dependencies for respective Library files (.jar). Also what do you mean by main ones? Thanks Reddy MVS -Original Message- From: Stijn de Witt [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 03, 2004 3:40 PM To: Maven Users List Subject: List all dependencies or only main ones? Hi, A quick question. Assume a project A, which depends on projects B and C. If project D depends on A, does it also have to state it's (implicit) dependencies on B and C in project.xml? TIA, -Stijn - 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: [ANN] Maven FindBugs Plugin 0.8.2 released
Colin Chalmers wrote: I tried adding it to the reports section of my project.xml but I got an error I assumed this meant that you got an error message ;-) Anyway, which version of the jvm are you using to run FindBugs when you get java.lang.UnsupportedClassVersionError? -Original Message- From: Colin Chalmers [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 03, 2004 5:08 PM To: Maven Users List Subject: Re: [ANN] Maven FindBugs Plugin 0.8.2 released Hey Chuck, Well initially I didn't get any message except that it wasn't registered, otherwise I would have posted it ;-) Today that problem seems to be resolved, now I get the following error message [echo] Running the FindBugs task... [findbugs] Running FindBugs... [findbugs] java.lang.UnsupportedClassVersionError: edu/umd/cs/findbugs/FindB ugs (Unsupported major.minor version 48.0) [findbugs] at java.lang.ClassLoader.defineClass0(Native Method) [findbugs] at java.lang.ClassLoader.defineClass(ClassLoader.java:488) [findbugs] at java.security.SecureClassLoader.defineClass(SecureClassLoader .java:106) [findbugs] at java.net.URLClassLoader.defineClass(URLClassLoader.java:243) [findbugs] at java.net.URLClassLoader.access$100(URLClassLoader.java:51) [findbugs] at java.net.URLClassLoader$1.run(URLClassLoader.java:190) [findbugs] at java.security.AccessController.doPrivileged(Native Method) [findbugs] at java.net.URLClassLoader.findClass(URLClassLoader.java:183) [findbugs] at java.lang.ClassLoader.loadClass(ClassLoader.java:294) [findbugs] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:281) [findbugs] at java.lang.ClassLoader.loadClass(ClassLoader.java:250) [findbugs] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:310) Colin Charles Daniels wrote: How about posting the errors you are getting? -Original Message- From: Colin Chalmers [mailto:[EMAIL PROTECTED] Sent: Monday, August 02, 2004 6:22 PM To: Maven Users List Subject: Re: [ANN] Maven FindBugs Plugin 0.8.2 released Hi, I am interested in adding this to our reports but couldn't quite get it to work. I tried adding it to the reports section of my project.xml but I got an error. Then I tried to run it by hand and got the message that it wasn't registered :-( Any ideas what's going wrong? Colin Jerome Lacoste wrote: On Sat, 2004-07-31 at 13:48 +0200, Eric Pugh wrote: I have updated the docs at http://maven-plugins.sourceforge.net/maven-findbugs-plugin/ind ex.html to include the findbugs report that is used while testing the plugin itself. This will give you a feeling for what the report looks like... Just a note for anyone who will be searching the report in the Project Reports section. It's not there but located in the Overview / sample report. Jerome - 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: [ANN] Maven FindBugs Plugin 0.8.2 released
FindBugs requires 1.4.0 or later (see http://findbugs.sourceforge.net/). -Original Message- From: Colin Chalmers [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 03, 2004 6:45 PM To: Maven Users List Subject: Re: [ANN] Maven FindBugs Plugin 0.8.2 released JVM = 1.3.1_08 Didn't see any notes pertaining to a specific version of JVM that had to be used. /c Charles Daniels wrote: Colin Chalmers wrote: I tried adding it to the reports section of my project.xml but I got an error I assumed this meant that you got an error message ;-) Anyway, which version of the jvm are you using to run FindBugs when you get java.lang.UnsupportedClassVersionError? -Original Message- From: Colin Chalmers [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 03, 2004 5:08 PM To: Maven Users List Subject: Re: [ANN] Maven FindBugs Plugin 0.8.2 released Hey Chuck, Well initially I didn't get any message except that it wasn't registered, otherwise I would have posted it ;-) Today that problem seems to be resolved, now I get the following error message [echo] Running the FindBugs task... [findbugs] Running FindBugs... [findbugs] java.lang.UnsupportedClassVersionError: edu/umd/cs/findbugs/FindB ugs (Unsupported major.minor version 48.0) [findbugs] at java.lang.ClassLoader.defineClass0(Native Method) [findbugs] at java.lang.ClassLoader.defineClass(ClassLoader.java:488) [findbugs] at java.security.SecureClassLoader.defineClass(SecureClassLoader .java:106) [findbugs] at java.net.URLClassLoader.defineClass(URLClassLoader.java:243) [findbugs] at java.net.URLClassLoader.access$100(URLClassLoader.java:51) [findbugs] at java.net.URLClassLoader$1.run(URLClassLoader.java:190) [findbugs] at java.security.AccessController.doPrivileged(Native Method) [findbugs] at java.net.URLClassLoader.findClass(URLClassLoader.java:183) [findbugs] at java.lang.ClassLoader.loadClass(ClassLoader.java:294) [findbugs] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:281) [findbugs] at java.lang.ClassLoader.loadClass(ClassLoader.java:250) [findbugs] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:310) Colin Charles Daniels wrote: How about posting the errors you are getting? -Original Message- From: Colin Chalmers [mailto:[EMAIL PROTECTED] Sent: Monday, August 02, 2004 6:22 PM To: Maven Users List Subject: Re: [ANN] Maven FindBugs Plugin 0.8.2 released Hi, I am interested in adding this to our reports but couldn't quite get it to work. I tried adding it to the reports section of my project.xml but I got an error. Then I tried to run it by hand and got the message that it wasn't registered :-( Any ideas what's going wrong? Colin Jerome Lacoste wrote: On Sat, 2004-07-31 at 13:48 +0200, Eric Pugh wrote: I have updated the docs at http://maven-plugins.sourceforge.net/maven-findbugs-plugin/ind ex.html to include the findbugs report that is used while testing the plugin itself. This will give you a feeling for what the report looks like... Just a note for anyone who will be searching the report in the Project Reports section. It's not there but located in the Overview / sample report. Jerome - 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: artifact for jsp taglib: bug? bad practice? or what?
-Original Message-
From: Marcin Maciukiewicz [mailto:[EMAIL PROTECTED]
Sent: Monday, August 02, 2004 10:27 AM
To: Maven Users List
Subject: Re: artifact for jsp taglib: bug? bad practice? or what?
most appropriate solution is to relay on tld discovery
mechanism built-in into container
yeap... that's also the way:)
I have better idea than renaming tld... on taglib jar I'll set property
tld-filename handled by my maven.xml... damn in that case I'll loose
maven's dependency check ... ar:(
anyway.. I assume also that there is no support for placing tld's in
webapp structure in any goal?
Add the following to your tld dependency:
properties
war.bundletrue/war.bundle
/properties
This will place the tld in ${maven.war.tld.dir}. See
http://maven.apache.org/reference/plugins/war/properties.html.
--
Marcin Maciukiewicz
[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: Default value for ${maven.conf.dir}
-Original Message-
From: news [mailto:[EMAIL PROTECTED] Behalf Of Peter Nabbefeld
Sent: Sunday, August 01, 2004 8:46 AM
To: [EMAIL PROTECTED]
Subject: Re: Default value for ${maven.conf.dir}
Hello,
I shouldn't reply to my own comments - however, I've found out more
about the conf dirs, and I'd like it to be documented on the
Maven web site:
./conf is used from some plugins, e.g. the jar manifest is expected
here (using ${maven.conf.dir}, of course).
src/conf is therefore for app-only data.
The differences are sometime very marginal, as of course one will
sometimes have to edit e.g. the manifest file.
This has been a point of confusion for me as well. However, I don't know if
this explanation provides any clarity. As you said, genapp creates a
${basedir}/src/conf directory, but the default for maven.conf.dir is
${basedir}/conf. Also, the jar manifest file is expected in
${maven.conf.dir}, but who's to say that shouldn't be ${basedir}/src/conf?
Is it not also app-only data, as you say src/conf is for?
I suppose what I'm really looking for is a best practice or a standard
convention with respect to the conf dir. Is there a purpose for having
both ${basedir}/conf and ${basedir}/src/conf? Or should there be only one
conf dir for a project? If so, what is the recommended location --
${basedir}/conf or ${basedir}/src/conf?
Furthermore, what sorts of files is the conf dir intended to hold? I see
that some of the genapp templates put cactus-web.xml there, which makes
sense to me, but what is the app.properties intended for? What other files
are candidates for the conf dir?
It'd be very fine, if someone could document all the GenApp templates
(not only list them). Sometimes it will help to understand one simple
template, if there are docs for a more complicated one. I've understood
the default template only after having a look at the complex template:
I've seen the various conf dirs, then I began to understand.
Kind regards
Peter
Peter Nabbefeld schrieb:
Dion Gillard schrieb:
maven.conf.dir = ${basedir}/conf
Hmm, looks strange to me: While the conf directory is created
in the src
folder, the property points to the project root. Is there probably some
purpose for an additional conf directory in the root dir? Or should the
GenApp plugin create a project.properties file with an entry for
${maven.conf.dir} to point to src/conf?
Kind regards
Peter
On Sat, 31 Jul 2004 23:29:11 +0200, Peter Nabbefeld
[EMAIL PROTECTED] wrote:
Hello,
what is the default value for ${maven.conf.dir}? Due to
http://maven.apache.org/reference/user-guide.html#Behavioural_Properties
it is ${basedir}/conf, but at
http://maven.apache.org/reference/user-guide.html#Starting_a_New_Project
there is a tree structure ${basedir}/src/conf, generated by the GenApp
plugin, so I'd expect this to be the value of ${maven.conf.dir}. What is
the correct value?
Kind regards
Peter Nabbefeld
-
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: Default value for ${maven.conf.dir}
That WIKI doesn't mention anything about a 'conf' directory. However,
thanks for the reference. It is very useful.
-Original Message-
From: Carlos Sanchez [mailto:[EMAIL PROTECTED]
Sent: Sunday, August 01, 2004 1:11 PM
To: 'Maven Users List'
Subject: RE: Default value for ${maven.conf.dir}
Hi,
Take a look to http://wiki.codehaus.org/maven/DirectoryLayout
Regards
Carlos Sanchez
A Coruña, Spain
Oness Project
http://oness.sourceforge.net
I suppose what I'm really looking for is a best practice or
a standard convention with respect to the conf dir. Is
there a purpose for having both ${basedir}/conf and
${basedir}/src/conf? Or should there be only one conf dir
for a project? If so, what is the recommended location --
${basedir}/conf or ${basedir}/src/conf?
-
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]
Recommended location of package-list files?
Hi All, Just wondering if there is a recommended location to put package-list files. I tend to use offlineLinks with the javadoc plugin, but have not seen a recommended location to place the package-list files required when using offline linking. At the moment, I do something like the following, but I'm not necessarily crazy about it: src/package-lists/j2se/package-list src/package-lists/j2ee/package-list src/package-lists/commons-xxx/package-list ... Any suggestions? Thanks, Chuck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Unable to download from the remote repository
http://www.ibiblio.org/maven -Original Message- From: Frederic Gedin [mailto:[EMAIL PROTECTED] Sent: Saturday, July 31, 2004 11:17 AM To: Maven Users List Subject: Unable to download from the remote repository Hi I tried this morning to update some packages without any success. All attempts to download from the remote repository fail. Digging a little bit further, i see that maven.repo.remote contains http://www.ibiblio.org while I suspect it should be http://www.ibiblio.org/pub/packages/maven I am wrong? If no, how can I update the maven.repo.remote parameter? I tried by updating within project.properties without any success but I also presume i should be updated in a moer generic way elsewhere. Regards Frédéric - 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: First plugin
-Original Message- From: STRAYER, JON (SBCSI) [mailto:[EMAIL PROTECTED] Sent: Friday, July 23, 2004 4:23 PM To: 'Maven Users List' Subject: First plugin I'm working on my first plugin. Should I need to delete it from the cache each time in install it? Maven doesn't seem to pick up the changes otherwise. You should simply execute the plugin:uninstall goal before plugin:install. No need to manually delete the cache, as plugin:uninstall will invalidate it for you. From what I've found, you really only need to run plugin:uninstall if you have added or removed a goal/preGoal/postGoal in your plugin. - 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]
Post plugin:download action
Hi All,
Is there any built-in mechanism for performing tasks after downloading a
plugin (or at least after the plugin is expanded to the cache directory)?
What I would like to do is allow my plugin to do things immediately after
someone downloads it.
For example, I have developed a plugin that defines additional templates for
use with the standard genapp plugin. When someone downloads my plugin, I
want my plugin to perform some initialization. In this particular case, I
want my plugin to initialize itself by copying its template files to
${user.home}/.maven/template (after clearing out old copies of its template
files), which is a standard location that the genapp plugin searches for
templates.
Is there any way to do this, or is this an RFE?
Of course, within my plugin I could add a postGoal for plugin:download to do
this, but that won't help the first time someone downloads my plugin.
Cheers,
Chuck
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: The Genapp plugin
-Original Message-
From: Erik Husby [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 22, 2004 5:04 PM
To: Maven Users List
Subject: Re: The Genapp plugin
Erik Husby wrote:
Charles Daniels wrote:
Unfortunately, that won't work because the genapp plugin specifically
uses
${user.home}/.maven/template, not
${maven.home.local}/template. If this
isn't already in JIRA against the genapp plugin, it should be.
I added that issue yesterday.
Thanks for adding the issue. (See below for a suggestion regarding your
prodinfo:genapp goal.)
What I've just ended up doing is writing my own plugin with a goal that
builds on Charley's preGoal. Mine looks like this which compensates for
the above problem.
goal name=prodinfo:genapp
description=Generate Production Informatics applications from
templates.
!-- TODO: Delete/copy only when necessary --
ant:delete dir=${maven.local.home}/template/prodinfo/
ant:copy todir=${maven.local.home}/template/prodinfo
preservelastmodified=true
ant:fileset dir=${plugin.resources}/
/ant:copy
j:set var=maven.genapp.template.repository
value=${maven.local.home}/template/prodinfo/
genapp:generate /
/goal
So my developers will do maven prodinfo:genapp instead of maven
genapp to get my specific templates.
If you are going to create your own goal (prodinfo:genapp), then you don't
need to bother with using the standard template directory that the genapp
plugin uses. You can simply tell genapp to look in your own plugin
resources directory, as follows:
goal name=prodinfo:genapp
genapp:generate
maven.genapp.template.repository=${plugin.resources}/template/
/goal
This assumes that each of your application templates is rooted its own
subdirectory of ${plugin.resources}/template.
--
Erik Husby
Team Lead for Software Quality Automation
Broad Institute of MIT and Harvard
Rm. 2192 320 Charles St
Cambridge, MA 02141-2023
mobile: 781.354.6669, office: 617.258.9227, [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: Post plugin:download action
-Original Message-
From: Dion Gillard [mailto:[EMAIL PROTECTED]
Sent: Friday, July 23, 2004 5:08 AM
To: Maven Users List
Subject: Re: Post plugin:download action
Can't you just put it in the pluginl.jelly outside of a goal? And next
time maven runs it will be executed.
Nope. Doesn't get executed unless you execute a goal/preGoal/postGoal from
that plugin.
On Thu, 22 Jul 2004 14:22:44 +0100, Charles Daniels
[EMAIL PROTECTED] wrote:
Hi All,
Is there any built-in mechanism for performing tasks after downloading a
plugin (or at least after the plugin is expanded to the cache
directory)?
What I would like to do is allow my plugin to do things
immediately after
someone downloads it.
For example, I have developed a plugin that defines additional
templates for
use with the standard genapp plugin. When someone downloads my
plugin, I
want my plugin to perform some initialization. In this
particular case, I
want my plugin to initialize itself by copying its template files to
${user.home}/.maven/template (after clearing out old copies of
its template
files), which is a standard location that the genapp plugin searches for
templates.
Is there any way to do this, or is this an RFE?
Of course, within my plugin I could add a postGoal for
plugin:download to do
this, but that won't help the first time someone downloads my plugin.
Cheers,
Chuck
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
http://www.multitask.com.au/people/dion/
-
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: The Genapp plugin
Erik, Don't use goals in your template.jelly script. Simply place all jelly scripting at the top level within the project node. For example, your example should like as follows: ?xml version=1.0? project default=broadTemplate xmlns:j=jelly:core xmlns:i=jelly:interaction xmlns:ant=jelly:ant xmlns:define=jelly:define xmlns:u=jelly:util echoIn the broad template.jelly file./echo /project Works like a charm for my templates. -- Chuck -Original Message- From: Erik Husby [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 21, 2004 8:07 PM To: [EMAIL PROTECTED] Subject: The Genapp plugin Just started looking at the genapp plugin. Setting up a template for use in my organization. One of the things you can do for a template is have a template.jelly where you are supposed to be able to do template specific tasks. However, there is no documentation on how that template.jelly file is to be setup and none of the provided templates use this feature. So I created a template.jelly that looks like this: ?xml version=1.0? project default=broadTemplate xmlns:j=jelly:core xmlns:i=jelly:interaction xmlns:ant=jelly:ant xmlns:define=jelly:define xmlns:u=jelly:util goal name=broadTemplate echoIn the broad template.jelly file./echo /goal /project When I run the template is processed but the system fails when it tries to execute my template.jelly file What does the error message Plugin Housing can not be null mean? It is issued by the class MavenGoalAction. I've verified that the jelly statement j:import file=somefile/ in another maven.xml file will generate the same error. Its apparent that this feature was not tested, and I have raised an issue in Jira for it (mpgenapp-16) but if someone has an explanation and a work around, I would be most grateful. -- Sample output from executing genap Z:\IdeaProjects\junkmaven -Dmaven.genapp.template.repository=z:\.maven\template genapp __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0 Enter a project template to use: [default] broad Please specify an id for your application: [app] junk Please specify a name for your application: [Example Application] JunkApplication Please specify the package for your application: [example.app] name.erikhusby.junk Please specify the CVS module for this application. [sequence/app] name/junk build:start: genapp: [copy] Copying 1 file to Z:\IdeaProjects\junk\src\java\name\erikhusby\junk [copy] Copying 1 file to Z:\IdeaProjects\junk\src\test\name\erikhusby\junk [echo] Use template.jelly file present in z:\.maven\template/broad. BUILD FAILED File.. z:\.maven\cache\maven-genapp-plugin-2.2\plugin.jelly Element... j:import Line.. 173 Column 86 file:/z:/.maven/template/broad/template.jelly:10:32: goal Plugin Housing can not be null Total time: 22 seconds Finished at: Wed Jul 21 14:24:13 EDT 2004 Z:\IdeaProjects\junk -- Erik Husby Team Lead for Software Quality Automation Broad Institute of MIT and Harvard Rm. 2192 320 Charles St Cambridge, MA 02141-2023 mobile: 781.354.6669, office: 617.258.9227, [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: The Genapp plugin
-Original Message-
From: Erik Husby [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 21, 2004 9:01 PM
To: Maven Users List
Subject: Re: The Genapp plugin
Charles Daniels wrote:
Works like a charm for my templates.
-- Chuck
How do you make your templates available to the rest of your company? Do
you provide a script that wraps maven genapp with appropriate
parameters?
Good question. This is something I have been wrestling with recently
myself. I have created a plugin specifically to aid in building
applications using my company's software. Part of what the plugin provides
is a template for starting a new project. One thing I had considered was
creating an alternative genapp goal as part of the plugin with a name of the
form prefix:genapp, which would use the genapp tag supplying the location of
my template repository within my plugin.
However, I opted not to create an alternative goal just to pickup my custom
template. I want to be able to use the standard genapp goal. After digging
through the genapp plugin.jelly file, I noticed that it will check for
templates in the ${user.home}/.maven/template directory, if you specify a
template that it does not have in its own plugin resources. I decided to
populate that directory with my custom template files. In order to do this
without requiring developers to do any work (other than install my plugin),
I decided to create a genapp preGoal in my plugin. The preGoal simply
copies my template files to the ${user.home}/.maven/template directory so
that genapp can find my template.
The only thing I have to do now is check the files in that directory against
the files in my plugin so that I only update the template directory if the
plugin contains newer files. Here's the preGoal in my plugin:
preGoal name=genapp
!-- TODO: Delete/copy only when necessary --
ant:delete dir=${user.home}/.maven/template/mytemplate/
ant:copy todir=${user.home}/.maven/template/mytemplate
preservelastmodified=true
ant:fileset dir=${plugin.resources}/genapp/mytemplate/
/ant:copy
/preGoal
I first delete my template directory in case a new release of my plugin has
eliminated or moved any template files.
I hope that helps.
-- Chuck
--
Erik Husby
Team Lead for Software Quality Automation
Broad Institute of MIT and Harvard
Rm. 2192 320 Charles St
Cambridge, MA 02141-2023
mobile: 781.354.6669, office: 617.258.9227, [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: FTP stuff
Thanks for the suggestion. I'll give it a try. -Original Message- From: Costin Grigore [mailto:[EMAIL PROTECTED] Sent: Monday, July 19, 2004 4:41 PM To: Maven Users List Subject: Re: FTP stuff I have this problem also on maven rc3. I resolved it by removing the org/apache/tools/ant/taskdefs/optional/net directory from ant-optional-1.5.3-1.jar and adding a dependency to the ant-1.6.1.jar, ant-commons-net.1.6.1.jar and commons-net-1.1.0.jar. Something like this: typedef name=ftp classname=org.apache.tools.ant.taskdefs.optional.net.FTP classpath pathelement location=d:\workspace\.maven\repository\ant\jars\ant-1.6.1.jar/ pathelement location=d:\workspace\.maven\repository\ant\jars\ant-commons-net- 1.6.1.jar/ pathelement location=d:\workspace\.maven\repository\commons-net\jars\commons- net-1.1.0.jar/ /classpath /typedef This is a hack, but until maven is compiled using a newer ant version is a solution ;) raisercostin - 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: FTP stuff
Dion, Adding the commons-net dependency makes no difference. I doubt this could make a difference anyway, because from what I can tell maven uses ant 1.5.3-1 and the ftp task in that version does not use commons-net, but rather the original ORO NetComponents jar file. However, adding NetComponents.jar to the dependency makes no difference either. Here's a simple example of a goal I put in my maven.xml: goal name=ftp-test ant:ftp server=myftpserver userid=myftpuserid password=myftppassword passive=true verbose=true action=get ant:fileset dir=. ant:include name=*.*/ /ant:fileset /ant:ftp /goal There are a number of files in the default ftp directory, but when I run 'maven ftp-test', here's the output I get: __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0 Attempting to download xdoclet-1.2.2-SNAPSHOT.jar. Response content length is not known Attempting to download xdoclet-web-module-1.2.2-SNAPSHOT.jar. Response content length is not known BUILD SUCCESSFUL Total time: 7 seconds Finished at: Sun Jul 18 16:59:05 BST 2004 Not a peep from the ftp task, but I can directly use my ftp client to fetch files without a problem. Any other ideas? -- Chuck -Original Message- From: Dion Gillard [mailto:[EMAIL PROTECTED] Sent: Sunday, July 18, 2004 3:33 PM To: Maven Users List Subject: Re: FTP stuff Are your dependencies specified to include commons.net? On Sun, 18 Jul 2004 15:28:34 +0200, Colin Chalmers [EMAIL PROTECTED] wrote: Hi all, I've just downloaded ver 1 after playing with previous versions along the way. Everything appears to be working OK except when I try to use FTP, even ant:ftp doesn't seem to work. When maven hits this script it just prints out the settings but does nothing with them. I did see some older messages concerning this issue and that it probably had to do with the commons.net jar file. Is this still the case? Are other using ftp successfully? Colin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ - 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: Unable to deploy distribution to remote
Also, how do you actually deploy something? The artifact plugin doesn't have any goals, only tags. The jar plugin has it's own jar:deploy goal, but what about the plugin plugin? How do you deploy a plugin to a remote repository? The plugin plugin has no goal for achieving this. -Original Message- From: Vincent Geh [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 13, 2004 10:23 AM To: Maven Users List Subject: Re: Unable to deploy distribution to remote What kinds of properties should I include? Jörg Schaible wrote: Vincent Geh wrote on Tuesday, July 13, 2004 10:57 AM: Hi there, it seems that i'm unable to deploy distribution to remote repo after swtching to Maven 1.0-rc4. Anybod knows why? RC4 uses now the artifact-plugin and you might not have set the necessary properties. :) -- Jörg - 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: Unable to deploy distribution to remote
Yes, I've seen that, but that doesn't say how to actually deploy anything. -Original Message- From: Paul Spencer [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 13, 2004 11:37 AM To: Maven Users List Subject: Re: Unable to deploy distribution to remote See the following http://maven.apache.org/reference/plugins/artifact/examples.html Paul Spencer Charles Daniels wrote: Also, how do you actually deploy something? The artifact plugin doesn't have any goals, only tags. The jar plugin has it's own jar:deploy goal, but what about the plugin plugin? How do you deploy a plugin to a remote repository? The plugin plugin has no goal for achieving this. -Original Message- From: Vincent Geh [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 13, 2004 10:23 AM To: Maven Users List Subject: Re: Unable to deploy distribution to remote What kinds of properties should I include? Jörg Schaible wrote: Vincent Geh wrote on Tuesday, July 13, 2004 10:57 AM: Hi there, it seems that i'm unable to deploy distribution to remote repo after swtching to Maven 1.0-rc4. Anybod knows why? RC4 uses now the artifact-plugin and you might not have set the necessary properties. :) -- Jörg - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Unable to deploy distribution to remote
Ah, thanks Brett. I see that the plugin:repository-deploy goal was added in version 1.2 of the plugin, however, even in the current version (1.5.1) this goal is not listed on the Goals page. What do I need to do to raise this as an issue? -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 13, 2004 12:55 PM To: Maven Users List Subject: Re: Unable to deploy distribution to remote plugin:repository-deploy (just uploading updated docs now) On Tue, 13 Jul 2004 11:14:39 +0100, Charles Daniels [EMAIL PROTECTED] wrote: Also, how do you actually deploy something? The artifact plugin doesn't have any goals, only tags. The jar plugin has it's own jar:deploy goal, but what about the plugin plugin? How do you deploy a plugin to a remote repository? The plugin plugin has no goal for achieving this. -Original Message- From: Vincent Geh [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 13, 2004 10:23 AM To: Maven Users List Subject: Re: Unable to deploy distribution to remote What kinds of properties should I include? Jörg Schaible wrote: Vincent Geh wrote on Tuesday, July 13, 2004 10:57 AM: Hi there, it seems that i'm unable to deploy distribution to remote repo after swtching to Maven 1.0-rc4. Anybod knows why? RC4 uses now the artifact-plugin and you might not have set the necessary properties. :) -- Jörg - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Unable to deploy distribution to remote
Excellent. Thank you. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 13, 2004 2:00 PM To: Maven Users List Subject: Re: Unable to deploy distribution to remote It was documented very recently, and I've just uploaded it now. It was MPPLUGIN-18 On Tue, 13 Jul 2004 13:57:09 +0100, Charles Daniels [EMAIL PROTECTED] wrote: Ah, thanks Brett. I see that the plugin:repository-deploy goal was added in version 1.2 of the plugin, however, even in the current version (1.5.1) this goal is not listed on the Goals page. What do I need to do to raise this as an issue? -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 13, 2004 12:55 PM To: Maven Users List Subject: Re: Unable to deploy distribution to remote plugin:repository-deploy (just uploading updated docs now) On Tue, 13 Jul 2004 11:14:39 +0100, Charles Daniels [EMAIL PROTECTED] wrote: Also, how do you actually deploy something? The artifact plugin doesn't have any goals, only tags. The jar plugin has it's own jar:deploy goal, but what about the plugin plugin? How do you deploy a plugin to a remote repository? The plugin plugin has no goal for achieving this. -Original Message- From: Vincent Geh [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 13, 2004 10:23 AM To: Maven Users List Subject: Re: Unable to deploy distribution to remote What kinds of properties should I include? Jörg Schaible wrote: Vincent Geh wrote on Tuesday, July 13, 2004 10:57 AM: Hi there, it seems that i'm unable to deploy distribution to remote repo after swtching to Maven 1.0-rc4. Anybod knows why? RC4 uses now the artifact-plugin and you might not have set the necessary properties. :) -- Jörg - 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] - 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: Changes report is missing
Did you add reportmaven-changes-plugin/report to your list of reports in your project.xml file? -Original Message- From: ssuriya narayanan [mailto:[EMAIL PROTECTED] Sent: Friday, July 09, 2004 10:20 AM To: [EMAIL PROTECTED] Subject: Changes report is missing Hello all Its important for me to add changes to my project site. I'm trying that for days. Can you please tell me how I can achieve that. Here are the methods i tried changes.xml [ ?xml version=1.0 ? document properties titleProject changes/title author email=[EMAIL PROTECTED]author/author /properties body release version=test1.0 date=2004-05-03 action dev=devtes type=update Updating for test /action action dev=devtes type=update **Updating for test** /action action dev=devtes type=Fixed **bugging a fix** /action /release /body /document ] project home c:\projects placed my changes.xml under c:\projects\xdocs build source ...\src maven doesnt recognises it. expecting a quick answer as i require one. Thanks suriya __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail - 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: JavaDoc issue
No, the issue was with generating javadocs using javadoc 1.3. By the way, this is still an issue with maven 1.0-rc4 and nobody has ever addressed the issue. Is this in JIRA? -Original Message- From: Puneet Garg [mailto:[EMAIL PROTECTED] Sent: Friday, July 09, 2004 2:31 PM To: Maven Users List Subject: JavaDoc issue Hi, I read somewhere that maven has issues in creating javadocs with jdk1.4. Is this issue fixed ?? Because I ran maven javadoc and it created javadocs for me..!! I am using 1.0rc4 Puneet - 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]
HttpException downloading dependencies (1.0-rc4)
Hi All, Today I upgraded to rc4 from rc3. Now I am getting HttpExceptions when attempting to download dependencies. I recall something on this subject in the list, but I can't find it in the archives. Here's my output: Attempting to download xdoclet-1.2.2-SNAPSHOT.jar. Error getting URI host org.apache.commons.httpclient.HttpException: Redirect from host www.ibiblio.com to www.ibiblio.org i s not supported at org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect(HttpMethodBa se.java:1243) at org.apache.commons.httpclient.HttpMethodBase.processRedirectResponse(HttpMet hodBase.java: 1191) at org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded(HttpMethodBase.ja va:977) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:109 5) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:675) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:529) at org.apache.maven.util.HttpUtils.getFile(HttpUtils.java:378) at org.apache.maven.util.HttpUtils.getFile(HttpUtils.java:274) at org.apache.maven.util.HttpUtils.getFile(HttpUtils.java:170) at org.apache.maven.verifier.DependencyVerifier.getRemoteArtifact(DependencyVer ifier.java:31 7) at org.apache.maven.verifier.DependencyVerifier.getDependencies(DependencyVerif ier.java:254) at org.apache.maven.verifier.DependencyVerifier.satisfyDependencies(DependencyV erifier.java: 171) at org.apache.maven.verifier.DependencyVerifier.verify(DependencyVerifier.java: 97) at org.apache.maven.project.Project.verifyDependencies(Project.java:1365) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:492) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:266) at org.apache.maven.cli.App.doMain(App.java:486) at org.apache.maven.cli.App.main(App.java:1215) at java.lang.reflect.Method.invoke(Native Method) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Invalid Redirect URI from: http://www.ibiblio.com:80/maven/xdoclet/jars/xdoclet-1.2.2-SNAPSHOT.jar t o: http://www.ibiblio.org/maven/xdoclet/jars/xdoclet-1.2.2-SNAPSHOT.jar warning: last-modified not specified Error getting URI host org.apache.commons.httpclient.HttpException: Redirect from host www.ibiblio.com to www.ibiblio.org i s not supported at org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect(HttpMethodBa se.java:1243) at org.apache.commons.httpclient.HttpMethodBase.processRedirectResponse(HttpMet hodBase.java: 1191) at org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded(HttpMethodBase.ja va:977) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:109 5) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:675) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:529) at org.apache.maven.util.HttpUtils.getFile(HttpUtils.java:378) at org.apache.maven.util.HttpUtils.getFile(HttpUtils.java:274) at org.apache.maven.util.HttpUtils.getFile(HttpUtils.java:186) at org.apache.maven.verifier.DependencyVerifier.getRemoteArtifact(DependencyVer ifier.java:31 7) at org.apache.maven.verifier.DependencyVerifier.getDependencies(DependencyVerif ier.java:254) at org.apache.maven.verifier.DependencyVerifier.satisfyDependencies(DependencyV erifier.java: 171) at org.apache.maven.verifier.DependencyVerifier.verify(DependencyVerifier.java: 97) at org.apache.maven.project.Project.verifyDependencies(Project.java:1365) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:492) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:266) at org.apache.maven.cli.App.doMain(App.java:486) at org.apache.maven.cli.App.main(App.java:1215) at java.lang.reflect.Method.invoke(Native Method) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Invalid Redirect URI from: http://www.ibiblio.com:80/maven/xdoclet/jars/xdoclet-1.2.2-SNAPSHOT.jar.m d5 to: http://www.ibiblio.org/maven/xdoclet/jars/xdoclet-1.2.2-SNAPSHOT.jar.md5 Response content length is not known warning: last-modified not specified Is there some property I need to set? I am not behind a firewall, and everything was working fine with rc3. Thanks, Chuck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: HttpException downloading dependencies (1.0-rc4)
Ah, thanks. Didn't realize that I had accidentally made www.ibiblio.com the repo rather than www.ibiblio.org. That fixed it. -Original Message- From: Alwyn Schoeman [mailto:[EMAIL PROTECTED] Sent: Friday, July 09, 2004 4:45 PM To: Maven Users List Subject: Re: HttpException downloading dependencies (1.0-rc4) Would explicitly defining a www.ibiblio.org remote repository be a temporary fix? On Fri, 9 Jul 2004 16:24:58 +0100, Charles Daniels [EMAIL PROTECTED] wrote: Hi All, Today I upgraded to rc4 from rc3. Now I am getting HttpExceptions when attempting to download dependencies. I recall something on this subject in the list, but I can't find it in the archives. Here's my output: Attempting to download xdoclet-1.2.2-SNAPSHOT.jar. Error getting URI host org.apache.commons.httpclient.HttpException: Redirect from host www.ibiblio.com to www.ibiblio.org i s not supported at org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect(Ht tpMethodBa se.java:1243) at org.apache.commons.httpclient.HttpMethodBase.processRedirectRespon se(HttpMet hodBase.java: 1191) at org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded(HttpMet hodBase.ja va:977) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBas e.java:109 5) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient. java:675) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient. java:529) at org.apache.maven.util.HttpUtils.getFile(HttpUtils.java:378) at org.apache.maven.util.HttpUtils.getFile(HttpUtils.java:274) at org.apache.maven.util.HttpUtils.getFile(HttpUtils.java:170) at org.apache.maven.verifier.DependencyVerifier.getRemoteArtifact(Dep endencyVer ifier.java:31 7) at org.apache.maven.verifier.DependencyVerifier.getDependencies(Depen dencyVerif ier.java:254) at org.apache.maven.verifier.DependencyVerifier.satisfyDependencies(D ependencyV erifier.java: 171) at org.apache.maven.verifier.DependencyVerifier.verify(DependencyVeri fier.java: 97) at org.apache.maven.project.Project.verifyDependencies(Project.java:1365) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:492) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:266) at org.apache.maven.cli.App.doMain(App.java:486) at org.apache.maven.cli.App.main(App.java:1215) at java.lang.reflect.Method.invoke(Native Method) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Invalid Redirect URI from: http://www.ibiblio.com:80/maven/xdoclet/jars/xdoclet-1.2.2-SNAPSHOT.jar t o: http://www.ibiblio.org/maven/xdoclet/jars/xdoclet-1.2.2-SNAPSHOT.jar warning: last-modified not specified Error getting URI host org.apache.commons.httpclient.HttpException: Redirect from host www.ibiblio.com to www.ibiblio.org i s not supported at org.apache.commons.httpclient.HttpMethodBase.checkValidRedirect(Ht tpMethodBa se.java:1243) at org.apache.commons.httpclient.HttpMethodBase.processRedirectRespon se(HttpMet hodBase.java: 1191) at org.apache.commons.httpclient.HttpMethodBase.isRetryNeeded(HttpMet hodBase.ja va:977) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBas e.java:109 5) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient. java:675) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient. java:529) at org.apache.maven.util.HttpUtils.getFile(HttpUtils.java:378) at org.apache.maven.util.HttpUtils.getFile(HttpUtils.java:274) at org.apache.maven.util.HttpUtils.getFile(HttpUtils.java:186) at org.apache.maven.verifier.DependencyVerifier.getRemoteArtifact(Dep endencyVer ifier.java:31 7) at org.apache.maven.verifier.DependencyVerifier.getDependencies(Depen dencyVerif ier.java:254) at org.apache.maven.verifier.DependencyVerifier.satisfyDependencies(D ependencyV erifier.java: 171) at org.apache.maven.verifier.DependencyVerifier.verify(DependencyVeri fier.java: 97) at org.apache.maven.project.Project.verifyDependencies(Project.java:1365) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:492) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:266) at org.apache.maven.cli.App.doMain(App.java:486) at org.apache.maven.cli.App.main(App.java:1215) at java.lang.reflect.Method.invoke(Native Method) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java
RE: maven parallel/sequential
You need to move attainGoal name=weblogic:server-start/ just above your sequential tag (and just after your parallel tag). As you have it written, nothing will execute in parallel since all of your subtasks are within the sequential tags. -Original Message- From: Jesper Linvald [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 29, 2004 9:24 AM To: [EMAIL PROTECTED] Subject: maven parallel/sequential Hello all, I been trying to get the ant parallel task to work with no success :( In my goal I have: parallel sequential attainGoal name=weblogic:server-start/ waitfor maxwait=3 maxwaitunit=minute checkevery=100 checkeveryunit=millisecond http url= http://localhost:7001/console/login/LoginForm.jsp/ /waitfor attainGoal name=selfservice:weblogic-deploy; / /sequential /parallel The weblogic:server-start uses the java task to startup a weblogic server (fork=true) The starts up fine but nothing more happens - I never get to the selfservice:weblogic-deploy; - the server blocks the process... Can anybody tell me what I might be doing wrong? I also tried prepending ant to the tags (ant:parallel) but this makes no difference... Best regards Jesper Linvald MAERSK DATA TRANSPORT Tel no.: +45 3911 1891 e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RFE for the war plugin
Brill,
First, let me apologize for calling you Brent in my previous posting.
Second, I agree with you. It would be a very simple enhancement to the war
plugin. All that should be needed are:
1. Define a new Boolean property, named something to the effect of
maven.war.generate.jar
2. Enhance war:webapp goal by adding something similar to the following
(which is the same thing that the postGoal does that I gave in my previous
reply to you):
j:if test=${maven.war.generate.jar}
attainGoal name=jar:jar/
ant:copy file=${maven.final.name}.jar
todir=${maven.war.webapp.dir}/WEB-INF/lib/
ant:delete dir=${maven.war.webapp.dir}/WEB-INF/classes/
/j:if
By default, the war plugin would set the new property to false, so that
default behavior remains unchanged (i.e., no jar file is generated).
-- Chuck
-Original Message-
From: Brill Pappin [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 29, 2004 12:01 PM
To: Maven Users List
Subject: Re: RFE for the war plugin
I thought I had explained this?
Under no circumstances am I asking that classes not ever go into the
classes directory, I'm not even asking that the JAR method be the
default... I just want to be able to do it.
Our requirements do not clash not even a little bit. So far, I've only
herd reasons against it like we don't want to, because we can't see the
value while I've given a good reason to add it -- I don't see where the
problem is in terms of *adding the ability*... please note I didn't say
*remove the old method*.
As for convincing people, I don't actually care if you want to use it
or not; I explained why I was asking for it and it's a valid reason with
a solid implementation behind it (the subject is RFE with means request
for enhancement).
If you want to know more about what I'm doing (and why I'm asking for
this), you can get a very good idea at this site:
http://java.sun.com/j2se/1.4.2/docs/guide/versioning/index.html
Specifically take a look at the Package Versioning Specification which
is link to the URL above, or at this URL:
http://java.sun.com/j2se/1.4.2/docs/guide/versioning/spec/versioni
ngTOC.html
I apologize to everyone if I'm sounding a bit huffy in this post but
I've said the same thing for the 3rd time now.
Frankly I think it imperative in a tool that your not supposed to have
to customize too much, that all the options are covered... and that
alone is a reason to add this ability.
Mavin is built on the premise that the build is uniform and easy, so
if I go and write my own plugin that duplicates exactly what another
plugin already does except one small addition, what the heck is the
point of Maven in the first place? I'd be better off using Ant.
- Brill Pappin
Maczka Michal wrote:
But sometimes two users have clashing requirements ( I am myself
also a user
of war plugin
and in some cases for some reasons I really need to have classes in
WEB-INF/classes folder).
If you are not convincing enough you have 0% of chances that such change
which your are asking for will be ever made.
-
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: RFE for the war plugin
Brett,
If you want to generate a jar file for your war file and do not want to
create 2 subprojects (as is the general convention), you can create a very
simple postGoal that will jar your class files just prior to construction of
your war file:
postGoal name=war:webapp
attainGoal name=jar:jar/
ant:copy file=${maven.final.name}.jar
todir=${maven.war.webapp.dir}/WEB-INF/lib/
ant:delete dir=${maven.war.webapp.dir}/WEB-INF/classes/
/postGoal
I haven't tested it, so you may have to fiddle with it a bit, but I think
you get the idea.
Cheers,
Chuck
-Original Message-
From: Brill Pappin [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 29, 2004 9:03 AM
To: Maven Users List
Subject: Re: RFE for the war plugin
Actually I don't really have much of a problem with Eclipse, other than
I have to keep the parts of an app together... remember I'm one of the
group who is trying to get the old fuddy-duddies around here to use
Maven, so not everyone would get it if the parts of an app where
spread all over the repository.
I'm having a hard enough time getting people to build with maven
(despite it being easier)... I've even got a couple of guys that won't
even *execute* it on our development box to build an app, for no reason
other than being stubbourn.
BTW - A little off topic but following that last thought -- I see Mavens
value, but if you want to gain more support and remove some of the
roadblocks (for me at least) you have to target the agile folks; we are
an agile shop but its they are who are the ones bulking even though
Maven fits right into agile practice.
- Brill Pappin
Matt Read wrote:
What problems do you have with Eclipse? I do exactly this across
a project
with many components which are re-used in various combinations
of .ear and
.war files using the Maven dependency mechanism and have no
problems at all
using Eclipse as my IDE.
Matt.
-Original Message-
From: Brill Pappin [mailto:[EMAIL PROTECTED]
Sent: 29 June 2004 13:38
To: Maven Users List
Subject: Re: RFE for the war plugin
Yes, I thought of doing that very thing :) however I then
have problems with Eclipse as it doesn't understand
multi-project builds, and you really want all the parts of an
application in the same place.
Still doable, but less than optimum.
- Brill
-
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: RFE for the war plugin
If you really want to create a jar file instead of deploying your classes in WEB-INF/classes, just split your project into 2 subprojects. One subproject will create your jar file. The other subproject will build your war file and will include the jar file as a dependency, with the war.bundle property set to true (just like any other dependency that you bundle into your war file). -Original Message- From: Brill Pappin [mailto:[EMAIL PROTECTED] Sent: Monday, June 28, 2004 2:21 PM To: Maven Users List Subject: Re: RFE for the war plugin To clarify; I'm not asking that the classes dir go away, I'm just asking for the ability to use a jar instead. Which should be a fairly simple addition to the war goal. Doing this allows me to use the manifest versioning, labeling and dependency parts of the manifest. For example, my code currently logs not only the file and line number that an exception happened in, but also the package and version of the jar, because in my situation it's possible that I have different servers running different revisions of the code. Your class-load order comment is a good point, but I actually see this as a bonus for the JAR argument, in that I can quickly patch a library or over-ride a log4j properties file without re-deploying... not that I would tend to do this if I could help it, but I've seen the need for it recently (in an emergency). - Brill Pappin Tomasz Pik wrote: On Mon, 28 Jun 2004 16:02:44 +0200, Göschl,Siegfried [EMAIL PROTECTED] wrote: Hi Tomasz, It is actually very convenient to supply a project specific log4j.properties since this is the vey first one to be found regardless of any other log4j.properties found in JARs Yes, I know. And that's why I'm not sure if it's the best idea to package classes into jar file during building war file. I understand that it might be useful in case of huge set of small classes but generally packaging classes in 'war' project into jar during build war file may leads to problems. So, it there'll be such possibilty in 'war' plugin - please, make it not-default. Regards, Tomek Cheers, Siegfried Goeschl -Original Message- From: Tomasz Pik [mailto:[EMAIL PROTECTED] Sent: Montag, 28. Juni 2004 15:03 To: Maven Users List Subject: Re: RFE for the war plugin On Mon, 28 Jun 2004 08:53:45 -0400, Brill Pappin [EMAIL PROTECTED] wrote: I'm sure some of us would prefer to keep the WEB-INF/classes dir, so my suggestion would be to include a switch property that would allow the user to use one or the other. Here's one reason: servlet specs define, that classes from WEB-INF/classes are loaded before WEB-INF/lib so this may be used as some kind of 'overloading', for example for classes from 'third party' libraries (I know it's ugly but it's possible due to spec). Regards, Tomek - 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] -- Any sufficiently advanced magic is indistinguishable from technology. - Arthur C Anticlarke - 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: maven javadoc [RC2] Problem
The spaces in your path could be the cause of your problems. Try installing Maven into a location where none of the directory names contain spaces. I'd also recommend that you place your project files somewhere other than under the Maven directory. --- Menetrieux Remy [EMAIL PROTECTED] wrote: When javadoc goals generate the file list in a javadoc file. It generate with an absolute Path. I run mave from the C:\Program Files\Apache Software Foundation\Maven-1.0-rc2\project_name\ Have you any idea to resolve this ? Eg: My javadoc file : C:\Program Files\Apache Software Foundation\Maven-1.0-rc2\project_name\src\xxx\\xx\\x x\\Remy.java C:\Program Files\Apache Software Foundation\Maven-1.0-rc2\project_name\src\xxx\\xx\\x x\\RemyCheck.java C:\Program Files\Apache Software Foundation\Maven-1.0-rc2\project_name\src\xxx\\xx\\x x\\RemyHome.java C:\Program Files\Apache Software Foundation\Maven-1.0-rc2\project_name\src\xxx\\xx\\x x\\RemyImpl.java C:\Program Files\Apache Software Foundation\Maven-1.0-rc2\project_name\src\xxx\\xx\\x x\\RemyPk.java -Message d'origine- De : Kevin Hagel [mailto:[EMAIL PROTECTED] Envoyé : lundi 29 mars 2004 16:05 À : Maven Users List Objet : Re: maven javadoc [RC2] Problem can you just use maven.javadoc.package=* Menetrieux Remy wrote: My package Tag contain com.x.project_name I don't understand why maven get my absolute path to my project.. -Message d'origine- De : Andy Jefferson [mailto:[EMAIL PROTECTED] Envoyé : lundi 29 mars 2004 15:57 À : Maven Users List Objet : Re: maven javadoc [RC2] Problem On Monday 29 Mar 2004 14:51, Menetrieux Remy wrote: Hi, When I run maven with the javadoc I obtain this errors : maven-javadoc-plugin:report: [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] javadoc: Illegal package name: C:\Program [javadoc] javadoc: Illegal package name: Files\Apache [javadoc] javadoc: Illegal package name: Foundation\Maven [javadoc] javadoc: File not found: 1.0-rc2\project\src\com\. What did you put in project.xml for package ? HTH - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited and may be a violation of law. If you received this transmission in error, please contact the sender by reply e-mail and delete and destroy all copies of the material, including all copies stored in the recipient's computer, printed or saved to disk. Thank you. Software virus: Europcar has taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. Europcar cannot accept liability for any loss or damage caused by software viruses. Intellectual Property: Europcar has built up a significant reputation in the name Europcar and has a number of trademark applications and registrations in many countries. No trademarks, service marks, and trade names owned or licensed by Europcar or its affiliates may be copied, reproduced, republished, uploaded, posted, transmitted, or distributed in any way, without the prior written consent of Europcar. - 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: Changelog report problem
Use a different delimiter, such as a pipe. See also the section under the heading repository at http://maven.apache.org/reference/project-descriptor.html. In your example, you might try the following: scm|cvs|pserver|[EMAIL PROTECTED]|d:/myrepository|mymodule/src --- Veerasamy, Thirumalai (Cognizant) [EMAIL PROTECTED] wrote: In case the repository is in a windows machine how do I denote 6 tokens Eg.. scm:cvs:pserver:[EMAIL PROTECTED]:d:/myrepository:mymodule/src here d:/myrepository is the repository location and mymodule/src is the module. But it throws the connection contains more than 6 tokens. -Original Message- From: Morris, Jason [IT] [mailto:[EMAIL PROTECTED] Sent: Monday, March 22, 2004 11:30 PM To: Maven Users List Subject: RE: Changelog report problem You have to have six tokens in the connection tag content: scm:cvs:pserver:[EMAIL PROTECTED]:/myrepository:mymodule/src or similar or it barfs - but it should report it in the log. Jason -Original Message- From: Maarten Coene [mailto:[EMAIL PROTECTED] Sent: 22 March 2004 17:05 To: Maven Users List Subject: Re: Changelog report problem Which version of the CVS server are you running ? The changelog (and related) plugins doesn't work properly for CVS versions 1.11.12 . I've created an issue in Jira for this some time ago, but it hasn't been solved yet. http://jira.codehaus.org/ViewIssue.jspa?key=MPCHANGELOG-31 regards, Maarten Ian Black wrote: Hi, I'm trying to get the changelog (and related CVS reports) to run properly. I've tried (successfully) to connect to CVS before generating the site reportson the command line. I've tried placing the 'user' directly into the connection address (in the project.xml file) like so...scm:cvs:pserver:[EMAIL PROTECTED] And I've tried placing the 'user' into the build.properties file and using the property like so...scm:cvs:pserver:[EMAIL PROTECTED] All to no avail. CVS reports are empty. Maven log file shows no scm errors. The builds are successful each time and I have a pre-existing connection to CVS each time too. Any thoughts on what I may be doing wrong or what else I could try? Thanks again, Ian. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.618 / Virus Database: 397 - Release Date: 09/03/2004 - 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] This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful. Visit us at http://www.cognizant.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin configuration and behavior
Hi Eric, I just tried your suggestion, but got an error because the project.xml file for the maven-javadoc-plugin extends ../project.xml, which doesn't exist. What can I do? Cheers, Chuck --- Eric Giguere [EMAIL PROTECTED] wrote: Hi Charles When applying patches to a plugin, you should then afterward install it in maven so that the cache for goals is refreshed and all files deployed. You can perform this by calling plugin:install goal from the directory where the source of the modified plugin. Never got that error if you modify an existing goal, but I guess that when adding goals, the install call in necessary. Hope it helps. Eric. Charles Daniels wrote: Hi, I am quite new to Maven and am having a difficult time understanding some behavior I am seeing with respect to plugins. I have been doing some experimentation with the javadoc plugin to try to resolve some other issue, but ran across some behavior that I don't understand. In an attempt to mimic the war:load goal, I placed an empty javadoc:load goal within the plugin.jelly file of the javadoc plugin (v1.4). Then, I added javadoc:load to the prereqs of the javadoc goal. When I run 'maven javadoc', I can see from the output that the javadoc:load goal was attained prior to the javadoc goal, as expected. However, when I attempt to directly attain the javadoc:load goal (via 'maven javadoc:load'), I get the following message: INTERNAL ERROR Reference made to goal 'javadoc:load' which has no definition. What am I missing? Why would I get this message when I directly attempt to attain the javadoc:load goal, but get no complaints when it is attained via a prereq? I am getting very confused by Maven's behavior. Any clarification on this type of behavior will be greatly appreciated. Cheers, Chuck - 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: [javadoc plugin] Javadocs not generated correctly
Any takers? --- Charles Daniels [EMAIL PROTECTED] wrote: I posted this issue earlier, but had only a couple of replies without any suggestions for a fix, so I will ask again to see if there is a solution. The problem I am encountering is that the javadoc plugin does not generate the package summary table, nor does it generate the standard frame that appears in the upper left of the browser (where the package list should appear). An earlier reply indicated that the javadocs are correctly generated when using JDK 1.4, but I must be able to use JDK 1.3. I cannot create a dependency on JDK 1.4 for this project. I looked at the plugin script, but can't see anything wrong with it. Any pointers? Cheers, Chuck - 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]
Cannot get plugin variable values
Hi,
I am having some trouble getting variable values from a plugin context. From one
plugin, the
following expression retrieves the expected value:
${pom.getPluginContext('maven-javadoc-plugin').getVariable('maven.javadoc.destdir')
However, from another plugin, this expression returns no value. How can this happen?
Also, this
expression returns no value when placed within my maven.xml file. Should I be able to
use this
type of expression in maven.xml?
Cheers,
Chuck
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: How to ask Maven to use jars from local drive ?
1. Is local repository in which you are placing your jars the location that maven
expects?
(maven.repo.local=${user.home}/.maven/repository)?
2. Are you placing your jars in the correct location within the repository?
(${maven.repo.local}/groupId/jars/artifactId-version.jar)?
3. Have you named your jars correctly (as indicated above -- artifactId-version.jar)?
--- [EMAIL PROTECTED] wrote:
I have them all in local repository, but it still tries to download.. :-( ??
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, March 05, 2004 10:11 AM
To: Maven Users List
Subject: Re: How to ask Maven to use jars from local drive ?
Put them in your local repository.
--
dIon Gillard, Multitask Consulting
[EMAIL PROTECTED] wrote on 05/03/2004 03:20:19 PM:
Hi all,
I just started using Maven, I have all the required jars in local
drive, how do I ask maven to use them from my drive and not to download
?
Thanks,
Chaithanya
Confidentiality Notice
The information contained in this electronic message and any
attachments to this message are intended
for the exclusive use of the addressee(s) and may contain
confidential or privileged information. If
you are not the intended recipient, please notify the sender at
Wipro or [EMAIL PROTECTED] immediately
and destroy all copies of this message and any attachments.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Confidentiality Notice
The information contained in this electronic message and any attachments to this
message are
intended
for the exclusive use of the addressee(s) and may contain confidential or privileged
information. If
you are not the intended recipient, please notify the sender at Wipro or [EMAIL
PROTECTED]
immediately
and destroy all copies of this message and any attachments.
-
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]
[checkstyle plugin] Custom checks not found
From previous postings, I see that earlier versions of the checkstyle plugin did not support the use of custom checks. I have version 2.1 of the plugin and I can see that plugin.jelly has been corrected to include a path reference to maven.dependency.classpath in the checkstyle task. However, I am encountering the problem that this correction is supposed to fix. I have placed a jar file with a custom check in my dependency list (in my projects project.xml file), but the plugin fails with a message indicating that it cannot instantiate my custom check. I am using rc-1. I have placed an echo call in the plugin.jelly file to verify that it is indeed using the correct plugin, echoing the dependency path to my jar file, which is indicating the correct location of my jar file in my local repository. What can I do to debug this problem? Cheers, Chuck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[javadoc plugin] Attempts to resolve URLs for offlineLinks
I have set maven.javadoc.mode.online=false in my project.properties file and have included a value for maven.javadoc.offlineLinks in the form url#packageListLoc, but the javadoc plugin still attempts to resolve the URL, causing my build to fail when I am offline. Aren't these property setting supposed to allow the javadoc plugin to succeed when offline by not attempting to go online? Am I missing something? Cheers, Chuck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [checkstyle plugin] Custom checks not found
Jason, Thanks for the quick response. I will certainly use your suggestion to get me going for now. Hopefully someone can explain what I may be doing wrong such that the 2.1 fix doesn't work for me. Thanks again, Chuck --- Morris, Jason [IT] [EMAIL PROTECTED] wrote: Charles, I rectified this previously by hacking the project.xml *in the checkstyle plugin* (i.e. plugins/maven-checkstyle-plugin-2.0-SNAPSHOT/project.xml, not your project file): dependency idmychecks/id version1.0/version properties classloaderroot/classloader /properties /dependency This forces the plugin to add mychecks-1.0.jar to the classpath. You then install your jar file in the repository/mychecks/jar directory which is where it will look for it. Not ideal but I'm not sure about the 2.1 fix which sounds like a better solution, but that should get you going. Jason -Original Message- From: Charles Daniels [mailto:[EMAIL PROTECTED] Sent: 04 March 2004 08:20 To: [EMAIL PROTECTED] Subject: [checkstyle plugin] Custom checks not found From previous postings, I see that earlier versions of the checkstyle plugin did not support the use of custom checks. I have version 2.1 of the plugin and I can see that plugin.jelly has been corrected to include a path reference to maven.dependency.classpath in the checkstyle task. However, I am encountering the problem that this correction is supposed to fix. I have placed a jar file with a custom check in my dependency list (in my projects project.xml file), but the plugin fails with a message indicating that it cannot instantiate my custom check. I am using rc-1. I have placed an echo call in the plugin.jelly file to verify that it is indeed using the correct plugin, echoing the dependency path to my jar file, which is indicating the correct location of my jar file in my local repository. What can I do to debug this problem? Cheers, Chuck - 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]
[xdoc plugin] Project reports not generated
I have just downloaded and installed xdoc plugin 1.5 using the plugin:download goal. Now when I attain the site goal, none of my project reports are generated. I was previously using version 1.4 of the plugin, which generated the reports without any problem. I decided to upgrade to version 1.5 for the new style, but now I get this odd output (instead of generated reports). Any ideas? Cheers, Chuck = OUTPUT FROM MAVEN'S SITE GOAL WITH XDOC PLUGIN 1.5 site: xdoc:register-reports: maven-checkstyle-plugin:register: maven:pluginVar var=reports plugin=maven-xdoc-plugin property=reports/maven:pluginVar maven-javadoc-plugin:register: maven:pluginVar var=reports plugin=maven-xdoc-plugin property=reports/maven:pluginVarmave n:pluginVar var=reports plugin=maven-xdoc-plugin property=reports/maven:pluginVar maven-jxr-plugin:register: maven:pluginVar var=reports plugin=maven-xdoc-plugin property=reports/maven:pluginVar site:run-reports: maven:pluginVar var=reports plugin=maven-xdoc-plugin property=reports/maven:pluginVar xdoc:init: xdoc:register-reports: maven-checkstyle-plugin:register: maven:pluginVar var=reports plugin=maven-xdoc-plugin property=reports/maven:pluginVar maven-javadoc-plugin:register: maven:pluginVar var=reports plugin=maven-xdoc-plugin property=reports/maven:pluginVarmave n:pluginVar var=reports plugin=maven-xdoc-plugin property=reports/maven:pluginVar maven-jxr-plugin:register: maven:pluginVar var=reports plugin=maven-xdoc-plugin property=reports/maven:pluginVar xdoc:generate-from-pom: [echo] Generating xdocs from POM ... maven:pluginVar var=reports plugin=maven-xdoc-plugin property=reports/maven:pluginVar xdoc:transform: xdoc:init: xdoc:copy-resources: [copy] Copying 3 files to D:\apps\eclipse\workspace\bmx-logging\target\docs\style [copy] Copying 89 files to D:\apps\eclipse\workspace\bmx-logging\target\docs\images About to use JSL stylesheet file:/d:/profiles/cdaniels/.maven/plugins/maven-xdoc-plugin-1.5/plugin-r esources/site.jsl xdoc:init: xdoc:copy-user-resources: xdoc:init: xdoc:jelly-init: xdoc:register-reports: maven-checkstyle-plugin:register: maven:pluginVar var=reports plugin=maven-xdoc-plugin property=reports/maven:pluginVar maven-javadoc-plugin:register: maven:pluginVar var=reports plugin=maven-xdoc-plugin property=reports/maven:pluginVarmave n:pluginVar var=reports plugin=maven-xdoc-plugin property=reports/maven:pluginVar maven-jxr-plugin:register: maven:pluginVar var=reports plugin=maven-xdoc-plugin property=reports/maven:pluginVar xdoc:jelly-transform: maven:pluginVar var=reports plugin=maven-xdoc-plugin property=reports/maven:pluginVar [ echo] Generating D:/apps/eclipse/workspace/bmx-logging/target/docs/changelog-report.html from D:\app s\eclipse\workspace\bmx-logging\target\generated-xdocs\changelog-report.xml [echo] Generating D:/apps/eclipse/workspace/bmx-logging/target/docs/checkstyle-report.html from D:\apps\eclipse\workspace\bmx-logging\target\generated-xdocs\checkstyle-report.xml [echo] Generating D:/apps/eclipse/workspace/bmx-logging/target/docs/cvs-usage.html from D:\apps\ eclipse\workspace\bmx-logging\target\generated-xdocs\cvs-usage.xml [echo] Generating D:/apps/eclipse/workspace/bmx-logging/target/docs/dependencies.html from D:\ap ps\eclipse\workspace\bmx-logging\target\generated-xdocs\dependencies.xml [echo] Generating D:/apps/eclipse/workspace/bmx-logging/target/docs/index.html from D:\apps\ecli pse\workspace\bmx-logging\target\generated-xdocs\index.xml [echo] Generating D:/apps/eclipse/workspace/bmx-logging/target/docs/issue-tracking.html from D:\ apps\eclipse\workspace\bmx-logging\target\generated-xdocs\issue-tracking.xml [echo] Generating D:/apps/eclipse/workspace/bmx-logging/target/docs/javadoc.html from D:\apps\ec lipse\workspace\bmx-logging\target\generated-xdocs\javadoc.xml [echo] Generating D:/apps/eclipse/workspace/bmx-logging/target/docs/jdepend-report.html from D:\ apps\eclipse\workspace\bmx-logging\target\generated-xdocs\jdepend-report.xml [echo] Generating D:/apps/eclipse/workspace/bmx-logging/target/docs/mail-lists.html from D:\apps \eclipse\workspace\bmx-logging\target\generated-xdocs\mail-lists.xml [echo] Generating D:/apps/eclipse/workspace/bmx-logging/target/docs/maven-reports.html from D:\a pps\eclipse\workspace\bmx-logging\target\generated-xdocs\maven-reports.xml [echo] Generating D:/apps/eclipse/workspace/bmx-logging/target/docs/project-info.html from D:\ap ps\eclipse\workspace\bmx-logging\target\generated-xdocs\project-info.xml [echo] Generating D:/apps/eclipse/workspace/bmx-logging/target/docs/team-list.html from D:\apps\ eclipse\workspace\bmx-logging\target\generated-xdocs\team-list.xml Transforming user supplied documentation. maven:pluginVar var=reports plugin=maven-xdoc-plugin property=reports/maven:pluginVar [ echo] Generating D:/apps/eclipse/workspace/bmx-logging/target/docs/index.html from D:\apps\eclipse\w
RE: [xdoc plugin] Project reports not generated
Thank you! I'll give this a try.
--- Marcin Werla [EMAIL PROTECTED] wrote:
Hi,
Message:
maven:pluginVar var=reports plugin=maven-xdoc-plugin
property=reports/maven:pluginVar
means that tag maven:pluginVar was not executed but just written on screen.
I think that his will work with New maven.jar file. But for now insted of
building New maven.jar I've just replaced all
maven:pluginVar var=some-variable plugin=some-plugin
property=some-plugin-property/maven:pluginVar
with
j:set var=some-variable
value=${pom.getPluginContext(some-plugin').getVariable('some-plugin-property'
)}/
In plugin.jelly file for xdoc plugin (and not only his plugin). So for this:
maven:pluginVar var=reports plugin=maven-xdoc-plugin
property=reports/maven:pluginVar
I've written:
j:set
var=reports
value=${pom.getPluginContext('maven-xdoc-plugin').getVariable('reports')}/
--
Greetings,
Marcin Werlamailto:[EMAIL PROTECTED]
http://www.man.poznan.pl/~mwerla/
ATTACHMENT part 2 application/x-pkcs7-signature name=smime.p7s
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Unit testing question
This sounds more like a problem with the way you have implemented your unit tests, not a problem with Maven. Can you provide more details on how you have written your test classes? --- Marco Tedone [EMAIL PROTECTED] wrote: Hi, I build my projects using maven. Maven executes automatically junit tests. I've got more than one test. Both of those tests use the services offered by a class, which I've implemented as a Singleton. The class is created after each test class has completed, thus my singleton is like as it doesn't exist. Is there a solution to this problem? Marco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javadoc plugin: overview capability
--- Stephen Colebourne [EMAIL PROTECTED] wrote: From: Charles Daniels [EMAIL PROTECTED] However, as I posted in a message just a couple of days ago, the javadocs do not appear to be generated correctly. Although the overview file is picked up correctly (and its contents appear within the generated javadocs), the package listing is missing. The packages are neither displayed within the usual summary table along with the overview contents, nor are they listed in the usual frame at the lower left (in the frames view). Anyone having the same problem? Yeh. I had this one yesterday. I switched to JDK1.4 and it went away. Stephen Hmmm. Unfortunately, I must stick to using 1.3 for this project. Anybody know how to correct this problem for JDK 1.3? Cheers, Chuck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javadoc plugin: overview capability
Hi Glenn,
--- Glenn R. Golden [EMAIL PROTECTED] wrote:
It appears that the javadoc plugin does not support the overview
capability.
Actually it does support the overview capability. See below.
By adding this line:
overview=${maven.javadoc.overviewfile}
to the plugin.jelly at the end of the
ant:javadoc
This is unnecessary. If you search a little further down for overview within
plugin.jelly, you
should find the following:
j:if test=${context.getVariable('maven.javadoc.overview') != null}
ant:setProperty name=overview value=${maven.javadoc.overview} /
/j:if
tag, and adding this to my ~/build.properties:
maven.javadoc.overviewfile = src/java/overview.html
As shown above, the recognized variable is maven.javadoc.overview, not
maven.javadoc.overviewfile.
it now does.
I wonder if I'm missing some other existing way to include overview
files in the javadocs, and if not, can this be added to the plugin?
Yes, you were missing something :-)
However, as I posted in a message just a couple of days ago, the javadocs do not
appear to be
generated correctly. Although the overview file is picked up correctly (and its
contents appear
within the generated javadocs), the package listing is missing. The packages are
neither
displayed within the usual summary table along with the overview contents, nor are
they listed in
the usual frame at the lower left (in the frames view).
Anyone having the same problem?
Thanks.
- Glenn
-- Chuck
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: local file system repository problem
Which operating system are you using? --- Maarten Coene [EMAIL PROTECTED] wrote: Hi, I'm having troubles updating sources from CVS using local file system repositories. I have defined my repository like this in the project.xml file: repository connectionscm:cvs:local:ignored:/home/cvs:reporting/connection urlhttp://192.168.1.1/cgi-bin/cvsweb.cgi/reporting//url /repository But, when I try to update my project, I get an error about a bad CVSROOT (see below). What am I doing wrong ? I'm using the CVS version of maven (version of 30 Jan 2004). thanks, Maarten scm:update-project scm:cvs-update-project [cvs] Using cvs passfile: /home/cruise/.cvspass [cvs] cvs update: Unknown method (`/home/cvs') in CVSROOT. [cvs] cvs [update aborted]: Bad CVSROOT: `:/home/cvs:reporting:'. BUILD FAILED File.. file:/home/cruise/.maven/plugins/maven-scm-plugin-1.2-SNAPSHOT/ Element... ant:cvs Line.. 199 Column 9 cvs exited with error code 1 Command line was [Executing 'cvs' with arguments '-d:/home/cvs:reporting:' '-q' 'update' '-Pd' The ' characters around the executable and arguments are not part of the command. - 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]
