Hello Xavier, Our projects are all circular dependant and one or more of them in the chain always has a refererence to our 3-4 standard "framework" modules. So when I use Ivy, Ivy goes through the entire graph resolving and downloading all transitive dependencies which when packaged into a war gives me high payloads.
Although I am able to understand at a very generic level that I can indeed prevent these child artifacts from ballooning in size, I am not sure how to go about this technically. If I use configurations in Ivy, does that mean that I can have just 3-4 framework projects which are heavy (ie containing 3rd party jars etc) and all other projects can just refer to their configuration instead of declaring them as dependencies. Is my understanding correct ? If yes, does that mean that child projects/modules can contain just refer to direct dependencies instead of downloading all transitive dependencies in my war's /WEB-INF/lib ? If yes, how can I disable transitive dependency retrieves and switch to a direct dependency retrieval scheme ? Is all this possible with configurations ? I am desperately looking for a way to prevent packaging all transitive dependencies of a war into its /WEB-INF/lib. Thanks a lot Xavier Hanin wrote: > > On 7/11/07, bhatia <[EMAIL PROTECTED]> wrote: >> >> >> Hello, >> >> I am integrating IvyDE in eclipse and also in the system build process. >> The >> problem is that the payload size balloons into 100 MBs+ after recovering >> all >> my transitive dependencies and then packaging them into a war. >> >> I basically Ivy retrieve all transitive deps into my /WEB-INF/lib, >> compile >> the project and make a war file from it. For highly dependant projects, >> my >> war file is running into 400Mb+. >> >> What is the best strategy to deal with this ? Can IBM Websphere app >> server >> run into problems at such payload levels ? I believe there must be some >> better way to manage Dependency Hell. > > > If your war reach 400MB+, you should wonder if everything is required or > not. Generate a graph from your dependencies, and plan a meeting to > discuss > this graph with the development team, to see what they think is really > necessary or not. Then I suggest modifying the module descriptors of the > modules which bring too much dependencies. You can use module exclusion to > cut down the number of dependencies, or use configurations to isolate the > dependencies in smaller groups, selecting the groups only when needed. It > takes some time, but you will really appreciate to have something clean in > the end, and by modifying module descriptors the work done to cut down > things will be reusable in later projects. > > My 2 c. > > Xavier > > Thanks >> Saurabh >> >> -- >> View this message in context: >> http://www.nabble.com/reducing-artifact-payload-size-tf4061211.html#a11538172 >> Sent from the ivy-user mailing list archive at Nabble.com. >> >> > > > -- > Xavier Hanin - Independent Java Consultant > http://xhab.blogspot.com/ > http://incubator.apache.org/ivy/ > http://www.xoocode.org/ > > -- View this message in context: http://www.nabble.com/reducing-artifact-payload-size-tf4061211.html#a11560998 Sent from the ivy-user mailing list archive at Nabble.com.
