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 ------------------------------------------------------------------------------ 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
