Как лучше всего сохранить информацию о версии Подверсии в EAR?
Как отмечали другие, сброс отсортированного потока записей в обычный HashMap ничего не сделает ... LinkedHashMap - логичный выбор.
Однако альтернативой вышеупомянутым подходам является полное использование API Stream Collectors.
Collectors имеет метод toMap, который позволяет предоставить альтернативную реализацию для Map. Таким образом, вместо HashMap вы можете запросить LinkedHashMap, например, так:
unsortedMap.entrySet()
.stream()
.sorted(Map.Entry.comparingByKey())
.collect(Collectors.toMap(
Map.Entry::getKey,
Map.Entry::getValue,
(v1, v2) -> v1, // you will never merge though ask keys are unique.
LinkedHashMap::new
));
Между использованием TreeMap и LinkedHashMap ... Сложность построения, вероятно, будет такой же, как O ( n log n) ... Очевидно, что решение TreeMap является лучшим подходом, если вы планируете продолжать добавлять к нему больше элементов ... Я думаю, вам следовало начать с TreeMap в этом случае. Опция LinkedHashMap имеет преимущество в том, что поиск будет O (1) на Связанной или исходной несортированной карте, тогда как TreeMap похож на O(log n), так что если вам потребуется сохранить несортированную карту для эффективного поиска, тогда как если вы создадите LinkedHashMap, вы можете сбросить исходную несортированную карту (тем самым сэкономив немного памяти).
Чтобы сделать вещи немного более эффективными с LinkedHashMap, вы должны предоставить хорошую оценку требуемого размера при построении, чтобы не было необходимости динамического изменения размера, поэтому вместо LinkedHashMap::new вы говорите () -> new LinkedHashMap<>(unsortedMap.size()).
Я считаю, что использование TreeMap более изящно ... так как код меньше, так что если нет фактической проблемы с производительностью, которую можно было бы решить с помощью подхода несортированной и отсортированной связанной карты, я бы используйте Tree.
9 ответов
Используйте команду svnversion в своем скрипте Ant для получения числа пересмотра:
<exec executable="svnversion" outputproperty="svnversion" failonerror="true">
<env key="path" value="/usr/bin"/>
<arg value="--no-newline" />
</exec>
Затем используйте $ {svnversion} свойство где-нибудь в Вашем EAR. Мы помещаем его в имя файла EAR, но Вы могли также поместить его в readme или файл версий в EAR, или указать версию в META-INF/manifest.mf EAR:
<!-- myapp-r1234.ear -->
<property name="ear" value="myapp-r${svnrevision}.ear" />
У нас есть первая часть нашей сборки, создают файл version.txt в корне пакета и выводят тег, используемый для проверки кода из (в нашем случае) CVS... Кроме того, заключительная часть нашего процесса сборки перепроверяет полностью созданный EAR в CVS для дальнейшего использования.
Тот путь, если у нас есть проблема с веб-приложением - это - просто случай просьбы, чтобы генератор отчетов поразил /app/version.txt - оттуда мы можем выполнить развертку конкретной истории сборки в CVS для определения местоположения, соответствующие компоненты (обрабатывает различные версии библиотек в приложениях) определять местоположение ошибки.
Не уверенный, сколько справки это нашему народу поддержки - но это - определенно что-то, что они жалуются на то, чтобы не быть там!
Вы хотели бы обеспечить ответвление Подверсии и число репозитория. Как обсуждено в том, Как получить доступ к текущему номеру сборки Подверсии?, svn info команда даст Вам эту информацию, которую можно затем использовать, чтобы создать ФАЙЛ ВЕРСИЙ или поместить в любом из других файлов, которые Вы создаете в Ваш *файлы AR. Если Вы не имеете ничего иного в виду, Вы могли бы рассмотреть использование задачи Ant XmlProperty для извлечения релевантной информации из вывода svn информации - xml команда
Для почему бы не помещения номера сборки в файл свойств..., это может затем быть легко считано Java и произведено к Справке | О диалоговом окне (апплет/приложение), нижний колонтитул веб-страницы или безотносительно другого GUI, который Вы могли бы иметь.
(См., что нижний колонтитул на каждой странице SOF.... имеет номер версии SVN там.)
Кажется загрузкой, легче, чем взгляд в ВОЙНЕ/EAR/JAR и т.д. бездельничанье?
Сделайте автоматические сборки и поместите тег (с отметкой даты) на кодовой базе, когда сборка будет успешна (с unittest, конечно).
В Вашем процессе доставки только поставьте отмеченные сборки клиенту. Таким образом, Вы сознаете ситуацию, и можете поместить имя тега в readme.txt куда-нибудь или иметь имя файла файла уха, отражают tagname.
Я лично переключился назад на CVS, и это - одна из причин. В CVS у меня может быть отчет о классе, это - тег. Все мои файлы банки содержат "основное", которое делает их выполнимыми. С вопросами о поддержке я прошу, чтобы клиент сделал "Java - банка somejar.jar" и отправил вывод мне вместе с вопросом.
Таким образом, я уверен в использовании их-ре сборки, и у меня может даже быть информация как версия Java, тип ОС и версия. Без клиента, имеющего необходимость отвечать на странные вопросы.
Это просто, но очень эффективно.
Я храню абсолютный пересмотр репозитория как часть моего числа полной версии. Это дает людям быстрый взгляд, чтобы видеть, находится ли данное изменение в данной версии или нет.
Мы также храним номер версии / дата сборки / и т.д. в файле манифеста уха как пользовательские свойства, они являются главным образом информационными только. Мы также храним его в файле свойств, который встроен в нашу банку, таким образом, приложение может считать его.
Ознакомьтесь с проектом jreleaseinfo . Содержит задачу ANT, которая может генерировать класс java, который можно вызывать во время выполнения для отображения информации о выпуске вашего проекта.
Мне нравится его простота.
См. Также этот вопрос: Сборка и нумерация версий для проектов Java (ant, cvs, hudson)
Он включает несколько полезных фрагментов кода.