Hi Nicolas, Thanks for the reply.
I am going to go ahead and add AspectJ support into our builds soon. I will respond to the list with how I resolved the problem and then people can use that as a starting point themselves or critique it and come up with a better best practise. On using Jars that have not been published yet I actually use the work around that you suggested. Thanks for the info, it at least means that the solution is not a one off broken solution and gives me confidence that using it is a 'correct' way of dealing with things. Many thanks, 2009/11/21 Nicolas Lalevée <[email protected]>: > > 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 > > -- Alex Foreman
