Robin, Thanks for the notes...I'll look into this.
I'm currently digging around in a few POMs and have noticed a couple areas that could use minor cleaning alongside the dspace-oai/pom.xml (https://jira.duraspace.org/browse/DS-1340). So, I'm gonna do a bit of minor POM cleanup today & get a pull request done. We'll see if we can then re-enable "dspace.config" (or your filterwebxml option) after the POM cleanup takes place. - Tim On 10/18/2012 10:38 AM, TAYLOR Robin wrote: > Actually if you had <name>dspace.config</name> you could activate it exactly > as before. Unfortunately there is a wee inconsistency in dspace-oai/pom.xml > that needs corrected so you can't do that quite yet. > > Cheers. > > ________________________________________ > From: TAYLOR Robin > Sent: 18 October 2012 16:33 > To: [email protected] > Subject: Re: [Dspace-devel] IDE development issues with DSpace 3.0 + > build.properties > > Very very quickly thrown together so just for discussion, you could do > something like... > > In dspace/pom.xml > > <profiles> > <profile> > <id>filterwebxml</id> > <activation> > <property> > <name>filterwebxml</name> > </property> > </activation> > <properties> > <filter.boolean>true</filter.boolean> > </properties> > </profile> > </profiles> > > and in dspace-jspui/pom.xml > > <filtering>${filter.boolean}</filtering> > > And then activate the profile with 'mvn package -Dfilterwebxml' > > > > On 18/10/12 15:12, TAYLOR Robin wrote: >> 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 > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
