как правильно формировать пакеты?

[fljot]

Greensock надо закинуть в виде swc в соответствующее место, опять таки, определённой версии. И не менять это, чтобы проект был всегда компибилен с ожидаемыми последствиями.

[expl]

вопрос по ответу от Wolsh . а, что тогда с переносимостью?
к примеру один проект делают два человека с разных компьютеров. либо я делаю проект, в котором указываю путь к библиотеке, затем мне нужно перекинуть проект на другой компьютер.
мне придется создавать директории на 2-м компьютере с теми же именами, что на 1-м компьютере.
Поясню. У меня есть директория для моих проектов, я работаю вместе с другим программистом, у него на компе своя директория для хранения проектов. Другой программист может скопировать у меня проект, скомпилировать у себя и проект сразу заработает, а в этом случае мне придется переписывать настройки компиляции?

1. Настройки IDE обычно не комитятся в репозиторий.
Т.е. в самом простом случае при получении кода программист настраивает пути к либам и всему остальному вручную

В более сложном - проект восстанавливается из скриптов автоматической сборки + фала локальных настроек с помощью какой-то тулзы (ничего про это не знаю, не пользовался и возможно ли для FlashBuilder тоже не знаю)

2. Есть ещё автоматическая сборка, но здесь всё гораздо проще - основной скрипт (например, ant) - комитится в репозиторий и одинаков на всех машинах. Файл специфических настроек путей не комитится и туда вносятся только те настройки, с которыми программисту не повезло - которые не совпали с прописанными с скрипте (у автора скрипта обычно таких нет ). Т.е. чтобы что-то собрать на своей машине, программист дописывает пару несовпавших настроек в файл конфигурации ant.

Если голые батники используются - то там сложнее - каждому проггеру нужно написать свой батник, запускающий другой (неизменяющийся) батник с нужными настройками. Батников не один, поэтому лучше использовать ситсемы сборки типа rake(все хвалят, но устанавливается _очень_ тяжело на windows) или ant.

Конечно. А потом, когда эти "ваши библиотеки" изменятся, вы получите пачку неработающих старых проектов. А если даже вести контроль версий "ваших библиотек", то в зависимых проектах придётся где-то сохранять-записывать хэши коммитов, с которыми оно разрабатывалось и работало..

Это палка о 2-х концах:
1. Вынести в либу
+ все баги найденные там будут исчезать во всех проектах
+ новые фитчи будут появлятся во всех проектах
- все изменения в либе надо тщателно проверять, чтобы не поломать предыдущие проекты (поэтому обычно в библиотеке больше всего автоматических тестов)
2. Оставить в проекте
- мучительный копипастинг новых фитч и заплаток
- копипастинг не может проходить без появления багов
+ легкость изменений - не надо обеспечивать совместимость
+ гарантия того, что старые проекты не поломаются

[Владимир Буквин]

Сообщение от Wolsh

Не изменяйте, пишите новые)) На то она и "библиотека", а не папка рабочего проекта. Если Вам нужен не такой класс, как в библиотеке, пишите его в проекте. А по вашей логике можно и в гринсок залезть да переписать там десяток классов под свои нужды....

я не это имел ввиду, я имел ввиду что если мой проект скопирует другой программист, то проект работать у него не будет

[Wolsh]

+ легкость изменений - не надо обеспечивать совместимость

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

+ гарантия того, что старые проекты не поломаются

При "архивации" старого проекта можно скопировать необходимые либы в его корень. Другого способа не вижу))
Важный минус к пункту два: 100500 вариантов вроде бы одного пакета.
p.S. Я не зря говорил о дисциплине))

[expl]

я не это имел ввиду, я имел ввиду что если мой проект скопирует другой программист, то проект работать у него не будет

Сложно найти проект, который не использует ничего внешнего.
Но можно, конечно, каждый раз при изменении своей либы генерить swc и копировать ее в папки с проектом.

При "архивации" старого проекта можно скопировать необходимые либы в его корень. Другого способа не вижу))

Ну да, логично было бы.

Правда в том посте я имел в виду скорее не старый, а "другой" проект, начатый ранее, который тоже развивается относительно активно, и которому могут потребоваться новые фитчи либы и исправление существующих багов.

[Wolsh]

я имел ввиду что если мой проект скопирует другой программист, то проект работать у него не будет

Это решается с помощью разговорной речи. У вас как бы два варианта — либо есть неприкасаемый фрагмент проекта (библиотека), и он должен быть доступен всем участникам — договаривайтесь; либо абсолютно все файлы проекта содержатся в его директории, и тогда один вариант проекта у Вас, и другой вариант будет у него. Если хотите просто "показать" другому, то опять же просто скопируйте библиотеки в проект, компилятор будет видеть их точно так же.

[fish_r]

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

Все редакторы кода позволяют сохранить настройки конкретного проекта. Или не все? Если не позволяет - в топку. Таким образом настройки также можно закоммитить.

При совместной разработке используйте систему версирования, это категорически обязательно - отпадут вопросы по составу классов проекта у других программистов. Впрочем и для индивидуальной разработки svn/git ( кому что удобнее ) очень рекомендуем. Помимо сохранения состояния проекта в каждом отдельном коммите, она позволяет работать над одним и тем же проектом хоть на десятке машин, не копипастя ни одного файла.

[expl]

Все редакторы кода позволяют сохранить настройки конкретного проекта. Или не все? Если не позволяет - в топку. Таким образом настройки также можно закоммитить.

Как-бы проблема в том что настройки путей (и не только путей) у всех разные. И если их коммитить - у всех кодеров поочерёдно будет переставать собираться. Тут нужны более тонкие подходы.
Ладно, с путями к либам ещё можно договорится (хотя бывали случаи что вот лежит либа на D, а у чувака нет такого диска , он согласен, что у всех должно быть одинаково, но изменить путь на D:\workspace\our-libs не может). Но с путями к компилятору, java-машине и т.д. и т.п. такое уже не прокатывает.

При совместной разработке используйте систему версирования

Как будто можно сделать по-другому. Было бы интересно посмотреть на 2-х кодеров, работающих с одним кодом без системы контроля версий.
... хотя, говорят бывает O_o таджик-свн

[fish_r]

Сообщение от expl

Как-бы проблема в том что настройки путей (и не только путей) у всех разные. И если их коммитить - у всех кодеров поочерёдно будет переставать собираться.

Настройки путей? Если используется свн, то классы вы подключаете не через проект, а через свн ( команда externals ), при этом копии нужных классов выгружаются в директорию проекта, сохраняются в копиях созданных экспортом, и в не зависят от последующих изменений в подключенных, оригинальных классах ( правда это надо указать специально).

[Владимир Буквин]

Добавлено через 2 минуты

Сообщение от expl

Было бы интересно посмотреть на 2-х кодеров, работающих с одним кодом без системы контроля версий.

я работаю вместе с другим программистом, над одним проектом, контроль версии не используем, а точнее используем раз в 2 недели, чтоб сохранять проект.
суть такая: я добавляю новый функционал, для чего требуется правка нескольких ранее написанных классов. другой программист так же, при решении своих задач затрагивает эти классы. у другого программиста также есть копия проекта. Я завершаю свою задачу, он свою, затем проекты объединяются в один. Для этого берется копия которая у меня, в нее добавляются классы, которые писал другой программист. классы, которые правились и мной и другим программистом "одновременно" сравниваются по содержимому.
а как тут по другому?

Добавлено через 9 минут

Сообщение от fish_r
Если используется свн, то классы вы подключаете не через проект, а через свн

а что такое свн?