Это должно хорошо обновить веб-приложение Java путем замены просто файлов единого класса?
Нашли это, повозившись. Я предполагаю, что исходные данные добавляются следующим образом:
var data = [{
type: 'scatter3d',
mode: 'lines',
x: x,
y: y,
z: z,
opacity: 1,
line: {
width: 10,
color: c,
reversescale: false
}
}];
Тогда можно также расширить цвет;
var interval = setInterval(function () {
Plotly.extendTraces(my_Div, {
x: [[Math.random()*100]],
y: [[Math.random()*100]],
z: [[Math.random()*100]],
'line.color': [[-1]]
}, [0])
// if (cnt === 100) clearInterval(interval);
}, 100);
5 ответов
Я сказал бы, что, вероятно, не лучшая практика, из-за управления версиями: как Вы знаете, какую версию приложения Вы развернули? При развертывании .war файла процесс сборки может заботиться об обновлении номера сборки (от управления исходным кодом, или отдельно, безотносительно - пока каждая сборка имеет различное число, это в порядке).
Если Вы используете непрерывную интеграцию (и это - определенно хорошая идея быть), затем, Ваш процесс сборки должен выгонять 'артефакт' (военный файл) каждый раз, когда Вы вносите изменения в исходном коде. также, возможно, отмечая код на управлении версиями с номером сборки.
Так, при развертывании веб-приложения Вы знаете точно, какая версия работает и какой исходный код составляет ту версию.
Внесение небольших возрастающих изменений путем обновления отдельных .class файлов, который, как я сказал бы, является, вероятно, не хорошей идеей для чего-либо кроме локального разработчика, тестирующего.
Можно решить задачи развертывания с помощью знатока.
Каждый раз Вы изменяете что-либо, просто вводите
svn update
mvn clean compile war:exploded tomcat:inplace -P deployment
у Вас есть профиль 'развертывания' в Вашем файле pom.xml, содержа весь configuraiton, необходимый для среды развертывания.
этим путем Вы можете событие автоматизировать процесс развертывания и никогда не перестать работать при ручном копировании неправильных/старых/и т.д. файлов.
Согласитесь с PHill; кажется, что экономия времени незначительна, и потенциальные риски - многие
Введение обновленного файла класса в приложение должно только быть сделано на ограниченной основе и не должно быть стандартным действием для сборки. Однако я видел сделанный на крупных приложениях, где все восстанавливает/повторно упаковывает, занял бы часы, и исправление ошибки было необходимо как можно скорее. Надежда это помогает.
С технической точки зрения, пока класс/сигнатуры методов то же, он должен работать. Но поскольку Phill указывает, это не лучшая идея в мире.
Я предполагаю, что Вы ни не используете Муравья Apache, ни Знатока Apache для создания .war файла. Я настоятельно рекомендую, чтобы Вы выбрали инструмент, который может автоматизировать создание .war файла, точно чтобы избежать, чтобы вид ручных взломов как Вы говорил о. Я лично использую Знатока, и это заботится о компиляции, рабочих модульных тестах и упаковке моего приложения. Хороший материал :)