Упаковка и доставка protoc, поэтому в наших средах сборки не требуется предварительно устанавливать protoc - PullRequest
Новая
       57

Упаковка и доставка protoc, поэтому в наших средах сборки не требуется предварительно устанавливать protoc

0 голосов
/ 20 декабря 2018

Чтобы иметь возможность генерировать классы из .proto-файлов, в моей системе должен быть установлен protoc .Затем я могу поручить протоколу вручную скомпилировать мои .proto-файлы.Тогда я мог бы получить идею использовать нашу систему сборки для этого, например, есть плагин maven, который выполняет свою работу довольно хорошо, я бы добавил его так: 

<plugin>
    <groupId>org.xolstice.maven.plugins</groupId>
    <artifactId>protobuf-maven-plugin</artifactId>
    <version>0.5.1</version>
    <executions>
        <execution>
            <goals>
                <goal>compile</goal>
                <goal>test-compile</goal>
            </goals>
            <configuration>
                <protocExecutable>protoc</protocExecutable>
            </configuration>
        </execution>
    </executions>
</plugin>

Так что каждый раз, когда явызвать сборку, плагин генерирует мои классы.Все хорошо и хорошо.Но если мы посмотрим на плагин, все еще трудно установить проток в системе, вызывающей сборку: <protocExecutable>protoc</protocExecutable>.

Вопрос теперь

Чтобы это "заработало", все наши разработчики, системы сборки ... должны иметь одинаковую версию буферов протокола в своей системе, иначе сгенерированный код может измениться (или даже сломаться),Это также означает, что по мере старения кода мы не сможем собрать его на всех наших системах сборки, так как установленная версия protoc будет более новой (хорошо, я думаю, вы могли бы поспорить, чтобы установить один protoc для каждой версии и вызвать его, например, protocv3), что потребует дополнительного обслуживания.

Есть ли что-то для протока, как это делает система сборки gradle со своими gradlew, так что в основном это скрипт, который будет пытаться установить конкретный проток в системе, которая выполняет сборку до вызова компилятора?Таким образом, мы сохраняем этот «protow» в нашей VCS с исходным кодом, так же, как вы это делаете с gradlew.Всегда используете «правильную» версию протокола для текущего проекта?

1 Ответ

0 голосов
/ 20 декабря 2018

Стоит отметить, что сгенерированный Java-код для protobuf также привязан к конкретной версии JAR protobuf-java, и двоичная версия protoc также должна соответствовать этому.Поэтому учтите, что в вашем процессе проектирования.

Если вы можете использовать Docker, вы можете использовать / делать что-то вроде этого: https://github.com/namely/docker-protoc

Это решает проблему согласованной версии, локальную разработку, ветви,и т. д. Вы можете легко свернуть свою собственную версию инструмента, на которую ссылаются, в соответствии с вашими потребностями.

Если это не вариант, вы можете рассмотреть возможность публикации артефакта protobufs вашей системой сборки.Это решает вашу проблему согласованности, но является проблемой для локальных разработчиков и филиалов.Это сильно неудовлетворительно, но работает как крайняя мера.

...