Re: mvn test phase out of memery issue
I believe that the parameters like heap size is only read at JVM initalizing phase. I guess one cannot change the heap size at run time. This prevents JVM from using up all of system's memories. -Xmx1050m -XX:MaxPermSize=128M is obviously ONLY for the forked JVM related spawned for surefire plugin. Jack On Fri, Oct 3, 2008 at 5:14 PM, Martin Gainty <[EMAIL PROTECTED]> wrote: > > Good Evening Zhou- > fairly intuitive to see the new params acting as an initial configuration > for forked jvm's > > but admittedly cannot see how the jvm parameters such as what is identified > here > -Xmx1050m -XX:MaxPermSize=128Mbeing used in the current > VM > > would be used to 'reconfigure' the current jvm process > > perhaps a JVM resource can elucidate > ? > Martin Gainty > __ > Disclaimer and confidentiality note > Everything in this e-mail and any attachments relates to the official > business of Sender. This transmission is of a confidential nature and Sender > does not endorse distribution to any party other than intended recipient. > Sender does not necessarily endorse content contained within this > transmission. > > > > Date: Fri, 3 Oct 2008 17:05:15 -0700 > > From: [EMAIL PROTECTED] > > To: users@maven.apache.org > > Subject: Re: mvn test phase out of memery issue > > > > Thanks, > > I will try that. Currently I am trying always. It > > works. But very very slow. We have over a thousand tests. > > Regards, > > Jack > > > > On Fri, Oct 3, 2008 at 4:15 PM, Matthew McCullough < > > [EMAIL PROTECTED]> wrote: > > > > > > > > You may need to increase the memory used by the surefire jvm if it is > set > > > to > > > fork. > > > > > > Here's a config example: > > > > > > > > >org.apache.maven.plugins > > >maven-surefire-plugin > > >2.3 > > > > > > > > >**/*Test.java > > > > > >once > > > > > >-Xmx1050m -XX:MaxPermSize=128M > > > > > > > > > > > > > > > > > > Jinyuan Zhou-3 wrote: > > > > > > > > Hello, > > > > When I run a test, (mvn test) out of memory happens when run one of > the > > > > unit > > > > test case methed : > > > > java.lang.OutOfMemoryError: Java heap space > > > > > > > > > > > > I did put the following . > > > > > > > > MAVEN_OPTS=-Xmx512m > > > > > > > > Can some one give a clue as which plugin is used in test phase, and > what > > > > option can be used to increase the heap size when running test? > > > > Thanks, > > > > Jack > > > > > > > > > > > > > > -- > > > View this message in context: > > > > http://www.nabble.com/mvn-test-phase-out-of-memery-issue-tp19805700p19807236.html > > > Sent from the Maven - Users mailing list archive at Nabble.com. > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > > > Some people lived like they will never die > > and died like they have never lived > > _ > Want to do more with Windows Live? Learn "10 hidden secrets" from Jamie. > > http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns!550F681DAD532637!5295.entry?ocid=TXT_TAGLM_WL_domore_092008 -- Some people lived like they will never die and died like they have never lived
maven filtering component usage
Hello all,
I am current using maven-filtering-beta-1 & 2 to interpolate
@{variable} so here is the codesnip
// support @{} izpack ant format
mavenResourcesExecution.addFilerWrapper( new MavenProjectValueSource(
project, true ), "\\@", "(.+?)\\}", "@{", "}" );
The real source is at
http://svn.codehaus.org/izpack/izpack-maven/trunk/izpack-maven-plugin/src/main/java/org/izpack/mojo/IzPackMojo.java
at interpolateDescriptorFile()
The test case is at
http://svn.codehaus.org/izpack/izpack-maven/trunk/izpack-maven-plugin/src/it/izpack-172/
The file i am trying to interpolate is under src/izpack/install.xml
can someone give it a quick scan to see if I manage to use the API correctly.?
Full appreciate the helps
Thanks
-D
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Version conflict resolution and stable builds
I've been spending some time trying to get my head around the way version resolution works in 2.0.9. I'm trying to get a sense for the best way to use maven to achieve our objectives: 1. Builds on our CI server that were working should not break unless someone commits a change - in particular new versions of dependencies should not be introduced to the build without a change to the pom. (I'm actually more concerned about changes that don't break the build on CI but cause runtime errors on our production web site due to some edge case that was insufficiently covered with automated tests.) 2. We really don't want to have to restate the versions of every dependency in all local pom files. We like "dry". I've looked at the version ranges but am a little concerned about them for a couple of reasons: 1. Closed ranges like [1.2,1.4] means modules need to be re-tested and re-released with a new range if a dependency changes and any application using the module needs the newer version of the dependency, say 1.5, even if only transitively. With the hundreds of modules we have, this would be a time-consuming task. Besides, very few 3rd party modules seem to use ranges. 2. Open ranges like [1.2,) seem to imply a guarantee of compatibility with ALL future releases. (And if all dependency declarations for a module A are open ranges then the version of A that is actually included can change over time as maven pulls in the latest one from the repo - leading to temporally inconsistent builds) I studied MNG-612 which seems like it goes a little way towards addressing our issue, but the status of that ticket is unclear as it's pretty old and none of the code has been merged back. Any info welcome. (The MNG-612 branch looks like it introduced a bug into the scope resolving code too as it swaps nearest and farthest under some circumstances - and it is not clear to me that it would work with ranges.) I think what *we* would want would be the following rules for version conflict resolution... If a suggested version is specified in the local pom use it. Treat it as override for transitives, unless any transitive specifies a range that is not satisfied by the suggestion - in which case resolution should fail. Else If any ranges are used select the oldest version that satisfies all the ranges. Else use the newest suggested version. The scope rules would need to stay as they are in 2.0.9 My questions: 1. Can anyone please tell me of a way to achieve this with 2.0.9 today? 2. Can 2.1 do this yet? Or is support for this functionality planned for any 2.1 milestone? 3. Can anyone point me to discussions/documents describing what direction the maven developers are planning for version conflict resolution in the future? If this is not in the works and we could contribute to maven to help make this happen we would be willing to do so. Thanks, Keith. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mvn test phase out of memery issue
Good Evening Zhou- fairly intuitive to see the new params acting as an initial configuration for forked jvm's but admittedly cannot see how the jvm parameters such as what is identified here -Xmx1050m -XX:MaxPermSize=128Mbeing used in the current VM would be used to 'reconfigure' the current jvm process perhaps a JVM resource can elucidate ? Martin Gainty __ Disclaimer and confidentiality note Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. > Date: Fri, 3 Oct 2008 17:05:15 -0700 > From: [EMAIL PROTECTED] > To: users@maven.apache.org > Subject: Re: mvn test phase out of memery issue > > Thanks, > I will try that. Currently I am trying always. It > works. But very very slow. We have over a thousand tests. > Regards, > Jack > > On Fri, Oct 3, 2008 at 4:15 PM, Matthew McCullough < > [EMAIL PROTECTED]> wrote: > > > > > You may need to increase the memory used by the surefire jvm if it is set > > to > > fork. > > > > Here's a config example: > > > > > >org.apache.maven.plugins > >maven-surefire-plugin > >2.3 > > > > > >**/*Test.java > > > >once > > > >-Xmx1050m -XX:MaxPermSize=128M > > > > > > > > > > > > Jinyuan Zhou-3 wrote: > > > > > > Hello, > > > When I run a test, (mvn test) out of memory happens when run one of the > > > unit > > > test case methed : > > > java.lang.OutOfMemoryError: Java heap space > > > > > > > > > I did put the following . > > > > > > MAVEN_OPTS=-Xmx512m > > > > > > Can some one give a clue as which plugin is used in test phase, and what > > > option can be used to increase the heap size when running test? > > > Thanks, > > > Jack > > > > > > > > > > -- > > View this message in context: > > http://www.nabble.com/mvn-test-phase-out-of-memery-issue-tp19805700p19807236.html > > Sent from the Maven - Users mailing list archive at Nabble.com. > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > > Some people lived like they will never die > and died like they have never lived _ Want to do more with Windows Live? Learn “10 hidden secrets” from Jamie. http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns!550F681DAD532637!5295.entry?ocid=TXT_TAGLM_WL_domore_092008
Re: AW: Release fails during SVN commit
I've discovered one solution that worked for me. I don't know if I have a different problem than was mentioned here, but it was the same error. I did have the same issues mentioned in this thread and tried all sorts of subversion client's. Try fixing the scm configuration first to point to the correct location in your svn. I kept getting this error until i've resolved that first. Also, this assumes that you have a typical SVN structure: with trunk, branches and tags in the same folder. If you don't have a typical layout, then maven-release-plugin's configuration will have to be modified and a tagBase specified. Example: scm:svn:svn+ssh://[EMAIL PROTECTED]/local/project/svn/devrepo/project/trunk scm:svn:svn+ssh://[EMAIL PROTECTED]/local/project/svn/devrepo/project/trunk http://svn.repository.com maven-release-plugin BTW, currently i'm running the latest subversion client (1.5.2) doballve wrote: > > I'm forced to go with 1.5.1 right now, so here is a workaround that worked > for me (on gentoo): > > * Checkout a working copy with svn client 1.5.1, otherwise svn copy fails > with file already exists > * run mvn release:prepare, it will fail in the svn --non-interactive copy > ... > * run svn update > * run svn copy manually, do not use --non-interactive, and you'll have to > provide a message > * edit release.properties, advance the completed phase > - completedPhase=scm-commit-release >+ completedPhase=scm-tag > * run mvn release:prepare to continue the release > * proceed normally with release:perform and so on.. > > If anybody has the proper solution for this issue, I'd be glad to know it. > > Thanks, > Diego > -- View this message in context: http://www.nabble.com/Release-fails-during-SVN-commit-tp19084270p19807745.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mvn test phase out of memery issue
Thanks, I will try that. Currently I am trying always. It works. But very very slow. We have over a thousand tests. Regards, Jack On Fri, Oct 3, 2008 at 4:15 PM, Matthew McCullough < [EMAIL PROTECTED]> wrote: > > You may need to increase the memory used by the surefire jvm if it is set > to > fork. > > Here's a config example: > > >org.apache.maven.plugins >maven-surefire-plugin >2.3 > > >**/*Test.java > >once > >-Xmx1050m -XX:MaxPermSize=128M > > > > > > Jinyuan Zhou-3 wrote: > > > > Hello, > > When I run a test, (mvn test) out of memory happens when run one of the > > unit > > test case methed : > > java.lang.OutOfMemoryError: Java heap space > > > > > > I did put the following . > > > > MAVEN_OPTS=-Xmx512m > > > > Can some one give a clue as which plugin is used in test phase, and what > > option can be used to increase the heap size when running test? > > Thanks, > > Jack > > > > > > -- > View this message in context: > http://www.nabble.com/mvn-test-phase-out-of-memery-issue-tp19805700p19807236.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Some people lived like they will never die and died like they have never lived
Re: Migrating non-maven project. Adding dependencies
In short, no. Wayne On Fri, Oct 3, 2008 at 4:25 PM, emma.sender <[EMAIL PROTECTED]> wrote: > > Hi, I'm trying to migrate a project to maven that has all the .jars in a lib > folder relative to the project root folder, and I don't want to have to > specify every .jar in a element... Is there a way to include > lib/*.jar in the classpath? > -- > View this message in context: > http://www.nabble.com/Migrating-non-maven-project.-Adding-dependencies-tp19807322p19807322.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Migrating project to Maven. Adding dependencies.
Hi, I'm trying to migrate a project to maven that has all the .jars in a lib folder relative to the project root folder, and I don't want to have to specify every .jar in a element... Is there a way to include lib/*.jar in the classpath? -- View this message in context: http://www.nabble.com/Migrating-project-to-Maven.-Adding-dependencies.-tp19807326p19807326.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Migrating non-maven project. Adding dependencies
Hi, I'm trying to migrate a project to maven that has all the .jars in a lib folder relative to the project root folder, and I don't want to have to specify every .jar in a element... Is there a way to include lib/*.jar in the classpath? -- View this message in context: http://www.nabble.com/Migrating-non-maven-project.-Adding-dependencies-tp19807322p19807322.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mysterious assembly-plugin
Try filling in a bit more in your xml file.
Also use the information at
http://maven.apache.org/plugins/maven-assembly-plugin/usage.html and go down
to the example below the heading "Normal Assemblies" to see how the pom
should look.
Your parts should look like this:
src/main/properties/development
dev
*.properties
*.xml
is where in your maven project you are getting the files. If you
put a dot only, it will use the ${basedir} the same folder where you
normally put your pom.
defines a folder in the generated zip, tar.gz, etc.
And you need the includes to specify some files that go into the generated
archive. You may want some excludes to tell it to get all but some files.
--Lee
On Thu, Oct 2, 2008 at 2:59 AM, <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have great problems to solve a simple requirement with Maven2. I have
> a Maven project with several sub-modules. Each submodule has its own
> config- and install files. I want to distribute and deploy these files
> together with its respective submodule artefact. The assembly-plugin
> seems to be appropriate for this task but as I made always the
> experience up to now with nearly every Maven functionality, it does not
> work as expected and documented and error messages are mysterious.
> Furthermore it is very hard to understand the different goals and
> parameters of assembly-plugin and from where does it count paths.
>
>
>
> I defined the plugin in my parent pom:
>
>
>
>
>
>maven-assembly-plugin
>
>
>
>
>
>assembly-descriptor.xml
>
>
>
>
>
>
>
>
>
>
>
>make-assembly
>
>package
>
>
>
> single
>
>
>
>
>
>
>
>
>
>
>
> I defined the descriptor:
>
>
>
>
>
> install
>
>
>
>zip
>
>
>
>
>
>
>
> src/main/install
>
>
>
>
>
>
>
>
>
>
>
> readme.txt
>
>
>
>
>
>
>
>
>
>
>
> I have modified these two in any possible way, I tried also goal
> attached but when I execute mvn install I always get the error: you must
> set at least one file.
>
>
>
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-1:single' with
> basic configurator -->
>
> [DEBUG] (s) appendAssemblyId = true
>
> [DEBUG] (f) attach = true
>
> [DEBUG] (s) basedir = D:\projekte\core
>
> [DEBUG] (s) descriptors = [Ljava.io.File;@1742c56
>
> [DEBUG] (s) filters = []
>
> [DEBUG] (s) finalName = core-0.0.2-SNAPSHOT
>
> [DEBUG] (s) includeSite = false
>
> [DEBUG] (s) localRepository = [local] ->
> file://D:\projekte\maven-repository
>
> [DEBUG] (s) outputDirectory = D:\projekte\core\target
>
> [DEBUG] (f) project = MavenProject: net.atos.wlp:core:0.0.2-SNAPSHOT @
> D:\projekte\core\pom.xml
>
> [DEBUG] (s) reactorProjects = [MavenProject:
> net.atos.wlp:plugin-setproperties:0.0.2 @
> D:\projekte\core\plugin-setproperties\pom.xml, MavenProject:
> net.atos.wlp:grandparent-pom:0.0.2 @
> D:\projekte\core\grandparent-pom\pom.xml, MavenProject:
> net.atos.wlp:core-install:0.0.2-SNAPSHOT @
> D:\projekte\core\install\pom.xml, MavenProject:
> net.atos.wlp:plugin-jbossinstall:0.0.2-SNAPSHOT @
> D:\projekte\core\plugin-jbossinstall\pom.xml, MavenProject:
> net.atos.wlp:core:0.0.2-SNAPSHOT @ D:\projekte\core\pom.xml,
> MavenProject: net.atos.wlp:core-database:0.0.2-SNAPSHOT @
> D:\projekte\core\database\product\pom.xml, MavenProject:
> net.atos.wlp:core-config:0.0.2-SNAPSHOT @
> D:\projekte\core\config\product\pom.xml, MavenProject:
> net.atos.wlp:core-template:0.0.2-SNAPSHOT @
> D:\projekte\core\template\pom.xml, MavenProject:
> net.atos.wlp:core-translation:0.0.2-SNAPSHOT @
> D:\projekte\core\translation\product\pom.xml, MavenProject:
> net.atos.wlp:plugin-translationimport:0.0.2-SNAPSHOT @
> D:\projekte\core\plugin-translationimport\pom.xml, MavenProject:
> net.atos.wlp:plugin-blobloader:0.0.2-SNAPSHOT @
> D:\projekte\core\plugin-blobloader\pom.xml, MavenProject:
> net.atos.wlp:parent-pom:0.0.2-SNAPSHOT @
> D:\projekte\core\parent-pom\pom.xml, MavenProject:
> net.atos.wlp:core-commonobjects:0.0.2-SNAPSHOT @
> D:\projekte\core\commonobjects\pom.xml, MavenProject:
> net.atos.wlp:core-log:0.0.2-SNAPSHOT @
> D:\projekte\core\log\product\pom.xml, MavenProject:
> net.atos.wlp:core-baselogservice:0.0.2-SNAPSHOT @
> D:\projekte\core\baselogservice\product\pom.xml, MavenProject:
> net.atos.wlp:core-logbean:0.0.2-SNAPSHOT @
> D:\projekte\core\logbean\product\pom.xml, MavenProject:
> net.atos.wlp:core-security:0.0.2-SNAPSHOT @
> D:\projekte\core\security\product\pom.xml, MavenProject:
> net.atos.wlp:core-batch:0.0.2-SNAPSHOT @ D:\projekte\core\batch\pom.xml,
> MavenProject: net.atos.wlp:core-messaging:0.0.2-SNAPSHOT @
> D:\projekte\core\messaging\product\pom.xml, MavenProject:
> net.atos.wlp:core-starterservlet:0.0.2-SNAPSHOT @
> D:\projekte\co
Re: How to aggregate License info
I think the following might get you on the right track, though they may not be precisely what you are seeking: 1) http://code.google.com/p/maven-license-plugin/ 2) http://mojo.codehaus.org/rat-maven-plugin/ -Matthew McCullough bshepherd wrote: > > I have a requirement to determine all dependencies used in our project and > determine what licenses are used. When I use the site:site/site:deploy > goals I can select the Dependencies link for reports and get a License > section that looks like the following: > > Licenses > SILENTWIRE License 1.0: Silentwire Common, Silentwire Dissector > BSD Style License: Trilead SSH for Java > Sun Microsystems, Inc. Binary Code License Agreement: JMX 1.2 > Reference Implementation, JMXTools 1.2.1, Java Message Service > Common Public License Version 1.0: JUnit > MIT License: SLF4J API Module, SLF4J LOG4J-12 Binding > The Apache Software License, Version 2.0: Apache Log4j, Apache MINA > Core, Codec, Collections, Commons BeanUtils, Commons IO, Commons > Logging, Lang > Common Development and Distribution License (CDDL) v1.0: JavaBeans > Activation Framework (JAF), JavaMail API > > > This is great, however, we have so many sub modules, that it takes quite a > bit of manual effort to look through all the modules, select the > dependency report and view/copy the License info. > > > Does anyone know how to aggregate all the dependencies with license info > during site creation, or is there a better way to find this information. > > Thanks > -- View this message in context: http://www.nabble.com/How-to-aggregate-License-info-tp19799759p19807277.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mvn test phase out of memery issue
You may need to increase the memory used by the surefire jvm if it is set to fork. Here's a config example: org.apache.maven.plugins maven-surefire-plugin 2.3 **/*Test.java once -Xmx1050m -XX:MaxPermSize=128M Jinyuan Zhou-3 wrote: > > Hello, > When I run a test, (mvn test) out of memory happens when run one of the > unit > test case methed : > java.lang.OutOfMemoryError: Java heap space > > > I did put the following . > > MAVEN_OPTS=-Xmx512m > > Can some one give a clue as which plugin is used in test phase, and what > option can be used to increase the heap size when running test? > Thanks, > Jack > > -- View this message in context: http://www.nabble.com/mvn-test-phase-out-of-memery-issue-tp19805700p19807236.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Assembly Tar: How to exclude directories
I'm curious if the Assembly plugin is capable of creating a tar file similar to the following command: find * ! -type d | tar zcvfT $TARFILE - if you exec 'tar ztvf myAssembly.tar.gz' you will see that directories are listed in the tar file. if you create a tar w/ the above command, you will notice that when you list the tar w/ 'tar ztvf myAssembly.tar.gz' you will just see files and the full path to that file. please note, i am not trying to exclude entire directories or to flatten the tar, but to not include the directories in the tar. please try out these commands w/ a sample if its confusing and you will see what i mean. thanks. -- View this message in context: http://www.nabble.com/Assembly-Tar%3A-How-to-exclude-directories-tp19806706p19806706.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mvn test phase out of memery issue
Hello, When I run a test, (mvn test) out of memory happens when run one of the unit test case methed : java.lang.OutOfMemoryError: Java heap space [INFO] [INFO] Total time: 1 minute 20 seconds [INFO] Finished at: Fri Oct 03 11:50:28 PDT 2008 [INFO] Final Memory: 11M/20M [INFO] I did put the following . MAVEN_OPTS=-Xmx512m Can some one give a clue as which plugin is used in test phase, and what option can be used to increase the heap size when running test? Thanks, Jack
Re: Dependency licenses
The reply from James @ Atlassian provided the SVN trunk url: https://svn.atlassian.com/svn/public/atlassian/maven-plugins/maven-licenses-plugin/trunk/ I haven't done it, but I imagine you can check out the code and build/install/use it pretty easily. Wayne On Fri, Oct 3, 2008 at 11:47 AM, bshepherd <[EMAIL PROTECTED]> wrote: > > I can follow the link in my browser, but how do you check out the code so I > can build it. It sounds exactly what I need. > Thanks > > > Keith Bonawitz-2 wrote: >> >> Is there a way to create an assembly that includes a license file for >> each dependency (including transitive dependencies)? >> >> Thanks, >> Keith >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > -- > View this message in context: > http://www.nabble.com/Dependency-licenses-tp17040644p19803517.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven ant tasks and the provided scope
i've managed to work around by hardcoding in the three or four provided scope
deps.
should i create a jira issue for this?
will vuong wrote:
>
> yes, i've tried changing it to use the runtime scope and it looks like
> everything in the runtime scope is copied to the directory.
>
>
>
> Brett Porter wrote:
>>
>> I don't believe so, since it assumes it to be provided.
>>
>> If you use "compile" instead of "provided", does it work? It is not
>> expected to be transitive, however.
>>
>> - Brett
>>
>> 2008/9/25 William Vuong <[EMAIL PROTECTED]>:
>>> I have something like this in my ant file and the maven ant tasks 2.0.9
>>> and
>>> ant 1.7 that loads a pom.xml file and creates a bunch of filesets:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>> pathId="provided.classpath" filesetId="provided.fileset"
>>> verbose="${maven.verbosity}" useScope="provided" />
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> And my pom file does have several dependencies with the provided scope:
>>>
>>>
>>>
>>>
>>>
>>> com.oracle
>>>
>>> ojdbc14
>>>
>>> 9.0.2.0.0
>>>
>>> provided
>>>
>>>
>>>
>>>
>>>
>>> So when I execute "ant wtf", none of the dependencies in the provided
>>> scope
>>> gets copied into that directory. The provided scope is supported by the
>>> maven ant tasks, right? Or am I doing something wrong?
>>>
>>>
>>>
>>> Thanks.
>>>
>>>
>>
>>
>>
>> --
>> Brett Porter
>> Blog: http://blogs.exist.com/bporter/
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/maven-ant-tasks-and-the-provided-scope-tp19662878p19804834.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependency licenses
I can follow the link in my browser, but how do you check out the code so I can build it. It sounds exactly what I need. Thanks Keith Bonawitz-2 wrote: > > Is there a way to create an assembly that includes a license file for > each dependency (including transitive dependencies)? > > Thanks, > Keith > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Dependency-licenses-tp17040644p19803517.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: exec:java arguments vs. commandLineArgs
Hi Trevor, documentation lacks a lot of explanations, but looking at the code it seems like : - If commandLineArgs is specified, it will be used as is, except for replacing %classpath with proper classpath using dependencies - Otherwise if the property exec.args is specified, it will be used - Otherwise the list of and will be parsed and used So, yes, they both (and the exec.args also) serve the same purpose, but commandLineArgs is taken more or less literaly, as well as exec.args, while the element offer a more "formal" way of specifying parameters and calculating classpaths. Hope this helps, Simone Trevor Harmon wrote: > In the exec:java goal, what is the difference between and > ? The documentation says: > > arguments: The class arguments > commandlineArgs: Arguments for the executed program > > The difference still isn't clear to me. > > Trevor > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Simone GianniCEO Semeru s.r.l. Apache Committer MALE human being programming a computer http://www.simonegianni.it/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to aggregate License info
I have a requirement to determine all dependencies used in our project and determine what licenses are used. When I use the site:site/site:deploy goals I can select the Dependencies link for reports and get a License section that looks like the following: Licenses SILENTWIRE License 1.0: Silentwire Common, Silentwire Dissector BSD Style License: Trilead SSH for Java Sun Microsystems, Inc. Binary Code License Agreement: JMX 1.2 Reference Implementation, JMXTools 1.2.1, Java Message Service Common Public License Version 1.0: JUnit MIT License: SLF4J API Module, SLF4J LOG4J-12 Binding The Apache Software License, Version 2.0: Apache Log4j, Apache MINA Core, Codec, Collections, Commons BeanUtils, Commons IO, Commons Logging, Lang Common Development and Distribution License (CDDL) v1.0: JavaBeans Activation Framework (JAF), JavaMail API This is great, however, we have so many sub modules, that it takes quite a bit of manual effort to look through all the modules, select the dependency report and view/copy the License info. Does anyone know how to aggregate all the dependencies with license info during site creation, or is there a better way to find this information. Thanks -- View this message in context: http://www.nabble.com/How-to-aggregate-License-info-tp19799759p19799759.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: scope-import and dependencyManagement
Nahhh much easier mvn -N install in the directory where your root pom is... that will restrict the build to the current pom only and not build the child modules 2008/10/3 webhiker <[EMAIL PROTECTED]>: > > OK, so that's not the issue I was trying to discuss then. > But for those who had the same problem as I did, I have a solution : > > if you have the following structure : > > pom.xml > child-project1\pom.xml > child-project2\pom.xml > > If you add in the depManagement to the root pom, the others will not work > (in my case anyway) because Maven downloads the root pom from your > repository (which in the initial case didn't have the depManagement > definitions) instead of looking at the version on disk. > So it's a chieck-egg problem - you can't deploy your new pom because it > won't build! > > Solution is to manually copy the modified root pom either to your remote > repository or to the local repo (USER_HOME\.m2 or whatever) > > cheers > > > Stephen Connolly-2 wrote: >> >> I think you are mis-interpreting what I said. >> >> You have the following structure >> >> /pom.xml (agregator) >> +suite/pom.xml (the suite dependencies) >> +client/pom.xml (the client thing we are building) >> +web/pom.xml (the web ting we are building) >> >> If you have only one corporate pom (not shown on the tree) then you >> can get away with everything ultimately inheriting from the corporate >> pom by having a parent tree like >> >> /pom.xml ---is-a-child-of---> /suite/pom.xml >> /client/pom.xml ---is-a-child-of---> /suite/pom.xml >> /web/pom.xml ---is-a-child-of---> /suite/pom.xml >> /suite/pom.xml ---is-a-child-of---> corporate-pom.xml >> >> And you'd put your dependencyManagement in /suite/pom.xml >> >> The question is why have this import >> >> The reason is you may have corporate standards for different >> packagings... and they may not work in the one pom.xml >> >> In that case you would have >> >> corporate-root-pom.xml >> corporate-jar-pom.xml ---is-a-child-of---> corporate-root-pom.xml >> corporate-war-pom.xml ---is-a-child-of---> corporate-root-pom.xml >> >> And then >> /pom.xml ---is-a-child-of---> corporate-aggregator-pom.xml >> /client/pom.xml ---is-a-child-of---> corporate-jar-pom.xml >> /web/pom.xml ---is-a-child-of---> corporate-war-pom.xml >> >> Now the problem is how do I ensure that client and web have the same >> dependencyMangement sections? >> >> The answer is import scope so in that case you have >> >> /suite/pom.xml ---is-a-child-of---> corporate-root-pom.xml >> /client/pom.xml ---is-a-child-of---> corporate-jar-pom.xml with >> dependency on /suite/pom.xml: scope=import >> /web/pom.xml ---is-a-child-of---> corporate-war-pom.xml with >> dependency on /suite/pom.xml: scope=import >> >> I was explaining *why* you would want import scope. I don't know *if* >> import scope works... only *why* one would want it in the first place >> >> - Stephen >> >> >> 2008/10/3 webhiker <[EMAIL PROTECTED]>: >>> >>> Stephen, I don't think you are correct, it IS supposed to be used that >>> way, >>> and that's what all the Maven documentation lists as examples and >>> operating >>> behaviour : >>> >>> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html >>> >>> I'm having the exact same issue. Using identical examples to the Maven >>> docs, >>> if I omit the version tag in the child pom, the build always fails with >>> "missing version tag" error. >>> >>> There appears to be something wrong with the code. I'm running Maven >>> 2.0.9 >>> >>> >>> Stephen Connolly-2 wrote: Each project can list _only the dependencies that it has_ while using the import to ensure that only a single suite of dependency versions are used, I would guess. It's to separate inheritance from dependency management On Tue, Sep 16, 2008 at 4:25 PM, Barry Kaplan <[EMAIL PROTECTED]> wrote: > > What is the value of importing into dependencyManagement if those > dependencies cannot then be refered to in the regular dependencies? I'm > missing the purpose/value. > -- > View this message in context: > http://www.nabble.com/scope-import-and-dependencyManagement-tp19512161p19514217.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/scope-import-and-dependencyManagement-tp19512161p19795461.html >>> Sent from the Maven - Users mailing list archive at Nabble.com. >>> >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> - >>
Dependencies without version tag
I would like to add a dependency to my maven project but have it included WITHOUT the version tag. I am currently running into problems where the comm.jar (javax.comm) library needs to be exactly named that way and cannot be named comm-2.0.3.jar or some other thing because otherwise it fails. This library references a .dll and a properties file... this must have something to do with it. That is why I don't want my project to depend on a library with a version number. This means that my classpath entry autogenerated must also reference jars without version tag. Is there a way to strip the version tag from a dependency so that it will be reflected in the classpath entry of the jar's manifest? Thanks. Simon P.S.: Any maven help in dealing with the comm.jar library is also welcomed! :.)
Re: scope-import and dependencyManagement
OK, so that's not the issue I was trying to discuss then. But for those who had the same problem as I did, I have a solution : if you have the following structure : pom.xml child-project1\pom.xml child-project2\pom.xml If you add in the depManagement to the root pom, the others will not work (in my case anyway) because Maven downloads the root pom from your repository (which in the initial case didn't have the depManagement definitions) instead of looking at the version on disk. So it's a chieck-egg problem - you can't deploy your new pom because it won't build! Solution is to manually copy the modified root pom either to your remote repository or to the local repo (USER_HOME\.m2 or whatever) cheers Stephen Connolly-2 wrote: > > I think you are mis-interpreting what I said. > > You have the following structure > > /pom.xml (agregator) > +suite/pom.xml (the suite dependencies) > +client/pom.xml (the client thing we are building) > +web/pom.xml (the web ting we are building) > > If you have only one corporate pom (not shown on the tree) then you > can get away with everything ultimately inheriting from the corporate > pom by having a parent tree like > > /pom.xml ---is-a-child-of---> /suite/pom.xml > /client/pom.xml ---is-a-child-of---> /suite/pom.xml > /web/pom.xml ---is-a-child-of---> /suite/pom.xml > /suite/pom.xml ---is-a-child-of---> corporate-pom.xml > > And you'd put your dependencyManagement in /suite/pom.xml > > The question is why have this import > > The reason is you may have corporate standards for different > packagings... and they may not work in the one pom.xml > > In that case you would have > > corporate-root-pom.xml > corporate-jar-pom.xml ---is-a-child-of---> corporate-root-pom.xml > corporate-war-pom.xml ---is-a-child-of---> corporate-root-pom.xml > > And then > /pom.xml ---is-a-child-of---> corporate-aggregator-pom.xml > /client/pom.xml ---is-a-child-of---> corporate-jar-pom.xml > /web/pom.xml ---is-a-child-of---> corporate-war-pom.xml > > Now the problem is how do I ensure that client and web have the same > dependencyMangement sections? > > The answer is import scope so in that case you have > > /suite/pom.xml ---is-a-child-of---> corporate-root-pom.xml > /client/pom.xml ---is-a-child-of---> corporate-jar-pom.xml with > dependency on /suite/pom.xml: scope=import > /web/pom.xml ---is-a-child-of---> corporate-war-pom.xml with > dependency on /suite/pom.xml: scope=import > > I was explaining *why* you would want import scope. I don't know *if* > import scope works... only *why* one would want it in the first place > > - Stephen > > > 2008/10/3 webhiker <[EMAIL PROTECTED]>: >> >> Stephen, I don't think you are correct, it IS supposed to be used that >> way, >> and that's what all the Maven documentation lists as examples and >> operating >> behaviour : >> >> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html >> >> I'm having the exact same issue. Using identical examples to the Maven >> docs, >> if I omit the version tag in the child pom, the build always fails with >> "missing version tag" error. >> >> There appears to be something wrong with the code. I'm running Maven >> 2.0.9 >> >> >> Stephen Connolly-2 wrote: >>> >>> Each project can list _only the dependencies that it has_ while using >>> the >>> import to ensure that only a single suite of dependency versions are >>> used, >>> I >>> would guess. >>> >>> It's to separate inheritance from dependency management >>> >>> On Tue, Sep 16, 2008 at 4:25 PM, Barry Kaplan <[EMAIL PROTECTED]> >>> wrote: >>> What is the value of importing into dependencyManagement if those dependencies cannot then be refered to in the regular dependencies? I'm missing the purpose/value. -- View this message in context: http://www.nabble.com/scope-import-and-dependencyManagement-tp19512161p19514217.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> -- >> View this message in context: >> http://www.nabble.com/scope-import-and-dependencyManagement-tp19512161p19795461.html >> Sent from the Maven - Users mailing list archive at Nabble.com. >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/scope-import-and-dependencyManagement-tp19512161p19798389.html Sent from the Maven - Users mailing list archive at Nabble.com. -
Re: Determining jar groupId ArtifactId for deploy-file
Thanks Stephen for explaining! Makes lots of sense!!! Sonia Stephen Connolly-2 wrote: > > you are working for ericsson... so com.ericsson.what.ever.you.want > > Or if you are working on a project hosted on dev.java.net you'd use > net.java.dev.projectname > > It's just like package names in java... there are no hard and fast > rules... but if you ever want to interact with the public > repositories, you'd want to ensure that the group Id you are using is > not used by anyone else... > > For example, if you publish to your internal repo using com.sun... and > then sun publish to repo1 an artifact with the same groupId and > artifactId but a newer version, it may interfere with your build as > that newer version will bee seen in version ranges > > If they deploy something with the same version, and your developers > accidentally get that one on their machein first you'll have all sorts > of trouble. > > So the recommendation is to use a group ID that you control (in this > case by you, we mean your employers) > > -Stephen > > 2008/10/2 solo1970 <[EMAIL PROTECTED]>: >> >> What does that mean exactly??? >> >> >> Stephen Connolly-2 wrote: >>> >>> yes, but it's best to use a group Id that you control >>> >>> Sent from my iPod >>> >>> On 2 Oct 2008, at 19:48, solo1970 <[EMAIL PROTECTED]> >>> wrote: >>> Ok, so if understand this correctly I can give it any groupId ArtifctId that I choose regardless of the file name. Once deployed with those coordinates, then that's what I use to declare the dependencies. Sonia Stephen Connolly-2 wrote: > > If they already exist in a maven repo... you could use that > (provided it > is > not a short groupId... so if it was www.somecompany.org that you > got the > files you could use the groupId of "com.somecompany") > > If you are unsure in any way... you could use your groupId to > ensure that > it > is these exact jars that are used... i.e. "com.ericsson.ncl" > > If you are bored you could crack-open the jar files and see what the > common > package root is and use that > > -Stephen > > 2008/10/2 solo1970 <[EMAIL PROTECTED]> > >> >> Hello, >> >> I am fairly new to Maven and Archiva and would like some help on two >> issues >> both related to the same problem. >> >> We have to use 2 jar files: nclmsg.public.jar and nclutil.public.jar >> provided to us by A third party (we need for compile and packaging >> (war)) >> >> 1. In order to use them, I want to do a mvn deploy:deploy-file to >> our >> repository, which is Archiva >> >> 2. How do we figure out the groupId, artifactId and version of those >> jars... >> I searched the different repositories on the net, but didn't find >> anything, >> probably because they were provided to us. >> >> mvn deploy:deploy-file -Dfile=nclmsg.public.jar -DgroupId=??? >> -DartifactId=??? -Dversion= -Dpackaging=jar -DgeneratePom=true >> -DcreateChecksum=true -DrepositoryId=3pp_cache >> -Durl=dav:http://maven..se:/repository/3pp_cache >> >> Can anyone help clarify this for me??? >> >> Sonia >> -- >> View this message in context: >> http://www.nabble.com/Determining-jar-groupId-ArtifactId-for-deploy-file-tp19781489p19781489.html >> Sent from the Maven - Users mailing list archive at Nabble.com. >> >> >> --- >> -- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > -- View this message in context: http://www.nabble.com/Determining-jar-groupId-ArtifactId-for-deploy-file-tp19781489p19785329.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> >> -- >> View this message in context: >> http://www.nabble.com/Determining-jar-groupId-ArtifactId-for-deploy-file-tp19781489p19786021.html >> Sent from the Maven - Users mailing list archive at Nabble.com. >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Determining-jar-gr
Re: scope-import and dependencyManagement
I think you are mis-interpreting what I said. You have the following structure /pom.xml (agregator) +suite/pom.xml (the suite dependencies) +client/pom.xml (the client thing we are building) +web/pom.xml (the web ting we are building) If you have only one corporate pom (not shown on the tree) then you can get away with everything ultimately inheriting from the corporate pom by having a parent tree like /pom.xml ---is-a-child-of---> /suite/pom.xml /client/pom.xml ---is-a-child-of---> /suite/pom.xml /web/pom.xml ---is-a-child-of---> /suite/pom.xml /suite/pom.xml ---is-a-child-of---> corporate-pom.xml And you'd put your dependencyManagement in /suite/pom.xml The question is why have this import The reason is you may have corporate standards for different packagings... and they may not work in the one pom.xml In that case you would have corporate-root-pom.xml corporate-jar-pom.xml ---is-a-child-of---> corporate-root-pom.xml corporate-war-pom.xml ---is-a-child-of---> corporate-root-pom.xml And then /pom.xml ---is-a-child-of---> corporate-aggregator-pom.xml /client/pom.xml ---is-a-child-of---> corporate-jar-pom.xml /web/pom.xml ---is-a-child-of---> corporate-war-pom.xml Now the problem is how do I ensure that client and web have the same dependencyMangement sections? The answer is import scope so in that case you have /suite/pom.xml ---is-a-child-of---> corporate-root-pom.xml /client/pom.xml ---is-a-child-of---> corporate-jar-pom.xml with dependency on /suite/pom.xml: scope=import /web/pom.xml ---is-a-child-of---> corporate-war-pom.xml with dependency on /suite/pom.xml: scope=import I was explaining *why* you would want import scope. I don't know *if* import scope works... only *why* one would want it in the first place - Stephen 2008/10/3 webhiker <[EMAIL PROTECTED]>: > > Stephen, I don't think you are correct, it IS supposed to be used that way, > and that's what all the Maven documentation lists as examples and operating > behaviour : > > http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html > > I'm having the exact same issue. Using identical examples to the Maven docs, > if I omit the version tag in the child pom, the build always fails with > "missing version tag" error. > > There appears to be something wrong with the code. I'm running Maven 2.0.9 > > > Stephen Connolly-2 wrote: >> >> Each project can list _only the dependencies that it has_ while using the >> import to ensure that only a single suite of dependency versions are used, >> I >> would guess. >> >> It's to separate inheritance from dependency management >> >> On Tue, Sep 16, 2008 at 4:25 PM, Barry Kaplan <[EMAIL PROTECTED]> wrote: >> >>> >>> What is the value of importing into dependencyManagement if those >>> dependencies cannot then be refered to in the regular dependencies? I'm >>> missing the purpose/value. >>> -- >>> View this message in context: >>> http://www.nabble.com/scope-import-and-dependencyManagement-tp19512161p19514217.html >>> Sent from the Maven - Users mailing list archive at Nabble.com. >>> >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> > > -- > View this message in context: > http://www.nabble.com/scope-import-and-dependencyManagement-tp19512161p19795461.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
exec:java arguments vs. commandLineArgs
In the exec:java goal, what is the difference between and ? The documentation says: arguments: The class arguments commandlineArgs: Arguments for the executed program The difference still isn't clear to me. Trevor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DependencyManagement to force scope
I have just remeber my problems with this: in many cases you define the versions with DepencyManagement in a parent POM to align them in all the modules, but, for one child (or via import scope) module you want them to be provided beacause other module provides them. Then, in your child pom you don't want to set the version again, as it is the reponsability of the parent POM. Yes, you can upgrade to provided in the direct dependencies section, but what about the transitive ones?. So i think there is a common use case in where it is very usefull to modify declare only the scope but not the version in the DependencyManagement. Anders Hammar wrote: > > Well, as I see things, if you specify the artifact as provided then you > also want to define the version that is provided. IMO you do want to use > the same version in your Maven build as you're going to use in the > targeted environment. In fact, this was one of my key points in a Maven > talk I did at our local jug earlier this week. > Why would you use a different version (and/or implementation) in your > build than you're going to use when deployd? > > /Anders > > > softwarepills wrote: >> >> I see. Thank you. >> >> So we can modify version, version an scope, but not, only scope. This is >> a problem when you only want using it to "upgrade" a dependency to >> "provided". Then you are also manipulatig the version that should be >> resolved by Maven. >> >> So it seems its not a good idea using it to exclude a "sticky" transitive >> dependency that someone has set as compile but in your context is >> provided, right? >> >> >> Anders Hammar wrote: >>> >>> I'm not sure about the optional tag, but it does apply to version. >>> DependencyManagement is where you can specify the version to use for >>> transitive dependencies. >>> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management >>> >>> /Anders >>> >>> >>> softwarepills wrote: To clarify more the matter. Should we think about DependencyManagement no only as a default value provider, but also as a modifier of inherited dependencies? Does it apply to other parameters like the itself and ?. Jörg Schaible-3 wrote: > > softwarepills wrote: >> I usually think in DependencyManagement as a "by default" section, i >> mean, the version and scope you set in DependencyManagement is the >> version and scope you get if ommited in the real dependency in the >> POM >> and child POMs. >> >> But, i have found that if i insert provided scope in the >> DependencyManagement section, any compile dependency and transitive >> compile dependency will be "upgraded" to provided. >> >> Is this correct? > > Yes. > >> Is this the intended behavior? > > Yes. > >> If yes, this is a inetresting tool to exclude artifacts form being >> packaged, right? > > Yes. > > :) > > You'll need M2.0.6 or greater though ... > > -Jörg > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > >>> >>> >> >> > > -- View this message in context: http://www.nabble.com/DependencyManagement-to-force-scope-tp19776450p19796224.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: scope-import and dependencyManagement
Here's an excerpt from Maven docs about how it should work : dependencyManagement: is used by POMs to help manage dependency information across all of its children. If the my-parent project uses dependencyManagement to define a dependency on junit:junit:4.0, then POMs inheriting from this one can set their dependency giving the groupId=junit and artifactId=junit only, then Maven will fill in the version set by the parent. The benefits of this method are obvious. Dependency details can be set in one central location, which will propagate to all inheriting POMs. In addition, the version and scope of artifacts which are incorporated from transitive dependencies may also be controlled by specifying them in a dependency management section. webhiker wrote: > > Stephen, I don't think you are correct, it IS supposed to be used that > way, and that's what all the Maven documentation lists as examples and > operating behaviour : > > http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html > > I'm having the exact same issue. Using identical examples to the Maven > docs, if I omit the version tag in the child pom, the build always fails > with "missing version tag" error. > > There appears to be something wrong with the code. I'm running Maven 2.0.9 > > > Stephen Connolly-2 wrote: >> >> Each project can list _only the dependencies that it has_ while using the >> import to ensure that only a single suite of dependency versions are >> used, I >> would guess. >> >> It's to separate inheritance from dependency management >> >> On Tue, Sep 16, 2008 at 4:25 PM, Barry Kaplan <[EMAIL PROTECTED]> >> wrote: >> >>> >>> What is the value of importing into dependencyManagement if those >>> dependencies cannot then be refered to in the regular dependencies? I'm >>> missing the purpose/value. >>> -- >>> View this message in context: >>> http://www.nabble.com/scope-import-and-dependencyManagement-tp19512161p19514217.html >>> Sent from the Maven - Users mailing list archive at Nabble.com. >>> >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> > > -- View this message in context: http://www.nabble.com/scope-import-and-dependencyManagement-tp19512161p19795572.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: scope-import and dependencyManagement
Stephen, I don't think you are correct, it IS supposed to be used that way, and that's what all the Maven documentation lists as examples and operating behaviour : http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html I'm having the exact same issue. Using identical examples to the Maven docs, if I omit the version tag in the child pom, the build always fails with "missing version tag" error. There appears to be something wrong with the code. I'm running Maven 2.0.9 Stephen Connolly-2 wrote: > > Each project can list _only the dependencies that it has_ while using the > import to ensure that only a single suite of dependency versions are used, > I > would guess. > > It's to separate inheritance from dependency management > > On Tue, Sep 16, 2008 at 4:25 PM, Barry Kaplan <[EMAIL PROTECTED]> wrote: > >> >> What is the value of importing into dependencyManagement if those >> dependencies cannot then be refered to in the regular dependencies? I'm >> missing the purpose/value. >> -- >> View this message in context: >> http://www.nabble.com/scope-import-and-dependencyManagement-tp19512161p19514217.html >> Sent from the Maven - Users mailing list archive at Nabble.com. >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > -- View this message in context: http://www.nabble.com/scope-import-and-dependencyManagement-tp19512161p19795461.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Calling maven.xml from maven.xml (top level dir to several sub dirs)
Check out the multiproject plugin: http://maven.apache.org/maven-1.x/using/multiproject.html http://maven.apache.org/maven-1.x/plugins/multiproject/ HTH, -Lukas [EMAIL PROTECTED] wrote: I am trying to run maven.xml from another maven.xml - is it possible? Here is the directory structure that I've: Folder1 Subfolder1a Subfolder1b Subfolder1c Subfolder1d Each folder contains it's own maven.xml, project.xml. So, what I want to do is, build all of them together using a single maven file. For that, I want to put a maven.xml in the top level directory (Folder1) and call individual maven.xml in each subfolder (folder1a, folder1b and so on). Is it possible and how? Thanks, xarora - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can't Maven handle dependendies recursively?
youhaodeyi wrote: > > I didn't define the scope. It should be the default value. Then something is wrong with your POM for P2 ... > > Wendy Smoak-3 wrote: >> >> On Thu, Oct 2, 2008 at 7:56 PM, youhaodeyi <[EMAIL PROTECTED]> wrote: >>> I set up a maven project "P1" which depends on the project "P2". P2 >>> includes >>> several dependencies which are used in P1. In this case, I must add >>> these dependencies in P1 too. If not, I will fail to build P1. How can I >>> let maven >>> deal with this recursive dependencies? >> >> How are the dependencies declared in P2? If they are in the default >> compile scope, they should be transitive (so P1 should compile.) >> >> -- >> Wendy >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can't Maven handle dependendies recursively?
I didn't define the scope. It should be the default value. Wendy Smoak-3 wrote: > > On Thu, Oct 2, 2008 at 7:56 PM, youhaodeyi <[EMAIL PROTECTED]> wrote: >> I set up a maven project "P1" which depends on the project "P2". P2 >> includes >> several dependencies which are used in P1. In this case, I must add these >> dependencies in P1 too. If not, I will fail to build P1. How can I let >> maven >> deal with this recursive dependencies? > > How are the dependencies declared in P2? If they are in the default > compile scope, they should be transitive (so P1 should compile.) > > -- > Wendy > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Can%27t-Maven-handle-dependendies-recursively--tp19791304p19793666.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
