ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <nicolas.lale...@hibnet.org>
Subject Re: Type and artifacts usage
Date Sun, 15 Nov 2009 13:23:38 GMT

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" ?

> 
> 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 ?

> 
> 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.
 
Nicolas


Mime
View raw message