ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Clay <>
Subject Re: instrumented vs non-instrumented artifacts with shared dependencies
Date Tue, 30 Nov 2010 22:10:20 GMT
Thanks for the suggestions.  (I wasn't subscribed to the list previously, so I 
saw the replies in the archives.  I'll respond to them here.)

First, Mitch...

>* Third-party libraries are depended upon by the new common conf. They're
>needed both for deploy and instrumented.

I like your approach of the common 'super' config. I think this makes a lot of 
sense.  I can't believe I didn't think of that.  I'll look into implementing it.

>* Third-party libraries have their own confs apart from deploy and
>instrumented. Instrumentation is not relevant to them. For commons-codec,
>I'm assuming it has a conf called "default".


>* The dependencies element specifies a defaultconf. This way, you're assured
>that someone doesn't forget to make deploy depend on deploy and instrumented
>depend on instrumented on the particular dependency. This default is geared
>towards in-house modules, not third-party modules.

Makes sense.  So essentially, we'd not specify any configurations for in-house
dependencies, but MUST specify confs for 3rd party dependencies.

>* For common, you might make visibility="private" so that it can't be
>depended upon directly. I believe that will still work, but double-check.

I'll try making it private.  Probably will work.

>I notice that you aren't specifying a name for your artifacts. I would
>recommend being explicit about that, so that you just don't fall back to the
>Ivy module name. 

In my real ivy.xml files, I am specifying a name for the artifacts.  I removed 
them from the example for brevity.

>But I also find it odd that the type of "instrumented.jar"
>is able to coexist with "jar" even though both artifacts ostensibly have the
>same name. This may be a feature of Ivy I wasn't aware of. Does the
>instrumented JAR appear with the name moduleB.instrumented.jar, such that
>Ivy is able infer the filename from the extended type name? The following
>would accomplish the same:
><artifact conf="instrumented" type="jar" ext="instrumented.jar" />

Funny you mention that.  Right now I actually DO use:
<artifact conf="instrumented" type="jar" ext="instrumented.jar" />

I was looking into changing it to...
<artifact conf="instrumented" type="instrumented.jar"/>

... as a part of this exercise.  (possibly to enable filtering out jars where
type="instrumented.jar" in certain cases.)

I'll probably revert back to type="jar" regardless.

>One other note. I'm not used to seeing JARs that have been instrumented for
>code coverage being published if only because the coverage report is being
>done on the tests of the project at hand, rather than on projects that
>depend on it. But I see your QA team is also doing coverage so I can

Yeah, we publish these jars mostly for the QA deployment. It allows us to 
assemble a war with instrumented versions of our jars in the WEB-INF/lib.  When 
I implemented it, I preferred this approach rather than building a 
non-instrumented war, and extracting only our own jars from it, instrumenting 
them, and then reassembling the war.  We also have some modules that are 
deployed "outside of the war" which would need to be instrumented as well.

Anyway, this approach has been working great so far.

Now for Tim...

>If developers are writing unit tests, those tests are for the particular
>module they're bundled with.   Since it's the module they're working on,
>it's available as source in the IDE [for reviewing coverage as they work],
>and later as part of your build process [for aggregation of the metric
>Wouldn't counting coverage of the instrumented jars fall under incidental
>coverage, and as such not be counted?

When running unit tests, we only run with the instrumented version of the module 
for which the unit tests are executing.  i.e. When running unit tests for 
moduleB, we run with the instrumented moduleB, but the NON-instrumented moduleA 
(or any other depended upon modules).  The instrumented modules are publish 
simply to create an instrumented deployment for use during the 'real' runtime by 
QA (or curious developers).

Thanks for the other pointers as well.  When I originally implemented this, I 
did consider instrumenting the deployment 'after the fact' like you mentioned. 
At the time, I decided that assembling pre-instrumented jars was easier.  I'm 
still not sure which approach I like better. What we have right now works well.  
I'd probably think about it a bit more if I were implementing it from scratch 

Thanks again Mitch and Tim.



View raw message