On Thu, Feb 21, 2008 at 10:44 PM, Shawn Castrianni < [EMAIL PROTECTED]> wrote:
> I LOVE IT!!! That adds so much more flexibility to IVY. I also have > always wanted to know what the original dependency constraints were after > publishing, but you can no longer find out after a deliver. > > This extra metadata could also come in handy in the report task when the > dependency graph is created. Right now, if you run the report, you can see > the dependency constraint rules for the direct dependencies of the module > you are reporting on, but all of the indirect (transitive) dependencies are > hardcoded to their specific revision numbers. Have this extra metadata > could allow the report task to put the original dependency constraint rules > on all the edges in the graph and the specific revision numbers inside all > of the nodes. In my opinion, that is a better report of the dependencies of > a module. It shows the constraint rule used and the actual revision found > for all nodes in the graph. Indeed, that'd be nice too. I think we can create 3 issues in JIRA: one to introduce the two kind of versions on the dependency, another one to introduce a new resolve mode to actually use the original version constraint, and a third one for the report improvement (with links between each of them). This will help split the work required, and better represents the changes we can foresee. Xavier Xavier > > > --- > Shawn Castrianni > CM Chief Architect > Landmark > Halliburton Drilling, Evaluation and Digital Solutions Building 2 > 2101 City West Blvd. > Houston, TX 77042 > Work: 713-839-3086 > Cell: 832-654-0888 > Fax: 713-839-2758 > > -----Original Message----- > From: Xavier Hanin [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 21, 2008 3:12 PM > To: [email protected] > Subject: Re: transitive dependency override > > What I dislike with implementing this feature is that it puts more > responsibility to the settings, and from the beginning I've often tried to > avoid putting too much of the resolution logic in the settings, to try to > keep Ivy files self expressive. > > But OTOH I understand your use case. Maybe a better solution (but which > would involve more changes in Ivy) would be to keep two versions > information > per dependency when publishing to the repository : the original version > constraint, and the version that was used when the module was published. I > think this has already been requested before, and I really think it would > be > a good improvement to Ivy, because we actually lose some metadata when > calling deliver. > > Then we could have a mode during resolve which asks to use original > version > constraints instead of delivered ones (maybe per module, to fit your > need). > I think this would better fit in Ivy philosophy, but requires more work, > and > is different from what you asked before. > > WDYT? > > Xavier > > On Thu, Feb 21, 2008 at 9:40 PM, Shawn Castrianni < > [EMAIL PROTECTED]> wrote: > > > Basically if a new indirect dependency is ready and published in the > repo > > and the developer wants to use it now without having to wait for a new > > direct dependency that uses that new indirect dependency to be > published, > > this would come in handy. Or maybe the direct dependency build is > broken so > > the developer can't access the new indirect dependency until the build > is > > fixed. There are other scenarios where explicitly specifying a revision > of > > a module can be useful. But again, I want that control in the settings > file > > so I don't have to change the ivy.xml files. > > > > > > --- > > Shawn Castrianni > > CM Chief Architect > > Landmark > > Halliburton Drilling, Evaluation and Digital Solutions Building 2 > > 2101 City West Blvd. > > Houston, TX 77042 > > Work: 713-839-3086 > > Cell: 832-654-0888 > > Fax: 713-839-2758 > > > > ---------------------------------------------------------------------- > > This e-mail, including any attached files, may contain confidential and > > privileged information for the sole use of the intended recipient. Any > > review, use, distribution, or disclosure by others is strictly > prohibited. > > If you are not the intended recipient (or authorized to receive > information > > for the intended recipient), please contact the sender by reply e-mail > and > > delete all copies of this message. > > > > > > -- > Xavier Hanin - Independent Java Consultant > http://xhab.blogspot.com/ > http://ant.apache.org/ivy/ > http://www.xoocode.org/ > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
