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
