ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Göttlich <guo.tu...@googlemail.com>
Subject Re: Partial transitive retrieve
Date Fri, 09 Jul 2010 07:00:10 GMT
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 <mgitman@gmail.com>

> 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 <guo.tuomi@googlemail.com>
>
> > 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 <mgitman@gmail.com>
> >
> > > 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 <guo.tuomi@googlemail.com>
> > >
> > > > 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.
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message