ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Goblirsch <dgoblir...@interactivebrokers.com>
Subject Re: artifactreport leaves out some dependencies
Date Wed, 03 Mar 2010 21:14:50 GMT
Maarten Coene wrote:
> It's hard to tell what's going wrong.
> After looking at the code, I think the artifactreport does ignore the fact that the resolve
should be done in dynamic resolveMode.
>
> Could you verify this hypothesis by setting the resolveMode to dynamic in your settings.xml?
> Cfr http://ant.apache.org/ivy/history/latest-milestone/settings/module.html
>
> <ivysettings>
>     ...
>     <modules>
>         <module organisation="xxx" name="*" resolveMode="dynamic"/>
>     </modules>
> </ivysettings>
>
> Where xxx is the organisation of your P module.
>
> regards,
> Maarten
>
>   

As I mentioned in a past email,  when I add the <modules> element you 
suggested, all other conditions the same,
the dependencies show up in the report as desired.

My next question is: Is this failure of artifactreport to just use the 
results of the preceding resolve a bug?
Is the <modules/>  suggestion above a "work around" for something that 
will be fixed, or is that the expected thing to do?

> ----- Original Message ----
> From: David Goblirsch <dgoblirsch@interactivebrokers.com>
> To: ivy-user@ant.apache.org
> Sent: Mon, March 1, 2010 3:46:02 PM
> Subject: Re: artifactreport leaves out some dependencies
>
> Maarten Coene wrote:
>   
>> Seems like a bug to me, could you provide more details?
>>
>> Maarten
>>
>>
>>
>>
>> ----- Original Message ----
>> From: David Goblirsch <dgoblirsch@interactivebrokers.com>
>> To: ivy-user@ant.apache.org
>> Sent: Thu, February 25, 2010 7:18:33 PM
>> Subject: artifactreport leaves out some dependencies
>>
>> I have a resolve target in an ant build that correctly finds all the jars;
>> I can see them in build/lib/[conf].
>>
>> But my artifactreport-[conf].xml does not include a list of all the jars that
>> the resolver found and in fact retrieved.
>>
>> Is this a bug, or does artifactreport "filter" the resolved list. If so, what
>> is the "filter"?
>>  
>>     
>
> I am sorry that I cannot just hand you a working example that
> duplicates the bug, but the build involves proprietary jars and a
> build system that is behind a corporate firewall.  So for now I will
> have to provide a detailed description of the conditions under which
> ivy:artifactreport fails to include some dependencies. Hopefully this
> is enough to diagnose the problem!
>
>
> SCENARIO
> --------
>
> I have 3 jars,
>
> P.jar         a project jar that contains a "main" program as well
>                as other code.
>
> M-api.jar     a module api jar
>
> M-impl.jar    a module implementation jar.
>
>
> In all 3 cases, the ivy files define 4 configurations:
>
>   (+) api      which is extended by
>   (-) compile  which is extended by
>   (+) runtime  which is extended by
>   (-) test
>
> and the defaultconfmapping is set to
>
>    "api->api, compile->api, runtime->runtime, test->runtime"
>
> with confmappingoverride="true".
>
>
> Because P.jar contains a "main" program, its build process ends with a
> resolution of the "runtime" configuration.
>
>
> For M-impl.jar, we have
>
>   <dependency conf="compile" org="xxx" name="M-api"
>               rev="latest.integration"/>
>
> For P.jar we have
>
>   <dependency conf="compile" org="xxx" name="M-api"
>               rev="latest.integration" />
>   <dependency conf="compile" org="xxx" name="M-impl"
>               rev="latest.integration" />
>
>
> Since we use confmappingoverride="true" and since "runtime" extends
> "compile", both M-api.jar and M-impl.jar should be found during the
> "runtime" resolve.  They are (yeah!), but the problem is in the
> reporting.
>
>
> OBSERVED PROBLEM
> ----------------
>
> The observed problem is this: When the local repository and local
> cache are completely empty, i.e., there are no files under
> ~/.ivy2/cache or ~/.ivy2/local, then when a fresh build of P.jar is
> complete, the file
>
> artifactreport-runtime.xml
>
> contains an entry for M-impl, but NOT M-api.
>
>
> Of course, for this build to even work, both M-api.jar and M-impl.jar
> and their associated resolved ivy files are already published to a
> "public" (within the company) repository.  We do not use version
> numbers on our home-grown jars, so the published ivy file for
>
>   M-api.jar
>
> lists its revision as 20100218185041, and the published ivy file for
>
>   M-impl.jar
>
> lists its revision as 20100218185204, claiming it was resolved against
> version 20100218185043 of M-api.jar.  The build correctly finds and
> "downloads" these jars from the "public" repository, but the
> artifactreport for the "runtime" configuration is missing an entry for
> M-api.
>
>   Possible clue: Note that the resolved version of M-api.jar
>   in the M-impl ivy file is 2 seconds after the revision
>   listed in the published M-api ivy file. However this may not be
>   relevant since we do resolves with resolveMode="dynamic".
>
>
> Note that our resolves are done with resolveMode="dynamic".  Here is
> the runtime resolution chunk from the ant build file:
>
> <ivy:resolve conf="runtime"
>               resolveMode="dynamic"
>               />
> <ivy:retrieve conf="runtime"
>      pattern="${ivy.lib.dir}/runtime/[artifact](-[revision]).[ext]"
>                sync="true"
>                />
> <ivy:report conf="runtime"
>              graph="false"
>              outputpattern="[module]-[conf].[ext]"
>              todir="${dir.build}/report"
>              />
> <ivy:artifactreport conf="runtime"
>       tofile="${dir.build}/report/artifactreport-runtime.xml" />
>
>
> As mentioned above, both M-api.jar and M-impl.jar are placed into
> build/lib/runtime, so the resolving part works beautifully.
>
> Interestingly, the ivy:artifactreport issues a log message saying that
> it sees M-api.jar; it just doesn't include it in the final report.
> >From the build log (names replaced):
>
> [ivy:artifactreport]  found xxx#M-api;20100218185041 in production
> [ivy:artifactreport]  [20100218185041] xxx#M-api;latest.integration
> [ivy:artifactreport]  found xxx#M-impl;20100218185204 in production
> [ivy:artifactreport]  [20100218185204] xxx#M-impl;latest.integration
>
> So ivy:artifactreport sees the dependency on M-api, logs that it found
> it, but the element is MISSING from the artifactreport-runtime.xml
> file.
>
>
> DOES IT EVER WORK?
> ------------------
>
> Yes.  If I now go and build a new version of M-api.jar locally, so
> that is it published to the local repository, then when I rebuild
> P.jar, M-api will be included in the report as expected.
>
>
>       
>
>   


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