Mark I will try to comment briefly...
On Fri, Jul 17, 2009 at 9:48 AM, Mark H. Wood<[email protected]> wrote: > I'm tracking down reasons for unexpected consequences of what should > be minor POM tweaking, and I'm puzzled by some of the dependency > declarations. > > For one thing, XMLUI (at least) seems to get most of its dependencies > set up in dspace/modules/xmlui. Shouldn't the stock dependencies be > in dspace-xmlui and its subprojects? I thought that dspace/modules** > was supposed to be essentially empty scaffolding to be filled locally > as needed. Yes, it is indeed just a scaffolding where the dspace-xmlui-xxxx subprojects are combined to produce the end product. But, no, all the third party dependencies should actually should be coming from dspace-xmlui-api or dspace-xmlui-wing where they are required for compilation. You will see that https://scm.dspace.org/svn/repo/dspace/trunk/dspace/modules/xmlui/pom.xml only contains the following while the upstream projects have much greater detail <dependencies> <!-- DSpace XMLUI Languages --> <dependency> <groupId>org.dspace</groupId> <artifactId>dspace-xmlui-lang</artifactId> <type>war</type> </dependency> <!-- DSpace XMLUI Webapp --> <dependency> <groupId>org.dspace</groupId> <artifactId>dspace-xmlui-webapp</artifactId> <type>war</type> </dependency> <!-- DSpace XMLUI API --> <dependency> <groupId>org.dspace</groupId> <artifactId>dspace-xmlui-api</artifactId> </dependency> <dependency> <groupId>javax.servlet</groupId> <artifactId>servlet-api</artifactId> <version>2.3</version> <scope>provided</scope> </dependency> </dependencies> > > For another, 'mvn dependency:analyze' shows a *lot* of "used undeclared" > and "unused declared" dependencies throughout the tree. Shouldn't we > try to keep these cleaned up as much as possible, and document the > reasons for the rest? Well, it forces us into a specific dependency set in those projects. Caution that with IoC/DI, that dependency:analyze can be inacurate because it doesn't take into consideration things like spring configuration. But I did recommend we experiment with refining our dependencies using exclusions. I do not however, think we should be going through and explicity defining all the dependencies that would be transitively resolved in the dspace-xmlui-api/wing poms. > I'm a mere apprentice w.r.t. things Maven, so before I plunge into > this I wanted to stir up some discussion among those more experienced. I know theres some issues arising with 1.5.2 dependency versions right now. So digging into this will be enlightening for us all and worthy of exploration. I recommend publishing your findings and stirring up the 'hornets nest" to get our dependency resolution on track is a noble and honorable task. Cheers, Mark ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
