Во-первых, как в значительной степени все говорят, проверьте XML, если существует схема, определенная для него. (Если нет, определите тот.)
, Но можно создать тесты, которые намного более детализированы, чем это путем выполнения запросов XPath против документа, например:
string xml="Your xml string here" ;
XmlDocument doc = new XmlDocument();
doc.LoadXml(xml);
path = "/doc/element1[@id='key1']/element2[. = 'value2']";
Assert.IsTrue(doc.SelectSingleNode(path) != null);
Это позволяет Вам протестировать не только, действителен ли Ваш документ семантически, но и заполняет ли метод, производящий его, его со значениями, которые Вы ожидаете.
Этот ответ описывает, как расширить подключаемый модуль properties-maven-plugin, чтобы разрешить совместное использование файлов свойств между проектами. Если вы используете этот плагин, свойства будут доступны для сборки и, следовательно, могут использоваться при фильтрации ресурсов.
В качестве альтернативы, вы можете указать файл фильтра как прикрепленный артефакт в некоторой сборке, чтобы он был доступен в репозиторий, затем используйте плагин зависимостей для загрузки файла фильтра и, наконец, укажите, что фильтр использует общий файл.
Чтобы прикрепить фильтр к родительской сборке, используйте build-helper-maven-plugin цель прикрепления:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.3</version>
<executions>
<execution>
<id>attach-artifacts</id>
<phase>package</phase>
<goals>
<goal>attach-artifact</goal>
</goals>
<configuration>
<artifacts>
<artifact>
<file>src/main/resources/shared-filter.properties</file>
<type>properties</type>
<classifier>filter</classifier>
</artifact>
</artifacts>
</configuration>
</execution>
</executions>
</plugin>
Когда проект, в котором размещен фильтр, развернут, фильтр теперь будет прикреплен к нему.
Чтобы загрузить файл фильтра в свой проект, используйте maven-dependency-plugin ' s цель copy-dependencies для загрузки файла:
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>copy</id>
<phase>generate-sources</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>name.seller.rich</groupId>
<artifactId>shared</artifactId>
<version>1.0.0</version>
<classifier>filter</classifier>
<type>properties</type>
<overWrite>false</overWrite>
<destFileName>shared-filter.properties</destFileName>
</artifactItem>
</artifactItems>
<outputDirectory>
${project.build.directory}/filters
</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
Если конфигурация плагина зависимостей определена в вашем родительском проекте, все другие проекты могут унаследовать эту конфигурацию, и не нужно будет переопределять ее.
Затем, чтобы использовать загруженный фильтр. :
<filters>
<filter>${project.build.directory}/filters/shared-filter.properties</filter>
</filters>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
Я не знаю, доступен ли это вариант, но вместо определения свойств во внешнем файле вы также можете определить их в разделе свойств вашего pom.xml
, и вы получите тот же эффект:
<project>
...
<properties>
<my.filter.value>hello</my.filter.value>
</properties>
</project>
Итак, определение
в родительском pom должно позволить вам легко фильтровать дочерние модули.
вы также можете совместно использовать фильтр, используя абсолютный путь для фильтра в родительском файле pom.xml
Поскольку путь зависит от среды (eclipse windows / eclipse linux / buildserver) вы можно указать префикс пути или его часть в профиле settings.xml