First copy one file, befo re anything
hello I must to copy one file before anything, This file contains some properties for filtering What plugin must i use and how for moving one file to one directory? Thanks
Re: First copy one file, befo re anything
Where is this file maintained? Why is it not within the project? What kind of filtering needs to be done (when in the build)? Is there anything else that you can add to give more details. The answers to these questions might give people some idea about how to do what you want. Ron On 05/12/2014 10:12 AM, Aitor Iturriondobeitia wrote: hello I must to copy one file before anything, This file contains some properties for filtering What plugin must i use and how for moving one file to one directory? Thanks -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: First copy one file, befo re anything
Hi. Use the ant plugin. Here's an example: build plugin artifactIdmaven-antrun-plugin/artifactId executions execution phasevalidate/phase goals goalrun/goal /goals configuration tasks delete file=src/main/resources/config.properties / copy file=src/main/resources/gold/config.properties tofile=src/main/resources/config.properties / delete file=src/main/resources/TestData.properties / copy file=srcץ Thanks, Yaron בתאריך 5 בדצמ' 2014 17:13, Aitor Iturriondobeitia laudio.i...@gmail.com כתב: hello I must to copy one file before anything, This file contains some properties for filtering What plugin must i use and how for moving one file to one directory? Thanks
Re: First copy one file, befo re anything
Thanks I must copy the file to one dir out of the project. The file is Info the project ($project.base}/Filters and i must to move to c:/Filters Thanks El viernes, 5 de diciembre de 2014, Yaron Goldstein yarongoldstei...@gmail.com escribió: Hi. Use the ant plugin. Here's an example: build plugin artifactIdmaven-antrun-plugin/artifactId executions execution phasevalidate/phase goals goalrun/goal /goals configuration tasks delete file=src/main/resources/config.properties / copy file=src/main/resources/gold/config.properties tofile=src/main/resources/config.properties / delete file=src/main/resources/TestData.properties / copy file=srcץ Thanks, Yaron בתאריך 5 בדצמ' 2014 17:13, Aitor Iturriondobeitia laudio.i...@gmail.com javascript:_e(%7B%7D,'cvml','laudio.i...@gmail.com'); כתב: hello I must to copy one file before anything, This file contains some properties for filtering What plugin must i use and how for moving one file to one directory? Thanks
Re: First copy one file, befo re anything
Hi, You can copy it to any directory of choice. One thing to remember is to run it in the validate phase: mvn validate install More info here http://maven.apache.org/plugins/maven-antrun-plugin/usage.html Good luck Shalom!! Yaron On Fri, Dec 5, 2014 at 6:06 PM, Aitor Iturriondobeitia laudio.i...@gmail.com wrote: Thanks I must copy the file to one dir out of the project. The file is Info the project ($project.base}/Filters and i must to move to c:/Filters Thanks El viernes, 5 de diciembre de 2014, Yaron Goldstein yarongoldstei...@gmail.com escribió: Hi. Use the ant plugin. Here's an example: build plugin artifactIdmaven-antrun-plugin/artifactId executions execution phasevalidate/phase goals goalrun/goal /goals configuration tasks delete file=src/main/resources/config.properties / copy file=src/main/resources/gold/config.properties tofile=src/main/resources/config.properties / delete file=src/main/resources/TestData.properties / copy file=srcץ Thanks, Yaron בתאריך 5 בדצמ' 2014 17:13, Aitor Iturriondobeitia laudio.i...@gmail.com כתב: hello I must to copy one file before anything, This file contains some properties for filtering What plugin must i use and how for moving one file to one directory? Thanks
Re: Using shaded JAR as a dependency in a WAR module
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ron, Thanks for the link. I'm attempting to do this with the shade plugin. I took a look at the JAR that the shade plugin generates with my configuration, and it seems to have the pom.xml files from which it was built, but not the reduced dependency pom.xml (or any pom.xml from the built / shaded artifact). This means that I have not configured the shade plugin properly to produce an artifact that can be consumed as if it was built without using the shade plugin. The entire list of dependencies for the WAR module: dependencies dependency groupIdorg.mdeggers/groupId artifactIdCoreServer/artifactId version${coreserver.version}/version /dependency dependency groupIdorg.mdeggers/groupId artifactIdCoreClient/artifactId version${coreclient.version}/version typewar/type /dependency dependency groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId version2.5/version scopeprovided/scope /dependency dependency groupIdjavax.servlet.jsp/groupId artifactIdjsp-api/artifactId version2.1/version scopeprovided/scope /dependency dependency groupIdorg.mdeggers/groupId artifactIdGlobalCalcWeb/artifactId version${globalweb.version}/version typewar/type /dependency dependency groupIdorg.mdeggers/groupId artifactIdIHomeWeb/artifactId version${ihome.version}/version typepom/type /dependency dependency groupIdorg.mdeggers/groupId artifactIdIFCResources/artifactId version1.0-SNAPSHOT/version /dependency /dependencies There could be as many as 50 components going into the final WAR file, so it would be nice to manage them in a more organized fashion (as well as reduce the clutter in WEB-INF/lib). All of the versions with properties have properties defined. The last dependency is the shaded JAR, and the one that is not behaving as expected (but probably as built / configured). The NetBeans graphical display of the dependencies shows IFCResources, as well as the three components it was shaded from. Sorry for the top-post. It seems to be the norm on this list, whereas the Tomcat mailing list explicitly mentions replying at the bottom. I didn't see any mention of posting style on the site. If posting at the bottom is the encouraged form, I'll be happy to do so. . . . just my two cents /mde/ On 12/4/2014 8:41 PM, Ron Wheeler wrote: We do this all the time and it always works. http://blog.artifact-software.com/tech/?p=121 Aggregation jars make development simpler and wars smaller Partial dependencies for org.mdeggers:iforeclosure:1.0-SNAPSHOT:war dependencies dependency groupIdorg.mdeggers/groupId artifactIdIFCResources/artifactId version1.0-SNAPSHOT/version /dependency /dependencies What are the dependencies for the war file? Partial list is not much help. Ron On 04/12/2014 6:29 PM, Mark Eggers wrote: Folks, I admit it, I'm a bit confused (and relatively new to maven). Goal: To release a WAR file with a minimal number of JAR files in WEB-INF/lib. Thought: 1. Break up the WAR project into a WAR module and a JAR module 2. Make the WAR module be dependent on the JAR module 3. Use the Maven shade plugin in the JAR module to create a shaded JAR 4. Drive the entire project with an agregator pom.xml The JAR module does shade properly, creating a single JAR with all of the dependencies bundled into a single JAR. It uses a pom dependency to gather in most of its requirements. None of the JAR or pom dependencies have further dependencies, so the resulting JAR is self-contained. However, when I build the WAR file and reference the shaded JAR file as a dependency, I do not get the shaded JAR file in WEB-INF/lib. Instead, I get all of the dependencies as individual JAR files in WEB-INF/lib. I'm using the following environment (can post my complete pom.xml files if needed). OS:Fedora Linux 64 bit - latest updates JDK: 1.7.0_72 64 bit Maven: 3.2.3 maven-shade-plugin: 2.3 maven-war-plugin: 2.4 shade configuration and dependencies for org.mdeggers:IFCResources:1.0-SNAPSHOT properties calhost.version1.0-SNAPSHOT/calhost.version ihomeresources.version1.0-SNAPSHOT/ihomeresources.version /properties dependencies dependency groupIdorg.mdeggers/groupId artifactIdCalhost/artifactId version${calhost.version}/version /dependency dependency groupIdorg.mdeggers/groupId artifactIdIHomeResources/artifactId version${ihomeresources.version}/version typepom/type /dependency /dependencies plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-shade-plugin/artifactId version2.3/version executions execution idcombine/id phasepackage/phase goals goalshade/goal /goals configuration artifactSet includes
Re: Using shaded JAR as a dependency in a WAR module
Some forums are more concerned about form than content. Everyone here is pretty focused on solving your problem rather than telling how to post it. If you look at the examples in my post, you will see that the type is pom for dependencies on libraries. We also use provided scope since we install the libraries once rather than include them with each upload of a war file since they generally don't change. We set the content of our libraries (jars and versions) at the beginning of a release cycle and don't change them for the duration of the release unless there is an emergency. This gives everyone a stable environment and once you have the libraries loaded into Tomcat, in our case, they do not change as the application gets worked on. This makes the testing go quicker since you are only replacing the war file that you are working on and the war file only contains the code that we write. I am not sure if this applies to your libraries. Ron On 05/12/2014 12:04 PM, Mark Eggers wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ron, Thanks for the link. I'm attempting to do this with the shade plugin. I took a look at the JAR that the shade plugin generates with my configuration, and it seems to have the pom.xml files from which it was built, but not the reduced dependency pom.xml (or any pom.xml from the built / shaded artifact). This means that I have not configured the shade plugin properly to produce an artifact that can be consumed as if it was built without using the shade plugin. The entire list of dependencies for the WAR module: dependencies dependency groupIdorg.mdeggers/groupId artifactIdCoreServer/artifactId version${coreserver.version}/version /dependency dependency groupIdorg.mdeggers/groupId artifactIdCoreClient/artifactId version${coreclient.version}/version typewar/type /dependency dependency groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId version2.5/version scopeprovided/scope /dependency dependency groupIdjavax.servlet.jsp/groupId artifactIdjsp-api/artifactId version2.1/version scopeprovided/scope /dependency dependency groupIdorg.mdeggers/groupId artifactIdGlobalCalcWeb/artifactId version${globalweb.version}/version typewar/type /dependency dependency groupIdorg.mdeggers/groupId artifactIdIHomeWeb/artifactId version${ihome.version}/version typepom/type /dependency dependency groupIdorg.mdeggers/groupId artifactIdIFCResources/artifactId version1.0-SNAPSHOT/version /dependency /dependencies There could be as many as 50 components going into the final WAR file, so it would be nice to manage them in a more organized fashion (as well as reduce the clutter in WEB-INF/lib). All of the versions with properties have properties defined. The last dependency is the shaded JAR, and the one that is not behaving as expected (but probably as built / configured). The NetBeans graphical display of the dependencies shows IFCResources, as well as the three components it was shaded from. Sorry for the top-post. It seems to be the norm on this list, whereas the Tomcat mailing list explicitly mentions replying at the bottom. I didn't see any mention of posting style on the site. If posting at the bottom is the encouraged form, I'll be happy to do so. . . . just my two cents /mde/ On 12/4/2014 8:41 PM, Ron Wheeler wrote: We do this all the time and it always works. http://blog.artifact-software.com/tech/?p=121 Aggregation jars make development simpler and wars smaller Partial dependencies for org.mdeggers:iforeclosure:1.0-SNAPSHOT:war dependencies dependency groupIdorg.mdeggers/groupId artifactIdIFCResources/artifactId version1.0-SNAPSHOT/version /dependency /dependencies What are the dependencies for the war file? Partial list is not much help. Ron On 04/12/2014 6:29 PM, Mark Eggers wrote: Folks, I admit it, I'm a bit confused (and relatively new to maven). Goal: To release a WAR file with a minimal number of JAR files in WEB-INF/lib. Thought: 1. Break up the WAR project into a WAR module and a JAR module 2. Make the WAR module be dependent on the JAR module 3. Use the Maven shade plugin in the JAR module to create a shaded JAR 4. Drive the entire project with an agregator pom.xml The JAR module does shade properly, creating a single JAR with all of the dependencies bundled into a single JAR. It uses a pom dependency to gather in most of its requirements. None of the JAR or pom dependencies have further dependencies, so the resulting JAR is self-contained. However, when I build the WAR file and reference the shaded JAR file as a dependency, I do not get the shaded JAR file in WEB-INF/lib. Instead, I get all of the dependencies as individual JAR files in
Re: Using shaded JAR as a dependency in a WAR module
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ron and Stephen, Ron, we cannot use libraries installed into Tomcat's $CATALINA_BASE/lib directory for several reasons. While it's nice from a developer and deployment point of view, we do end up running multiple versions of the WAR file (with different versions of various dependencies) on the same Tomcat. We also release the WAR file, and it would be difficult to require people to modify their server environment. Thanks! I finally figured it out. 1. Issue number 1 I was using a POM artifact to aggregate a set of lower level libraries. In order to do this, I had to set the following in the shade plugin: promoteTransitiveDependenciestrue/promoteTransitiveDependencies This of course makes perfect sense. 2. Issue number 2 I needed to set the following: keepDependenciesWithProvidedScopetrue/keepDependenciesWithProvidedScope Both of these are mentioned (albeit not as clearly as it might be) in the fine documentation here: http://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html Combining those two creates a JAR with all of the dependency pom.xml files in it, as well as the classes / resources / etc. An examination of the target WAR file shows a nice, clean WEB-INF/lib with managed dependencies all the way down the chain. For those people interested, the dependencies and shade plugin configuration are given below. dependencies dependency groupIdorg.mdeggers/groupId artifactIdCalhost/artifactId version${calhost.version}/version /dependency dependency groupIdorg.mdeggers/groupId artifactIdIHomeResources/artifactId version${ihomeresources.version}/version typepom/type /dependency /dependencies build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-shade-plugin/artifactId version2.3/version executions execution idcombine/id phasepackage/phase goals goalshade/goal /goals configuration keepDependenciesWithProvidedScopetrue/keepDependenciesWithProvidedScope promoteTransitiveDependenciestrue/promoteTransitiveDependencies artifactSet includes includeorg.mdeggers:*/include /includes /artifactSet /configuration /execution /executions /plugin /plugins /build Sorry for the line length. Obviously, if you don't have any transitive dependencies, you won't need the promote line. It works. Hope this is the correct solution. . . . just my two cents /mde/ On 12/5/2014 10:57 AM, Ron Wheeler wrote: Some forums are more concerned about form than content. Everyone here is pretty focused on solving your problem rather than telling how to post it. If you look at the examples in my post, you will see that the type is pom for dependencies on libraries. We also use provided scope since we install the libraries once rather than include them with each upload of a war file since they generally don't change. We set the content of our libraries (jars and versions) at the beginning of a release cycle and don't change them for the duration of the release unless there is an emergency. This gives everyone a stable environment and once you have the libraries loaded into Tomcat, in our case, they do not change as the application gets worked on. This makes the testing go quicker since you are only replacing the war file that you are working on and the war file only contains the code that we write. I am not sure if this applies to your libraries. Ron On 05/12/2014 12:04 PM, Mark Eggers wrote: Ron, Thanks for the link. I'm attempting to do this with the shade plugin. I took a look at the JAR that the shade plugin generates with my configuration, and it seems to have the pom.xml files from which it was built, but not the reduced dependency pom.xml (or any pom.xml from the built / shaded artifact). This means that I have not configured the shade plugin properly to produce an artifact that can be consumed as if it was built without using the shade plugin. The entire list of dependencies for the WAR module: dependencies dependency groupIdorg.mdeggers/groupId artifactIdCoreServer/artifactId version${coreserver.version}/version /dependency dependency groupIdorg.mdeggers/groupId artifactIdCoreClient/artifactId version${coreclient.version}/version typewar/type /dependency dependency groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId version2.5/version scopeprovided/scope /dependency dependency groupIdjavax.servlet.jsp/groupId artifactIdjsp-api/artifactId version2.1/version scopeprovided/scope /dependency dependency
Re: scm publish plugin and git pathname
seems you're the first one to ask for such a feature Regards, Hervé Le mercredi 3 décembre 2014 09:33:34 Benson Margulies a écrit : Is there any way to get the scm publish plugin to push to something other than the root of the repo at the specified branch? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [scala-debate] Emotional Support Group for Typesafe Maven Users
Le mercredi 3 décembre 2014 17:32:47 Rodrigo Cano a écrit : I just want to say that maven is not at all flowers, their phase model is too primitive, to the point where something such as wsimport (pretty basic stuff for good ol' java) did not work properly: I had a configuration for the java version wanted in the pom.xml, but because of the way phases work and the very restricted compile order, wsimport would always pick my OS-globally configured wsimport instead of the one configured in the pom.xml, leading to incorrect defintions of the ws and a VERY ugly hack where I had to basically compile the thing twice to get it right. Also, my os installed java was java7, the pom.xml stated that I wanted java6, guess what version would the .class generated by wsimport be.. I'm interested to understand the problem and try to improve. What is the Maven plugin you're using for wsimport, with which version? The general solution to such problem is to use Toolchains: toolchains support has to be implemented in the plugin. Here is a list of know plugins supporting toolchains: http://maven.apache.org/guides/mini/guide-using-toolchains.html Adding jax-ws plugin to the list would be an interesting improvement My point is, build tools are no easy task, and I know no system that does it right. While my experience with sbt has certainly not been yours (and I've done quite a bit with it, same with maven, where I had written several plugins for our own dev environment), I do have to say that I find it an improvement over maven. I still love maven for what it accomplished though. +1 peace: just let everyone choose the best tool for his own use case And let us know when Maven can be improved. Regards, Hervé Cheers. On Wed, Dec 3, 2014 at 5:11 PM, Eric Kolotyluk eric.koloty...@gmail.com wrote: Does anyone know of a good emotional support group for people trying to use Maven with Typesafe projects such as Akka and Play? I was thinking maybe there could a buddy/sponsor system, such as used in AA and other self help groups. Maybe there might be group sessions where people can talk about their trauma, especially by being constantly invalidated by comments such as you should use the simple build tool SBT, cause, well you know, it's simple and easy to use. Seriously though, is there a community of people who are successfully using Maven with Akka an Play projects? I would love to meet you. I can see why people who have tried Maven naturally think oh, its' too complicated, anyone can write a simple build tool that does what Maven does. Clearly they do not appreciate what Maven is or what it does. SBT and Gradle are two great examples of projects that attempted to do something more simple, but in the end, really don't measure up. I personally think the Scala community would be been better served if more investment was made in developing better Scala build tools within the Maven framework. More and better plugins for Scala, Akka, Play, etc. Better use of http://books.sonatype.com/mcookbook/reference/sect-scala-script-inline.htm l http://books.sonatype.com/mcookbook/reference/ch03s03.html I don't know if there is a Scala template for writing Maven plugins (or mojos), but there should be. The more I use SBT, the less I like it. It is not what I consider a serious build tool for build engineers, it is a toy or playground for Scala hackers who thrive on the abstruse. Don't get me wrong, I love Scala, but creating a build tool around .scala files just invites the use of chicken tracks and obscure overly concise cleverness that leads to one WTF experience after another. *It is actually possible to write Scala code that you can reason about,* but it just as easy to write Scala code that resembles APL, and reasoning about build engineering was clearly not a priority with the designers of SBT. The Scala-IDE was a really great approach because it leveraged off of an existing IDE infrastructure such as Eclipse, rather than trying to write an IDE from scratch the way SBT does. I wish the Scala/Typesafe community had taken the same approach with build-tools. - Eric -- You received this message because you are subscribed to the Google Groups scala-debate group. To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: scm publish plugin and git pathname
On Fri, Dec 5, 2014 at 4:06 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: seems you're the first one to ask for such a feature I feel like I'm missing something here. The eventual goal is to include the version in the URL on github, by pushing to a subdir on gh-pages. I'm puzzled to be first. OK, I'll go knock it into the plugin. Regards, Hervé Le mercredi 3 décembre 2014 09:33:34 Benson Margulies a écrit : Is there any way to get the scm publish plugin to push to something other than the root of the repo at the specified branch? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Using shaded JAR as a dependency in a WAR module
Great. I hope that the discussion was helpful even if you found a better solution. Ron On 05/12/2014 3:22 PM, Mark Eggers wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ron and Stephen, Ron, we cannot use libraries installed into Tomcat's $CATALINA_BASE/lib directory for several reasons. While it's nice from a developer and deployment point of view, we do end up running multiple versions of the WAR file (with different versions of various dependencies) on the same Tomcat. We also release the WAR file, and it would be difficult to require people to modify their server environment. Thanks! I finally figured it out. 1. Issue number 1 I was using a POM artifact to aggregate a set of lower level libraries. In order to do this, I had to set the following in the shade plugin: promoteTransitiveDependenciestrue/promoteTransitiveDependencies This of course makes perfect sense. 2. Issue number 2 I needed to set the following: keepDependenciesWithProvidedScopetrue/keepDependenciesWithProvidedScope Both of these are mentioned (albeit not as clearly as it might be) in the fine documentation here: http://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html Combining those two creates a JAR with all of the dependency pom.xml files in it, as well as the classes / resources / etc. An examination of the target WAR file shows a nice, clean WEB-INF/lib with managed dependencies all the way down the chain. For those people interested, the dependencies and shade plugin configuration are given below. dependencies dependency groupIdorg.mdeggers/groupId artifactIdCalhost/artifactId version${calhost.version}/version /dependency dependency groupIdorg.mdeggers/groupId artifactIdIHomeResources/artifactId version${ihomeresources.version}/version typepom/type /dependency /dependencies build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-shade-plugin/artifactId version2.3/version executions execution idcombine/id phasepackage/phase goals goalshade/goal /goals configuration keepDependenciesWithProvidedScopetrue/keepDependenciesWithProvidedScope promoteTransitiveDependenciestrue/promoteTransitiveDependencies artifactSet includes includeorg.mdeggers:*/include /includes /artifactSet /configuration /execution /executions /plugin /plugins /build Sorry for the line length. Obviously, if you don't have any transitive dependencies, you won't need the promote line. It works. Hope this is the correct solution. . . . just my two cents /mde/ On 12/5/2014 10:57 AM, Ron Wheeler wrote: Some forums are more concerned about form than content. Everyone here is pretty focused on solving your problem rather than telling how to post it. If you look at the examples in my post, you will see that the type is pom for dependencies on libraries. We also use provided scope since we install the libraries once rather than include them with each upload of a war file since they generally don't change. We set the content of our libraries (jars and versions) at the beginning of a release cycle and don't change them for the duration of the release unless there is an emergency. This gives everyone a stable environment and once you have the libraries loaded into Tomcat, in our case, they do not change as the application gets worked on. This makes the testing go quicker since you are only replacing the war file that you are working on and the war file only contains the code that we write. I am not sure if this applies to your libraries. Ron On 05/12/2014 12:04 PM, Mark Eggers wrote: Ron, Thanks for the link. I'm attempting to do this with the shade plugin. I took a look at the JAR that the shade plugin generates with my configuration, and it seems to have the pom.xml files from which it was built, but not the reduced dependency pom.xml (or any pom.xml from the built / shaded artifact). This means that I have not configured the shade plugin properly to produce an artifact that can be consumed as if it was built without using the shade plugin. The entire list of dependencies for the WAR module: dependencies dependency groupIdorg.mdeggers/groupId artifactIdCoreServer/artifactId version${coreserver.version}/version /dependency dependency groupIdorg.mdeggers/groupId artifactIdCoreClient/artifactId version${coreclient.version}/version typewar/type /dependency dependency groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId version2.5/version scopeprovided/scope /dependency dependency