Как вы строите "дерево" проектов?

[fish_r]

Общеизвестна рекомендация строить дерево пакетов по принципу -

домен первого уровня.домен второго уровня.дальше что хочешь

Ну, например:

com.nemo.effects.Lights

Я каждый новый проект начинаю с построения структуры подобных папок/пакетов. Но может я неправильно
делаю? Ведь можно сделать просто центральное дерево, напр.: com.nemo.... а от него уже ветки
например: com.nemo.effects.Lights, com.nemo.freelance.phillips.banner, com.nemo.utils и т.д.

Как правильнее делать - централизовано? Или децентрализовано? Т.е. каждый новый
скрипт/проект начинать с создания структуры вложенных папок/пакетов.

Или я, наверное, не правильно рассуждаю. В пакетах храним описание классов, а проектах
их реализация. Так?

[goodguy]

У меня не было ни одного проекта, в котором бы я знал наверняка всю будущую структуру папок.
И вряд ли это вообще возможно.
Да и какая, собственно, разница-то?

[fish_r]

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

У меня не было ни одного проекта, в котором бы я знал наверняка всю будущую структуру папок.
И вряд ли это вообще возможно.
Да и какая, собственно, разница-то?

Ну, разница, примерно, такая же как между грамотным письмом и безграмотным. Разве нет?

Но, я, кажется начинаю "прозревать" . В путях проекта подключаем нужные пакеты (com.greensock., com.etc., и т.д). А сам проект реализует их и поэтому может не иметь такой структуры пакетов, то есть иметь, но уже не такого типа, а согласно своей собственной архитектуре... Как то так...

Добавлено через 30 минут
Тогда, как, например, исходники передавать заказчику? Дергать куски "дерева" - гемморойно. Отдавать всё - тоже не то, что то.

[Crazy]

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

Общеизвестна рекомендация строить дерево пакетов по принципу -

Ну, например:

com.nemo.effects.Lights

Мне нравится такая схема имен пакетов:

В коде под конкретного клиента: com.example.Клиент.Подсистема (несколько лет использовал com.example.Клиент.Проект.Подсистема, но получается громоздко и пользы дополнительной мало). Здесь "Клиент" -- 3-4-символьная аббревиатура (главное, чтоб не матерная... были прецеденты)

В коде, который будет шариться: com.example.Подсистема

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

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

[fish_r]

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

В коде, который будет шариться: com.example.Подсистема

А как клиенту передаешь? Копипастишь в проект?

Добавлено через 2 минуты
Я имею в виду собственные, часто используемые наработки, и сторонние библиотеки

[Crazy]

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

А как клиенту передаешь? Копипастишь в проект?

Добавлено через 2 минуты
Я имею в виду собственные, часто используемые наработки, и сторонние библиотеки

Код живет в subversion. В проект делается checkout отдельных общих модулей + поддерево для конкретного клиента. (Делаем папку под исходники, создаем в ней поддерево для клиента, добавляем в svn. Рядом чекаутим по мере надобности общий код по подсистемам.)

Клиенту отдается с удалением папок .svn

[Bgg]

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

А как клиенту передаешь? Копипастишь в проект?

Добавлено через 2 минуты
Я имею в виду собственные, часто используемые наработки, и сторонние библиотеки

Если сторонние библиотеки удалить, то как клиент потом скомпилирует проект?)

[Crazy]

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

Если сторонние библиотеки удалить, то как клиент потом скомпилирует проект?)

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

[Котяра]

Можно класть код не в один src а в несколько. В FB это обычная практика.
тогда очень легко вытащить отдельно пакет
ru.k0t0vich.supergame.core.engine
и отдельно
ru.k0t0vich.core.utils
т.е. он будут лежать в разных папках, а не в общей ru.k0t0vich.
причём ru.k0t0vich.core.utils может вообще ссылаться на внешний svn проект.
В FD просто задайте разные classPaths
т.е. src/commonutils
src/supergame

Исходники я обычно отдаю полностью со всей структурой. Если используются сторонние (или личные) закрытые разработки, то их подключаю сразу в виде swc.
а потом просто svn->export -> zip

По поводу именований. Надо группировать так, чтобы каждый пакет был более менее обособленным. Лучше всего просто посмотрите распространённые фрэймворки, или тот же адобовский код. Придерживайтесь распространённых практик, они может и не самые лучшие, но они общеизвестны.

[fish_r]

Сообщение от Котяра

Исходники я обычно отдаю полностью со всей структурой.

А как это "со всей структурой"? Если я правильно понял - ты подключаешь нужные пакеты к проекту без копипаста. Тогда в export автоматом они не попадают (хотя в svn может и есть "плюшки" не настолько хорошо его знаю). Остается два варианта:
- либо "дергать" нужные пакеты из "дерева" codelib,
- либо отдавать всё скопом, работать будет, но в проект попадают "левые" в данной ситуации классы.
Последнее что ли?