ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Foreman <Alexander.Fore...@morganstanley.com>
Subject Re: Type and artifacts usage
Date Wed, 18 Nov 2009 09:26:15 GMT
Hi Nicolas,

Thanks for responding.

Comments and Questions replied inline.

2009/11/15 Nicolas Lalevée <nicolas.lalevee@hibnet.org>:
>
> 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?
If its not impossible for impl details or Ivy magic would you like me
to file a JIRA?


>
>>
>> 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 :)

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

Mime
View raw message