Выложил свой java-проект на github

*.iml & .idea в гитигнор засунь, зачем нам твои файлы проекта. всякие todo.txt туда же, глупо их держать в гите. кроме того, накатай нормальный ридми, что это, зачем и почему.

Добавил пару предложений в ридми, щас буду пытаться заигнорить лишние файлы.

Положим. Не совсем понятен смысл проекта тогда: интерпретатор с гуем. Я б на твлем месте сделал бы либу для поддержки выполнения кода на лискрипте в jvm. Так, идея.

Смысл - пет прожект, игрушка. Промышленного применения конечно не планировалось. Как обучалочка может еще сойдет. А идея либы интересна.

http://stackoverflow.com/questions/6313126/how-to-remove-a-directory-in-my-gi... так же.

С гитом напрямую не общался, ИДЕЯ предлагала готовые команды - шаре он гитхаб, коммит анд пуш и т.п. Так и жил. А сейчас кнопку заигнорить файл в гите навскидку не найду, а консольное гитовое окно тоже найти надо. Вот и приплыл с таким простом вопросом, жертва ИДЕ где все из коробки, а шаг влево-вправо - уже беспомощен...

Качаю плагин, буду ставить и разбираться )

Создай файл .gitignore, пропиши там игнорируемые файлы.

Создал с помощью плагина, прописал, сам этот файл даже запушился на гитхаб, теперь лишнее с гитхаба удалить пробую.

см. ссылку выше.

И совет для светлого будущего: не надо использовать «commit all» постоянно. У тебя разные вещи изменяются. Добавил .gitignore - коммитай только его. Зачем изменения в исходниках так же коммитать?
Сейчас не важно, будут проекты крупнее - поймешь, что это очень важно.

За совет спасибо. Добрался до консольного гита, параметр --cached он у меня не знает, запустил команду без него - удалил файл и на диске тоже ) Хорошо я копию сделал. С папкой буду пробовать с --cached как-то победить.

Спасибо, с очередного раза все вроде получилось. Такими темпами я и с гитом рискую научиться работать )

прочитай http://www.sbf5.com/~cduan/technical/git/ и https://git-scm.com/book/en/v2/Getting-Started-Git-Basics - полезное.

Вы можете поправить структуру проекта, чтобы удовлетворяла maven dir. structure. А то картинки в той же папке что и исходный код, не очень хорошо. Подробнее про это можно почитать тут https://maven.apache.org/guides/introduction/introduction-to-the-standard-dir... или тут для gradle https://docs.gradle.org/current/userguide/java_plugin.html

ПС: не важно, используйте вы мавен, градл или что ещё, но есть стандарт структуры проекта. Попробуйте его применить.

Спасибо, про гит почитаю. Азы когда-то читал,но забыл банально потому что не применял на практике.

Про структуру проекта - тоже. Я не использую никакие системы сборки, даже не знаю зачем билдить проект - в Идее тестирую и билдю сразу jar-артефакт. Насчет папок - чтобы работали относительные пути, мои внешние файлы мне надо держать рядом (в любых вложенных папках или снаружи) с папкой src. А после сборки jar-ника просто перекопировать их в такой же структуре рядом с ним. Иначе не работают относительные пути в коде. А картинки да, можно положить в другое место. Просто я обрадовался что они так у меня автоматом в jar упаковываются,если лежат в папке исходников. Но наверное это настраивается, что упаковывать.

Если у вас будет структура такая: /src/main/java/*.java и /src/main/resources/images/*.jpeg, то относительные пути до картинок будут работать, так как все будет упаковываться в один classpath.

в реальности никто не билдит проекты в IDE (неважно какой), для производства используется что-то типа Jenkins, он же пускает тесты, он же публикует в репозиторий, итп. Поэтому очень важно чтобы все легко и просто собиралось в консоли

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

более того, хранение зависимостей (jar-ок от которых зависит проект) в папке lib считается плохой практикой. В конце концов это приводит к тому, что для нового участника код твоего проекта начинает скачиваться с гитхаба часами. Garbage collector в гите начинает тормозить. Вместо этого правильно использовать менеджер сборки типа maven.

все вместе приводит к тому, что maven (или gradle - но не рекомендую) является основой любого современного java-приложения. Для helloworld он не нужен, но если предполагается что кто-то твой код будет скачивать и использовать - это сразу maven. Такие дела.

всякие todo.txt туда же, глупо их держать в гите

Зачем? Что, если кто-то захочет pull request сделать с решёнными todo?

issues на гитхабе для этого есть.

Почему не рекомендуешь gradle?

адски тормозит (в последний раз на i7, ssd и 24гб RAM проект (весьма большой, да) собирался минут 10, несмотря на наличие всех артефактов в локальном кэше). Что он там делает, вызывает сотону?

наверное, проблема в том, что там не аналитическая модель, нельзя просто взять одним xpath'ом все депенденси и отправить собираться, а нужно запускать миллионы скриптов

мавен тоже тормозит, но меньше и по другому...

#джаватормозит

Понятно. Интереса ради - на той же машине в тех же условиях мавен за сколько собирает?

Так же, насколько я понимаю (т.е. плохо) как работает gradle, большая доля времени, потраченного на сборку, тратится на инициализации (начальная проверка зависимостей, валидности скрипта, ...). Это решается демонизированием градля, однако все равно первая сборка кажый день будет медленней остальных.

мавеновской версии того же конфига нет, так что ХЗ.
полный ребилд текущего проекта (тоже жирного) занимает 2 минуты. Но вряд ли такое сравнение о чем-то скажет

наверное, надо еще сравнивать болезни конкретной системы сборки.

например, в Мавене нельзя нормально разграничить development и production среды (н-р у нас задача поставить war файл для application server, и мы не можем надеяться что админ скопирует правильные файлы настроек, или тем более пропишет правильные system property). Поэтому есть такой хак - на дженкинсе собирается с выбранным профилем (н-р mvn clean install -Pproduction) и нужные настройки вшиваются в compile time. Чтобы профиль подтянул разные проперти для разных сред, нужно создавать под них отдельный под-модуль с единственным содержимым - src/main/resources внутри которой лежат нужные .properties-файлы. Потом каждый проект включая корневой, на этапе process-resouces например, распаковывает эту jar'ку из локального репозитория, и по отфильтрованным переменным из профиля вытягивает нужные проперти (resource/${environment.name}/${environment.name}.properties например). Вся процедура с распаковкой джарки занимает некое время, может быть небольшое, но когда так начинают делать ВСЕ депенденси, это моментально добавляет ко времени сборки. И такого говна там еще полно. Наверняка в градле тоже есть какие-то такие проблемы, и даже если один и тот же проект сконвертить под разные системы, будут использоваться хаки в разных местах, и снова получится что сравнивать нечего.

Обязателеные минимальные требования к оформлению жабапроекта на гитхубе:

1) readme с указанной лицензией на код 2) ссылка на javadoc для этого кода (на гитхаб-пейджс например) 3) проект абсолютно обязан быть загружен в мавен-централ (в исключительных случаях можно XML сниппет с фед-парти репозиторием), его groupId и artifactId должны быть на самом видном месте в ридми

Если чего-то из вышеуказанного нет - это грубое неуважение к пользователям.

Мимо-по-ссылке-не-ходил

anonymous, смотрели фильм АССА? Там в конце Цою перечисляют правила поведения артиста на сцене и вне ее. Напомнило просто )

blan4 спасибо за структуру. Все в мэйн, классы в джава, картинки в ресурсы в подпапку. А мои внешние демо-файлы куда? Мне они даже в jar-файле не нужны. Мне надо оставить возможность их правки-добавления-удаления и работы приложения с ними через загрузку. Значит однозначно за пределы src? А в готовом приложении рядом с jar-ником? Я покавижу это так. Или есть другие традиции?

takino про maven понял, все про него говорят. Хотел избежать. Но если вдруг будет серьезный проект, то видимо придется с ним.

А что, если придётся мигрировать на другой хостинг репозиториев?

ЗЫ чувствую, что если такие строгие требования к оформлению, то может и хорошо что в кот никто не смотрел )

По коду несколько моментов - прокинь из syntax-подсветчика все данные в конфиг, во-первых
Во-вторых, я был железно уверен, что swing умеет рисовать гуй из xml. http://www.swixml.org/ гуглеж сказал вот что, люди, работающие со свингом может скажут что-то другое.
В-третьих, как правило, если один метод не помещается в один экран, значит, этот метод надо разбить на большее количество методов.
В-четвертых, выше сказали, что надо писать javadoc, и таки да, пиши javadoc, это полезно.


все, естественно, имхо.

зря стараешься, ТС типичный адепт порцедурного поргаммирования: https://github.com/Ivana-/Liscript-GUI-Java-Swing/blob/master/src/com/company...

про конченные автоматы он знает, а про то как потом вносит изменения в это - нет 8)

Спасибо, наконец-то дошли до структуры.

1. Подсветчик. Вижу 2 вещи, которые в принципе можно вынести во внешний конфиг: перечень десятка ключевых слов и само оформление (цвета и т.п.) Слова вынести в конфиг? Но ведь в коде все равно жесткий свитч по ним, и их перечень должен строго соответствовать. Если речь про варианты выделения комментариев например, то это в коде ридера также жестко прописано... Оформление в конфиг? Можно.

2. В xml наверное умеет. Но мне на порядок проще накидать это в коде. К тому же у меня закладки добавляются/удаляются, а раньше и кнопки появлялись/удалялись. Как рисовать статический гуй в xml я представляю, но динамику не знаю как.

3. Методы - да, есть такая буква. Единственно, боюсь вырастут расходы на вызовы. Я не знаю, инлайнит ли java методы сама при оптимизации.

4. javadoc - раз надо, значит надо. Если гитигнор как-то сделал с подсказками, то и javadoc думаю осилю.

http://stackoverflow.com/questions/6495030/java-how-expensive-is-a-method-call

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

ЗЫ javadoc прикольная концепция, не знал про нее :) Обязательно попробую. Заодно и структурировать проект придется лучше, он стимулирует для красивой документации. На ближайшее время фронт доработок ясен. Хорошо когда все работает и нужно только шлифовать-улучшать.

Может, хочешь присоединиться к моей деятельности?

https://bitbucket.org/budden/clcon/overview https://bitbucket.org/budden/l2

Я особо не знаю про swing, но вроде считается, что tcl/tk более легковесный. Касаемо интерпретатора лисп-подобного языка, то наука здесь уже ушла далеко вперёд от того, что ты делаешь. Уже давным-давно (до появления Явы) родились компиляторы лиспа в нативный код, но их всё ещё есть куда развивать. Этим я и занимаюсь.

В целом же основное отличие лиспа от явы, если коротко - Ява сделана для каторги индусов, а Лисп сделан для ощущения себя Богом. Жизнь коротка, успей выбрать правильное состояние.

http://www.swixml.org/

А как с этой штукой работать? Тулкиты, изначально заточенные под декларативное описание ui, типа wpf или javafx, имеют хоть какой-то тулинг - набиваешь xml'ку и в соседнем окне видно что получается. (ну и там layout менеджеры и правила более-менее понятны, как там у свинга честно не знаю - предполагаю что на уровне цпп билдера какого-нибудь)

Так-то набрасывание кнопочек на формочку после WPF кажется делом невероятно низким и противным

Вместо этого правильно использовать менеджер сборки типа maven.

А как он может сократить число загрузок зависимостей?

при наличии кучи проектов, все они шарят примерно одни и те же зависимости

можно передать соседу на флешке все 10 гигабайт своего локального мавен-репозитория

Gerrit, например, перешел с maven на buck

выше сказали, что надо писать javadoc, и таки да, пиши javadoc, это полезно

Узнав немного, что это за зверь, я задался наверное тем же вопросом, которым задаются все - документировать ли приватные поля и методы, или только внешние апи? Смотрел интернеты, там склоняются что не надо. Я тоже думаю, что пользователю класса/пакета достаточно документирования внешних апи, а кто умный - сам слазит в код и посмотрит что там у меня за процедурные конечные автоматы, и никакая документация ему не нужна.

документировать внешние АПИ - само собой. А вот насчёт внутренних недр - это уже как Вам хочется. Но лишней информация никогда не бывает