ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <>
Subject Re: Type and artifacts usage
Date Sat, 21 Nov 2009 19:17:25 GMT

Le 18 nov. 2009 à 10:26, Alex Foreman a écrit :

> Hi Nicolas,
> Thanks for responding.
> Comments and Questions replied inline.
> 2009/11/15 Nicolas Lalevée <>:
>> Le 2 nov. 2009 à 17:43, Alex Foreman a écrit :
>>> Hi,
>>> I have two interesting problems that I would like to know what your
>>> thoughts are / if there is a solution already.
>>> 1.  I specify an artifact such as:
>>> <artifact name="myjar" type="jar" ext="jar" conf="runtime" />
>>> However in this case 'myjar' is actually providing two distinct 'type'
>>> or usages.
>>> This could be for instance be similar to the ivy jar itself which
>>> provides source and binaries.  So I would want:
>>> <artifact name="myjar" type="jar,src" ext="jar" conf="runtime" />
>>> Or it could be that sometimes I require the jar to compile against and
>>> sometimes I want to place it on the aspectpath of iajc, so:
>>> <artifact name="myjar" type="jar,aspects" ext="jar" conf="runtime" />
>>> In both these cases the jar has two distinct use cases and I want to
>>> give the jar as multiple type but this seems impossible.
>>> If this is illegal then could I do this:
>>> <artifact name="myjar" type="jar,aspects" ext="jar" conf="runtime" />
>>> <artifact name="myjar" type="aspects" ext="jar" conf="runtime" />
>>> And provide the artifact twice with different type rarther than a
>>> comma seperated list (csl being preferable)
>>> Can anyone comment on this?
>> Yep you can do:
>> <artifact name="myjar" type="jar" ext="jar" conf="runtime" />
>> <artifact name="myjar" type="aspects" ext="jar" conf="runtime" />
>> But this would mean that the myjar.jar would be duplicated in the repository. If
you have no worry with space this would work.
>> But in your use case, don't you actually need a configuration named "aspect" ?
> I belived the pattern matcher would only require one artifact but it
> would be picked up in two different calls.  one conf="runtime" and
> type="jar" and one conf ="runtime" and conf="aspect".
> It may be a configuration we use, we may use types.  Types seems to be
> the best for for future work as a type="aspect" would allow better
> future IvyDE integration for aspects including with STS.
> As specifyied on another thread it is not good practise to have a
> 'src' config or 'javadoc' config.  So Using 'aspects' as a type is
> more inline with that.
> Is it illegal or impossible to have a multitype jar?

It is possible, but they would then be duplicated in the repository.

> If its not impossible for impl details or Ivy magic would you like me
> to file a JIRA?

I think it would be quite easy to have Ivy support multi type in the declaration of the Ivy,
but it would be just a declaration simplification. In your use case, this:
<artifact name="myjar" type="jar,aspects" ext="jar" conf="runtime" />
would actually be equivalent to that:
<artifact name="myjar" type="jar" ext="jar" conf="runtime" />
<artifact name="myjar" type="aspects" ext="jar" conf="runtime" />
and then having duplicate artifacts in the repo.

About truly multitype jar (one jar in the repo, two declared types in the ivy.xml), I don't
know if it is feasible, I don't know the Ivy implementation enough. At least I don't see any
conceptual issue.
A Jira might be needed.

>>> 2.
>>> I have a multi jar build.  Jar mylib has all core classes and
>>> mylib-backcompat relies on mylib (but is not a seperate project as I
>>> want people to be able to refer to the project and get its corejars or
>>> its backcompat jars as well)
>>> <conf name="runtime" />
>>> <conf name="backcompat" extends="runtime" />
>>> <artifact name="mylib" type="jar" ext="jar" conf="runtime" />
>>> <artifact name="mylib-backcompat" type="jar" ext="jar" conf="backcompat" />
>>> Now what I want to be able to do in ivy is when i cache path the
>>> backcompat dependencies that the ivy cachepath also retrives the jars
>>> that it requires from its own project and no others.
>> Actually I don't get what classpath you are trying to build. Could you explain a
little bit more ?
> Sure,
> I build mylib using its runtime dependencies (lets just say commons lang.)
> Now I want to construct the classpath for mylib-backcompat,  A
> cachepath will pick up transitivly commons lang, but wont pick up
> 'mylib'.  So compilation will fail.  Even tho we have specified that
> mylib-backcompat extends runtime, the missing library is actually one
> already built by the project itself.
> Does this explain it better?
> This is not urgent as I have  work around, but feel it is something
> ivy should be able to do. (maybe an ivy.built.artifacts.dir which can
> be set (or be null) by people to there artifacts directory).
> If you agree Ill add a JIRA and try to explain it better :)

I got your use case :)

The problem here is that you want Ivy to resolve a dependency (mylib) while it isn't have
been published yet. I don't think there is a proper way to do it in Ivy.

But in ant it can be resolved easily. Just build a classpath based on the cache path and the
build lib:
<ivy:cachepath pathid="compile.classpath" conf="compile" />
<path id="mylib-backcompat.classpath">
  <path refid="compile.classpath"/>
  <pathelement path="${basedir}/target/dist/jars/mylib.jar" />

I don't think this is a workaround, I think this is a clean way to accomplish it.


>>> Currently I solve this by adding all made jars automatically to javac
>>> outside of ivy using a fileset.
>>> Is there any non complicated way to do this in ivy?
>>> so for compilation of backcompat where I have junit as a  runtime
>>> dependency on a ivy:cachepath I would get
>>> Junit:hamcrest:mylib on the path in one fell swoop.
>>> SideNote:
>>> We have chosen to use the ivy standard of type="jar" for java
>>> binaries.  Can anyone comment on as why this is?  We have discussed
>>> this in firm and we thought that 'classpath' or 'java-bin' or simiar
>>> would be more appropriate as its not just jars that go on the
>>> classpath for java.  and jar is just the implementation that you want
>>> to place there.
>>> We are not going to change from the standard 'jar' now.  too much risk
>>> but we were wondering if anyone can remember why it was decided to
>>> use this standard and not something less implementation specific (like
>>> you suggest with 'src'/'sources')
>> Well, if you have other kind of type you want to see in your classpath, you would
just add it to the retrieve or cache-patch type attribute.
>> And I think it is better to have more specialized type than the requirement than
the reverse. For instance in maven there are "jar"s and also "bundle"s (osgified jars). "classpath"
here would have may be too generic.
> Thank you for your thoughts.  I think this is a personal thing as to
> how you look at an artifact and how you retrieve.  I don't think
> either way is wrong really, ivy is good enough to cater for each use
> case.  It was purely out of interest that I asked this, as a couple of
> persons in the firm have asked similar questions.
>> Nicolas
> Many thanks for your feedback.
> -- 
> Alex Foreman

View raw message