Hi Tim, I agree, its not ideal to require developers to edit the poms for this purpose. Off the top of my head, could the <resource> element in the UI pom be activated by a profile ? <filtering> would be set to true by default but the developer would need to run 'mvn package -P filterwebxml' , or something similar. I'll try it out if I get time.
Cheers. On 18/10/12 14:45, Tim Donohue wrote: > Hi Robin, > > On 10/18/2012 5:00 AM, Robin Taylor wrote: >> Hi Tim, >> >> I don't think it was a mistake. I think part of the original motivation >> was to simplify the whole business of filtering but it may have been >> simplified at the expense of some useful features. In the short term you >> can cause any web.xml file to be filtered by setting >> <filtering>true</filtering> in the appropriate UI pom, would that >> suffice ? Its set to false by default to allow filtering during the Ant >> phase. > Thanks for the response & suggestion. That could be a possible > workaround. Though, admittedly, I think that's less "developer/IDE > friendly" than before. > > Personally, I'm not a fan of requiring developers to tweak the POM > source code before they can successfully enable webapp debugging in > their IDE. I think that's my main point of frustration here -- it used > to be a simple maven flag you set in your IDE > (-Ddspace.config=[path-to-dspace.cfg]) that let you run a webapp from > your IDE, and now you actually have to dig into Maven POM(s) and edit them. > > If there was a way to support webapp debugging out-of-the-box again > alongside the new build.properties, I think that'd be ideal. I'm gonna > dig around a bit more myself to see if I can get it working & let > everyone know what I come up with. > > If anyone else comes up with other alternatives, let me know. > Essentially, as far as I can tell, running a DSpace webapp from *any* > IDE is not going to work properly unless you edit the POMs. The reason > is that variables in the web.xml files are no longer filtered via Maven > -- instead they get filtered later on via Ant, as Robin mentions. > >> In the long term I think the problem is that we use dspace.cfg to filter >> dspace.dir in web.xml, but dspace.cfg already lives in dspace.dir, its >> all a bit contrary. My feeling is that dspace.dir should be set outwith >> the webapp, by an environment variable or some such, so that the same >> webapp can be used in multiple environments without having to be rebuilt >> or refiltered. > I agree with you on this. The underlying problem is just that we have a > messy way of doing things. I agree too that maybe dspace.dir really > should be a system environment variable (DSPACE_HOME) or something like > that. Something to think about for 4.0 next year. > > - Tim -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
