Hi Mitch, Yes, I mean ivy:cachepath.
I also already did numerous ivy:report calls and the transitive dependencies all show up in the 'provided' conf. However, if I look at the dependency itself, the line Configurations often looks like this: runtime, provided, master, runtime(*), provided(*), master(*) So far, I didn't find any explanation of what this means, so I assume this are the configurations that are defined by the artifact. It that correct? If possible, could you give me a hint on what this really means, especially the (*) parts? Thanks in advance. 2010/7/8 Mitch Gitman <[email protected]> > At this point, it sounds like a standard matter of Ivy debugging. Try > running an ivy:report against the dep-for-ear conf and see where the > provided confs otherwise show up. > > When you mention you use ivy:cachefileset for compilation, I'm presuming > you > mean ivy:cachepath. > > And you're right in implying that the problem you're encountering is the > same regardless of whether it involves ivy:retrieve or > ivy:cachefileset+copy, although rather than doing a copy really you should > be doing ivy:cachefileset and then specifying the fileset in the ear task > itself. > > 2010/7/8 Thomas Göttlich <[email protected]> > > > Hi Mitch, > > > > thanks for your reply. > > > > Yes, the provided conf is declared in a base-ivy.xml as follows: > > <conf name="provided" transitive="false" /> > > > > Our ivy.xml files then include the base-ivy.xml in the configurations > > section. > > > > > > Additionally, our compile targets use ivy:cachefileset for compilation - > > with all the relevant confs - just the retrieve that collects the > > dependencies into the ear/lib folder doesn't work correctly. > > > > I assume a combination of ivy:cachefileset and an ant copy task would > have > > the same effect, wouldn't it? > > > > > > 2010/7/7 Mitch Gitman <[email protected]> > > > > > Thomas, your provided conf does specify transitive="false", correct? It > > > should. > > > > > > Side note. Not that this is your problem and not that there's anything > > > literally wrong about what you're doing, but I'd recommend using a > > > combination of ivy:cachepath and ivy:cachefileset instead of > > ivy:retrieve. > > > Then when you're actually ready to specify the libraries that go in > your > > > EAR, just reference the fileset you've created via ivy:cachefileset. > Now > > > you > > > have a fileset you can examine by itself before you go and copy it > where > > > you > > > ultimately need it. > > > > > > 2010/7/7 Thomas Göttlich <[email protected]> > > > > > > > Hi, I have a question on the ivy:retrieve task: > > > > > > > > We are building an enterprise application which consists of multiple > > > > modules. > > > > Each module has several dependencies, among which are some which only > > are > > > > required for compilation. > > > > > > > > The EAR has dependencies on our modules in order to put them into the > > lib > > > > dir. > > > > > > > > We now have several Ivy configurations: > > > > > > > > dep-for-ear -> dependency for the ear, i.e. artifacts of type "ejb" > are > > > put > > > > into the top level and artifacts of type "jar" are put into the "lib" > > > > directory. > > > > provided -> dependency which is needed at compile time only and is > > > provided > > > > by the application server (JBoss in our case) > > > > > > > > > > > > I now want to retrieve all direct and transitive dependencies which > > need > > > to > > > > be put into the ear/lib directory: > > > > > > > > <ivy:retrieve sync="true" conf="dep-for-ear" type="jar" > > > > pattern="${ear.dir}/lib/[ > > > > artifact]-[revision].[ext]" /> > > > > > > > > However, I also get the "provided" transitive dependencies. > > > > The output indicates they are resolved as "dep-for-ear". > > > > > > > > Example: > > > > > > > > In our EAR-project's ivy.xml, we have this dependency definition: > > > > > > > > <dependencies defaultconfmapping="*->*,!sources,!javadoc"> > > > > ... > > > > <dependency org="my.org" name="my-ejb-project" > > > rev="latest.integration" > > > > conf="dep-for-ear" /> > > > > ... > > > > </dependencies> > > > > > > > > > > > > In the ivy.xml of the my-ejb-project module, some JBoss artifacts are > > > > declared as "provided", others are declared as "dep-for-ear": > > > > > > > > <dependencies defaultconfmapping="*->*,!sources,!javadoc"> > > > > ... > > > > <dependency org="my.org" name="my-api-project" > > > rev="latest.integration" > > > > conf="dep-for-ear"/> > > > > ... > > > > <dependency org="jboss" name="jboss-annotations-ejb3" > > > > rev="4.2.3.GA<http://4.2.3.ga/>" > > > > conf="provided"/> > > > > <dependency org="jboss" name="jboss-ejb3x" rev="4.2.3.GA< > > > > http://4.2.3.ga/>" > > > > conf="provided"/> > > > > <dependency org="jboss" name="jboss-ejb3" rev="4.2.3.GA< > > > http://4.2.3.ga/ > > > > >" > > > > conf="provided"/> > > > > <dependency org="jboss" name="jboss-j2ee" rev="4.2.3.GA< > > > http://4.2.3.ga/ > > > > >" > > > > conf="provided"/> > > > > ... > > > > </dependencies> > > > > > > > > > > > > When retrieving the "dep-for-ear" dependencies, I'd expect that > > > > only*my-api-project > > > > * would be copied to the ear/lib dir, since *my-ejb-project* is of > type > > > > ejb. > > > > > > > > However, I also get the JBoss libs. > > > > > > > > > > > > Any idea of what is missing or wrong? > > > > > > > > Thanks in advance for your help. > > > > > > > > > >
