of their own local build, the dev-context.xml file
is processed last (note: dev-context.xml isn't
part of the source tree itself).
Once this file said:
<import resource="classpath*:alfresco/extension/*-context.xml"/>
Now it ensures dev-context.xml is last via:
<import resource="classpath*:alfresco/extension/*-context.xml"/>
<import resource="classpath*:alfresco/extension/dev-context.xml" />
The order matters if you have a dev-context.xml
that overrides fileServersConfigSource
(which is the "right" way to assert a private version of:
root/projects/repository/config/alfresco/extension/file-servers-custom.xml
It seems weird that we have a checked-in extension like this,
so I supose it's no stranger that the means to override it
should also be a little curious.
Anyway, now my dev-context.xml can say:
<bean id="fileServersConfigSource"
class="org.alfresco.config.source.UrlConfigSource">
<constructor-arg>
<list>
<value>classpath:alfresco/file-servers.xml</value>
<!-- Get the CIFS port from a custom application context config file -->
<!-- <value>classpath:alfresco/extension/file-servers-custom.xml</value> -->
<value>file:/home/jcox/etc/alfresco/file-servers-custom.xml</value>
</list>
</constructor-arg>
</bean>
This allows me to provide *my* file-servers-custom.xml that
won't ever get checked in by mistake, because it only uses
the existing dev-context.xml mechanism.
From there, I can set my CIFS ports.
Whew.
git-svn-id: https://svn.alfresco.com/repos/alfresco-enterprise/alfresco/HEAD/root@4511 c4b6b30b-aa2e-2d43-bbcb-ca4b014f7261
- Single configuration entry point for JCR and non-JCR clients (i.e. application-context.xml)
- Addition of build-war, incremental-war build targets (no deploy)
- Remove build of JCR TCK war file by default
git-svn-id: https://svn.alfresco.com/repos/alfresco-enterprise/alfresco/HEAD/root@2777 c4b6b30b-aa2e-2d43-bbcb-ca4b014f7261
