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 <[email protected]>:
>>
>> 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" />
</path>
I don't think this is a workaround, I think this is a clean way to accomplish
it.
Nicolas
>
>>
>>>
>>> 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
