Здравствуйте, lxAlexis, Вы писали:

A>Что я должен настроить, чтобы всё работало правильно?

Чтобы все работало правильно — нужна IntelliJ IDEA

Здравствуйте, denis_krg, Вы писали:

_>Представь себе ситуацию, что у тебя 5 разработчиков. Из них 3 не шибко квалифицированные. Надо оценить — что за фигню они там написали, но быстро, а не роясь в каждом классе. Вот тут то Problems и помогает.

Докаркались
http://www.intellij.net/forums/thread.jspa?threadID=221600&tstart=0

Demetra, build 5261 is available at http://www.intellij.net/eap

Changes in build 5261 from build 5245:

* Code coverage. Global report.
* Highlighting of files containing errors in project view and editor
tab titles.
* Scope "Problems" to display files containing errors.

Complete list of changes: http://jetbrains.net/jira/secure/ReleaseNote.jspa?projectId=10132&styleName=Html&version=10593

_>Опять же, а что означает "стандартные функции VC"? Это на твой взгляд зло. А на мой — еще одна фича, благодаря которой я решаю некоторые свои проблемы. Ну к примеру. Если я много наменял (ну требует этого задача), а тут народ комититься, и это идет вразрез с моими изменениями? Что проще? Я могу посмотреть что они там наделали, взять и смержить, могу отложить, много чего могу.
_>Всем это может быть и не надо. Но опять же, мне лично это уже помогало.

Вообще, когда народ комитится он берет и коммитится. И у него если закомитилось, то дальше это твое дело, коммитится или нет. Ибо мержится всеравно предется. Вот только размах этого мёржа в случае с IDEA будет меньшим.

lxAlexis wrote:
> Здравствуйте, denis_krg, Вы писали:
>
> _>Здравствуйте, lxAlexis, Вы писали:
> [skip]
> Можно в догонку ещё вопрос — где можно прочитать вразумитльную хелпню про .properties-файлы. Я хотел бы с помощью Ant-овых Build-файлов и этих .property-файлов автоматически увеличивать версию апплета при каждой перекомпиляции, но нормальной хелпни не нашёл.

Создаем файл:
-- project.properties ----
version=2.13
build.date=2005/11/03 14\:23
build=0090
--------------------------

В build.xml прописываем:
<target name="build-number-update">
<propertyfile file="${source.dir}/project.properties">
<entry key="build" type="int" operation="+" pattern="0000"
value="1"/>
<entry key="build.date" type="date" value="now"/>
</propertyfile>
<property file="${source.dir}/project.properties"/>
</target>

Теперь после выполнения build-number-update обновится project.properties.
Также в build.xml можно будет использовать переменные build, version,
build.date. Например так:

<property name="full.version" value="${version}.${build}"/>
<property name="zip.name" value="${ant.project.name}-${full.version}"/>

<jar jarfile="${zip.file}"
manifest="${source.dir}/META-INF/MANIFEST.MF">
<fileset dir="${build.classes}/">
<include name="..."/>
<exclude name="..."/>
</fileset>
</jar>

---
Самурай без меча подобен самураю с мечом, но только без меча

Здравствуйте, denis_krg, Вы писали:

_>1. Problems показывает состояние сразу всего проекта. Причем тут не ошибки важны, а warning'и. В ИДЕЕ вообще ничего на эту тему нет.
И очень хорошо, что в ИДЕИ нет этой дурацкой инкрементальной автокомпиляции. Знаем, что это очень круто. Знаем, знаем.
_>2. Работа с CVS в чем-то гораздо хуже (при редактировании), но при синхронизации зато можно увидеть — что же там народ наменял и решить — брать или не брать.
Все навески над стандартными функциями Version Control — это зло, приводящее к проблемам в репозитории. И в голове. У разработчика должен быть последний репозиторий. Он должен знать о проблемах. Он должен орать, что все сломалось. А когда каждый сидит и берет себе только те изменения какие ему нужны, в результате получается такая каша, что собрать ее вообще не возможно. Хотя, да — круто. Это мы тоже знаем.

Здравствуйте, aefimov, Вы писали:

A>3. Перспектив нет

Бесперспективняк.

Здравтсвуйте,

Я установил у себя Eclipse 3.2 и у меня появились проблемы с компиляцией проекта. Почему-то при начале копмиляции .class файлы стираются и потом новые не создаются. То есть компиляция не производится. Что я должен настроить, чтобы всё работало правильно?

Спасибо.

Здравствуйте, lxAlexis, Вы писали:

A>Здравтсвуйте,

A>Я установил у себя Eclipse 3.2 и у меня появились проблемы с компиляцией проекта. Почему-то при начале копмиляции .class файлы стираются и потом новые не создаются. То есть компиляция не производится. Что я должен настроить, чтобы всё работало правильно?

A>Спасибо.

Каким образом компилируешь?

Здравствуйте, Beard-electronic, Вы писали:

BE>Здравствуйте, lxAlexis, Вы писали:

A>>Здравтсвуйте,

A>>Я установил у себя Eclipse 3.2 и у меня появились проблемы с компиляцией проекта. Почему-то при начале копмиляции .class файлы стираются и потом новые не создаются. То есть компиляция не производится. Что я должен настроить, чтобы всё работало правильно?

A>>Спасибо.

BE>Каким образом компилируешь?

Меню Run->Run As...->Java Application

Здравствуйте, lxAlexis, Вы писали:


A>Меню Run->Run As...->Java Application

Сделай Project\Clean или поставь Project\Build Automatically

Здравствуйте, lxAlexis, Вы писали:

BE>>Каким образом компилируешь?

A>Меню Run->Run As...->Java Application

Это ж запуск. В эклипсе все не как у всех. Т.е. ты что-то изменил в сорцах, сохранил — автоматом компиляется. Если что — в окне Problems появляются ошибки (красным).

Следствия следующие:
1. Быстрый запуск приклад, так как не требуется стадия компиляции
2. Постоянный контроль правильности софта. По-крайней мере с точки зрения компиляции его.
3. На более менее крупных проектах есть тормоза, если меняется что-то, что используется везде. А так зависимости четко определяет.

Здравствуйте, denis_krg, Вы писали:

_>Здравствуйте, lxAlexis, Вы писали:

BE>>>Каким образом компилируешь?

A>>Меню Run->Run As...->Java Application

_>Это ж запуск. В эклипсе все не как у всех. Т.е. ты что-то изменил в сорцах, сохранил — автоматом компиляется. Если что — в окне Problems появляются ошибки (красным).

_>Следствия следующие:
_>1. Быстрый запуск приклад, так как не требуется стадия компиляции
_>2. Постоянный контроль правильности софта. По-крайней мере с точки зрения компиляции его.
_>3. На более менее крупных проектах есть тормоза, если меняется что-то, что используется везде. А так зависимости четко определяет.

ОК, всё заработало! ПОл дня убил на это!

Можно в догонку ещё вопрос — где можно прочитать вразумитльную хелпню про .properties-файлы. Я хотел бы с помощью Ant-овых Build-файлов и этих .property-файлов автоматически увеличивать версию апплета при каждой перекомпиляции, но нормальной хелпни не нашёл.

Спасибо

Здравствуйте, lxAlexis, Вы писали:

A>Можно в догонку ещё вопрос — где можно прочитать вразумитльную хелпню про .properties-файлы. Я хотел бы с помощью Ant-овых Build-файлов и этих .property-файлов автоматически увеличивать версию апплета при каждой перекомпиляции, но нормальной хелпни не нашёл.

мы так не делаем. Мы пишем в build.properties версию типа:
buildid=200605021355

Если надо — сами ручками правим. Дату сейчас зашиваем, но будем менять.

Потом можно это в манифест забабахать или еще куда. Это не проблема.

Почему не делаем автоматом — так понимаешь, людей много работает, я, примеру, могу отлаживать вещи, для которых собирать приходится по надцать раз на дню, а может и больше. И что, каждый раз будет версия увеличиваться? Но это все лирика.
А вот как бы я делал, если бы нужно было менять что-то такое? Это вопрос. Нужен конечно внешний файл с последним номером версии. И нужно его менять. У АНТа плохо с этим. Наверное проще свой anttarget написать. Тут ничего посоветовать не могу, смотри доку.

Здравствуйте, aefimov, Вы писали:

A>Чтобы все работало правильно — нужна IntelliJ IDEA

А можно узнать — чем ИДЕЯ хуже, чем Эклипс? )))) Именно хуже, а не лучше.

Здравствуйте, denis_krg, Вы писали:

_>Здравствуйте, aefimov, Вы писали:

A>>Чтобы все работало правильно — нужна IntelliJ IDEA

_>А можно узнать — чем ИДЕЯ хуже, чем Эклипс? )))) Именно хуже, а не лучше.

Она бесплатная?

Здравствуйте, denis_krg, Вы писали:

_>А можно узнать — чем ИДЕЯ хуже, чем Эклипс? )))) Именно хуже, а не лучше.

1. Open API документация
2. Плагинность вообще
3. Перспектив нет (всмысле View перспектив, Debug, Java и т.д.)

Здравствуйте, lxAlexis, Вы писали:

A>Она бесплатная?

Очень не правильно оценивать таким образом IDE.
Она бесплатная в бета версии, она бесплатная для любого Open Source проекта.

Здравствуйте, ettcat, Вы писали:

E> <entry key="build" type="int" operation="+" pattern="0000"

Что-то вы велосипед придумываете.
Есть там стандартная таска — buildnumber называется. И дату сборки проставит и номер проинкрементит.

Здравствуйте, aefimov, Вы писали:

A>Здравствуйте, ettcat, Вы писали:

E>> <entry key="build" type="int" operation="+" pattern="0000"

A>Что-то вы велосипед придумываете.
A>Есть там стандартная таска — buildnumber называется. И дату сборки проставит и номер проинкрементит.

Мне не только для инкремента версий надо. Необходимо там задавать какую-нибудь переменную в определённое значение и чтобы в зависимости от этого значения процесс компиляции шёл по разному (определённые файлы включались/не включались в jar, main-class менялся бы). Это можно сделать через .properties?

Здравствуйте, aefimov, Вы писали:

A>1. Open API документация
A>2. Плагинность вообще
A>3. Перспектив нет (всмысле View перспектив, Debug, Java и т.д.)

Хороший ответ ))) Я бы добавил еще вот какие вещи (на мой вгляд):
1. Problems показывает состояние сразу всего проекта. Причем тут не ошибки важны, а warning'и. В ИДЕЕ вообще ничего на эту тему нет.
2. Работа с CVS в чем-то гораздо хуже (при редактировании), но при синхронизации зато можно увидеть — что же там народ наменял и решить — брать или не брать.

Ну и наверное из основного — все. А так — я сам сидел на ИДЕЕ 3 года, вот, решил перейти. Для кругозору, да есть еще желание оценить Эклипс как RCP-платформу. Ну и попытаться под нее пописать что-нибудь.
А вообще по эргономике Эклипс ИДЕЕ сливает практически везде.

aefimov wrote:
> Здравствуйте, ettcat, Вы писали:
>
> E> <entry key="build" type="int" operation="+" pattern="0000"
>
> Что-то вы велосипед придумываете.
> Есть там стандартная таска — buildnumber называется. И дату сборки проставит и номер проинкрементит.

Читем http://ant.apache.org/manual/CoreTasks/buildnumber.html
Так вот, там есть приписка:
(See the PropertyFile task if you need finer control over things such as
the property name or the number format.)

Собственно для finer control мы используем PropertyFile task (этот
task также входит в поставку ant, как и buildnumber, велосипед уже
придуман за нас).

Хотя buildnumber тоже можно использовать, для большинства случаев
подойдет.

--
Люди делятся на две категории: на тех, кто делит людей на две
категории, и тех, кто не делит.

Здравствуйте, Beard-electronic, Вы писали:

BE>Здравствуйте, lxAlexis, Вы писали:


A>>Меню Run->Run As...->Java Application

BE>Сделай Project\Clean или поставь Project\Build Automatically

Все равно не компилится.... просот не создает classы и все тут.... Уже все preferences перерыли....

lxAlexis wrote:
> Здравствуйте, aefimov, Вы писали:
>
> A>Здравствуйте, ettcat, Вы писали:
>
> E>> <entry key="build" type="int" operation="+" pattern="0000"
>
> A>Что-то вы велосипед придумываете. A>Есть там стандартная таска -
> buildnumber называется. И дату сборки проставит и номер
> проинкрементит.
>
> Мне не только для инкремента версий надо. Необходимо там задавать
> какую-нибудь переменную в определённое значение и чтобы в зависимости
> от этого значения процесс компиляции шёл по разному (определённые
> файлы включались/не включались в jar, main-class менялся бы). Это
> можно сделать через .properties?

Можно.

Задаем в .properties переменную:

main.class=ru.superprogs.Main

Если теперь в таске загрузить эти свойства:
<property file="${home.dir}/build.properties"/>
(см. http://ant.apache.org/manual/CoreTasks/property.html)
то можно использовать переменную ${main.class} для указания mainclass:

<target name="jar">
<property file="${home.dir}/build.properties"/>
<jar destfile="test.jar" basedir=".">
<include name="build"/>
<manifest>
<attribute name="Main-Class" value="${main.class}"/>
</manifest>
</jar>
...

Для управления тасками есть свойства if, unless для target (см.
http://ant.apache.org/manual/using.html#targets):

<target name="jar1" if="generate.jar1">
...

Здравствуйте, lxAlexis, Вы писали:

A>Мне не только для инкремента версий надо. Необходимо там задавать какую-нибудь переменную в определённое значение и чтобы в зависимости от этого значения процесс компиляции шёл по разному (определённые файлы включались/не включались в jar, main-class менялся бы). Это можно сделать через .properties?

Не рекомендую вам смешивать автогенерируеме свойства и ручные. Особенно под Version Control. Выполнением target можно управлять с помощью аттрибутов if и unless. Соответственно, target выполнится если проперьть установлена или неустановлена соответственно.

Проперть установить в зависимости от содержимого проперти из файла можно с помощью таски condition и вложенным в него istrue.

   <property name="my.property" value="true">   

   <condition property="my.Target.enabled">
      <istrue value="${my.property}" />
   </condition>

   <target name="my.Target" if="my.Target.enabled">
   </target>

Здравствуйте, Cider, Вы писали:

C>Здравствуйте, aefimov, Вы писали:

A>>3. Перспектив нет

C>Бесперспективняк.

ОК,

Теперь вроде всё заработало.

И ещё один последний вопрос — как можно к Eclipse подключить исходники Java? Они у меня лежат в виде набора .java-файлов и куда их указать в Eclipse я тоже не нашёл.

Здравствуйте, lxAlexis, Вы писали:


A>И ещё один последний вопрос — как можно к Eclipse подключить исходники Java? Они у меня лежат в виде набора .java-файлов и куда их указать в Eclipse я тоже не нашёл.

Либо Project\Properties\Java Build Path закладка Libraries — там можно jar-ам
приаттачить сорцы и javadoc,
либо Window\Preferences\Installes JREs и там указать

Здравствуйте, aefimov, Вы писали:

A>Здравствуйте, denis_krg, Вы писали:

_>>1. Problems показывает состояние сразу всего проекта. Причем тут не ошибки важны, а warning'и. В ИДЕЕ вообще ничего на эту тему нет.
A>И очень хорошо, что в ИДЕИ нет этой дурацкой инкрементальной автокомпиляции. Знаем, что это очень круто. Знаем, знаем.

Представь себе ситуацию, что у тебя 5 разработчиков. Из них 3 не шибко квалифицированные. Надо оценить — что за фигню они там написали, но быстро, а не роясь в каждом классе. Вот тут то Problems и помогает.

И вообще, лучше, когда можно и так и этак.

_>>2. Работа с CVS в чем-то гораздо хуже (при редактировании), но при синхронизации зато можно увидеть — что же там народ наменял и решить — брать или не брать.
A>Все навески над стандартными функциями Version Control — это зло, приводящее к проблемам в репозитории. И в голове. У разработчика должен быть последний репозиторий. Он должен знать о проблемах. Он должен орать, что все сломалось. А когда каждый сидит и берет себе только те изменения какие ему нужны, в результате получается такая каша, что собрать ее вообще не возможно. Хотя, да — круто. Это мы тоже знаем.

Опять же, а что означает "стандартные функции VC"? Это на твой взгляд зло. А на мой — еще одна фича, благодаря которой я решаю некоторые свои проблемы. Ну к примеру. Если я много наменял (ну требует этого задача), а тут народ комититься, и это идет вразрез с моими изменениями? Что проще? Я могу посмотреть что они там наделали, взять и смержить, могу отложить, много чего могу.
Всем это может быть и не надо. Но опять же, мне лично это уже помогало.

А то, что ты говоришь насчет "каши" в голове у абстрактного разработчика, ну так и каша тогда тоже абстрактная.