I would have you think hard about publishing the artifacts from project A in at the same time you publish artifacts from project B. It sounds like they are dependencies and not publications. Really project A should publish it's artifacts when project A is built. Project A needs it's own Ivy file. Then project B should retrieve it project A's jars by dependency declaration when it is built and only publish artifacts for project B. Project B has it's own Ivy file. Really you shouldn't need to publish the project A's jars with project B's jars at all.
This is what transitive dependencies is for. Say there is Project C which wants to use project B. You just declare your dependency on project B and retrieve transitively and it will pull in the A dependencies automatically. I see what you mean now. There is no way to dynamically tell it what jars to publish with a wildcard. Only on dependencies. You will have to declare the artifacts you publish explicitly. This may be on purpose to force you to publish only the project/module's artifacts for the one project. Now you may use ivy:buildlist to publish things in the right order but it will only ever be project A publishing project A's artifacts and project B publishing project B's artifacts. Lets take the example a bit further. Lets say there is a project D that depends on project C and version 1.0 of project A. Lets say that project B depends on version 2.0 of module A. Depending on the dependency declarations you could have a conflict. Where if you are doing the dependency correctly you could have version 2.0 pulled in automatically and evict 1.0 or if they are non-compatible you will get an error and have to manually upgrade the code for project D to version 2.0 and update the dependency to 2.0. This is where the transitive dependencies is handy because you know explicitly which versions you depend on and intended on depending on. You know when you go to resolve dependencies if there are conflicts rather than when you go to compile or execute the code. If you bundle project A with project B then you wouldn't detect a conflict between different project A versions potentially until runtime but most likely at compile time depending on the classpath search order. I could see having an ant task that packages module B and all of it's dependencies in a zip and putting it on a http or ftp server for end users to use kind of like spring will put their zip file with the distro and all dependencies. You certainly could write an ivy file for the zip file to publish it as an artifact. You could build it using a retrieve transitively on module B, package it up, then publish the zip file to an ivy repository under a different name for the composite rather than just the module B although the dependencies would be the same. I could also see having a separate publication for project B that publish the jar artifacts for project B but also a zip where it has it's dependencies in it alone with the jars for B. I would give them two different configurations though. Likewise we will publish the EAR file to ivy which has dependencies inside it but the artifact is the EAR for that project. But it has it's own ivy file. Shawn -----Original Message----- From: Jefferson Magno Solfarello [mailto:jmagno...@gmail.com] Sent: Wednesday, June 15, 2011 7:38 AM To: ivy-u...@ant.apache.org Subject: Re: Transitive dependencies? Hi all, thanks all for the tips, So, on my Project B, I have a distrib directory, from which I publish the artifacts of Project B. Let's suppose I have called <ivy:retrieve> on my Project B and that now I have all the artifacts of Project A in the a 'lib' directory of Project B. So now I have: Project B root /distrib/B1.jar /distrib/B2.jar /distrib/B3.jar /lib/A1.jar /lib/A2.jar /lib/A3.jar How can I use wildcards to publish those artifacts of Project A (lib directory) without declaring them individually? Thanks, Jefferson 2011/6/14 Garner, Shawn <garner.sh...@principal.com> > Cool, I didn't realize it was smart at all. Thanks for pointing it out. > I thought it just created a list to iterate over. > > Shawn > > -----Original Message----- > From: Not Zippy [mailto:notzi...@gmail.com] > Sent: Tuesday, June 14, 2011 9:21 AM > To: ivy-u...@ant.apache.org > Subject: Re: Transitive dependencies? > > Actually there is an ant tag which does a "smart" build "ivy:buildlist" > will > ensure that the builds are performed in the correct order. > > On Tue, Jun 14, 2011 at 9:15 AM, Garner, Shawn > <garner.sh...@principal.com>wrote: > > > I don't know of a good way directly in Ivy. > > If you use a build server like Jenkins you can trigger another build > after > > the build of the current project. > > > > Without a build server you would have to manually write an ant file that > > builds project A, B, C in order. > > > > There is a Multi-project example in the samples section of the Ivy > > distribution demoing this. The website tutorial goes through it. > > > > Shawn > > > > -----Original Message----- > > From: Jefferson Magno Solfarello [mailto:jmagno...@gmail.com] > > Sent: Tuesday, June 14, 2011 8:43 AM > > To: ivy-u...@ant.apache.org > > Subject: Transitive dependencies? > > > > Hello all, > > > > I have a multi-project setup like this: > > > > Project A publishs 5 artifacts > > > > Project B publishs 3 artifacts > > > > I would like to have a dependency in a way that Project B can publish its > > own artifacts plus the artifacts of Project A. > > > > In the future maybe Proj A publishs more artifacts, I don't want to > declare > > the artifacts published by Proj A on the Ivy file of Proj B. > > > > I could have a Project C, that depends of project B, and when I execute > > <ivy:retrieve> on project C, Ivy downloads all the artifacts published by > B > > (8 artifacts) > > > > Is there a way to do that? > > > > Regards, > > > > Jefferson > > > > > > -----Message Disclaimer----- > > > > This e-mail message is intended only for the use of the individual or > > entity to which it is addressed, and may contain information that is > > privileged, confidential and exempt from disclosure under applicable law. > > If you are not the intended recipient, any dissemination, distribution or > > copying of this communication is strictly prohibited. If you have > > received this communication in error, please notify us immediately by > > reply email to conn...@principal.com and delete or destroy all copies of > > the original message and attachments thereto. Email sent to or from the > > Principal Financial Group or any of its member companies may be retained > > as required by law or regulation. > > > > Nothing in this message is intended to constitute an Electronic signature > > for purposes of the Uniform Electronic Transactions Act (UETA) or the > > Electronic Signatures in Global and National Commerce Act ("E-Sign") > > unless a specific statement to the contrary is included in this message. > > > > While this communication may be used to promote or market a transaction > > or an idea that is discussed in the publication, it is intended to > provide > > general information about the subject matter covered and is provided with > > the understanding that The Principal is not rendering legal, accounting, > > or tax advice. It is not a marketed opinion and may not be used to avoid > > penalties under the Internal Revenue Code. You should consult with > > appropriate counsel or other advisors on all matters pertaining to legal, > > tax, or accounting obligations and requirements. > > > > >
