Прекрасно позволяет. Можно подключить Java-код в виде исходников, можно — в виде скомпилированных классов или jar-файлов, а можно засосать Java-код в MPS и редактировать его уже прямо из MPS.
На этот вопрос у меня заготовлен ответ. Отличительное свойство среды MPS — способность расширять языки, а не только писать их с нуля. То есть замена базового языка не предполагается.
Обычно код сколько-нибудь крупного проекта состоит из трех частей: готовые сторонние библиотеки, библиотеки, содержащие связанные с предметной областью проекта классы и функции, и код, реализующий конкретную функциональность. Сторонние библиотеки и библиотеки предметной области могут также навязывать правила написания кода, например, что каждому классу серверного интерфейса соответствует Javascript «класс», или что рядом с классами, работающими с базой данных, должен лежать соответствующий XML-файл.
Для сторонних библиотек вы можете ожидать, что их поддержка со стороны IDE будет написана сторонними же разработчиками. Со своими собственными библиотеками вам никто не поможет.
С помощью MPS вы можете добавить в IDE знания о своих библиотеках предметной области. И проблема «вавилонского столпотворения» угрожает вам в той же мере, что и без использования MPS. Не стоит в своем проекте использовать плохо совместимые технологии, и точно также надо стараться, чтобы код на ваших DSL выглядел единообразно.
Ничего не мешает. Просто появляется возможность наделить IDE дополнительными «знаниями» об элементах вашей программы. Например, если вы пишите на языке Java, то ваша IDE «знает» только о классах, методах, аннотациях и т.п. Соответственно и рефакторинги, навигацию и подсказки она может выполнять только для элементов языка Java. Что происходит, когда в вашей IDE появляется поддержка некоторой технологии, например, Spring? Она «узнает» о дополнительной семантике вашего кода, и получает возможность, например, искать использования класса не только в Java-коде, но и в XML-файлах Spring.
Конечно, вы можете наделить IDE знаниями о дополнительной семантике конструкций вашей программы, самостоятельно написав плагин для Eclipse или IntelliJ IDEA, но в MPS сделать это значительно проще.
Боюсь, что нами поддержка C# не планируется. По большому счету мы добавляем языки по мере нашей собственной необходимости. То есть те языки, которые необходимы для написания баг-теркера YouTrack и других проектов JetBrains. Поэтому у нас есть поддержка для Java, Javascript, CSS, REST, etc. A для C# — нет.
Хорошая новость состоит в том, что качественную поддержку остальных языков в MPS начали делать люди, не имеющие отношения к JetBrains. Например, компания Realaxy сделала IDE для ActionSctipt на базе MPS. А Markus Völter разрабатывает проект mbedder — Си IDE для встраиваемых систем.
TeamCity — continuous integration сервер. Он интегрирован с большим числом VCS: ClearCase, CVS, Git, Mercurial, Perforce, StarTeam, Subversion, Team Foundation Server, SourceGear Vault, Visual SourceSafe. YouTrack интегрируется с VCS через TeamCity. Это не очень обременительно, потому что у TeamCity есть бесплатная версия. Мы, правда, планируем научиться интегрироваться c VCS напрямую из YouTrack.
1. Баг в одном проекте может ссылаться на баги в других проектах.
2. Для комментария можно указать группу. В этом случае комментарий будет виден только автору комментария и пользователям этой группы.
3. Синтаксис вики для описания багов и комментариев — базовые конструкции MediaWiki.
Вопрос про авторизацию и форварды не совсем понял.
4. Подсветка кода работает на Google Code Prettify.
Интеграция с различными Version Control тоже есть: автоматическое связывание коммитов в репозиторий с багами, выполнение команд из комментариев к коммитам.
Ну, смотрите. До появления YouTrack’а в JetBrains для баг-трекинга использовалась Jira. Там все ок, но, во-первых, на наших объемах багов она сильно тормозила, во-вторых, она предлагала традиционный способ задания фильтров в виде «формы с галочками». То есть искать баги настолько неудобно, что проще воспользоваться одним из сохраненных фильтров, а дальше глазами найти то, что нужно в таблице с результатами. А в YouTrack'е можно искать и по мере необходимости уточнять свой запрос, так быстрее. К тому же YouTrack сам по себе значительно бодрее.
У нас есть фича «недавние поиски» — это в некотором смысле адаптация, о которой вы говорите. Но у сохраненных запросов есть еще дополнительные качества: их можно расшарить с коллегами или вообще со всеми пользователями. Можно подписаться на изменения багов, соответствующих сохраненным запросам. Наконец, бывают длинные запросы, которыми хочется пользоваться каждый день, например, «все открытые критические баги, которые нужно закрыть к ближайшему релизу». Такой запрос можно сохранить, а потом искать в контексте этого запроса.
Под впечатлением от Раскина мы делали UI к нашему баг-трекеру. Графический интерфейс с CLI поиском и CLI модификацией багов. Скорость разгребания багов выросла драматически.
А в текущих что не так?
Эти правила спорные, например:
Также следует помнить, что значимость программного обеспечения не определяется контекстом его использования...
Почему нет?
По поводу нейтральности/рекламности у меня тоже есть пример. Статья написана в нейтральном стиле с ссылками на авторитетные источники, но помечена плашкой «This article is written like an advertisement». На вопрос автора, что следует переделать и является ли некоторая аффилированность автора противопоказанием, ответа нет. Про аффилированность весьма категорично написано в КОИ, но КОИ — это не правило.
Более того, если КОИ станет правилом в том виде, в котором есть сейчас, то узкие специалисты точно ничего не смогут написать, они ведь аффилированы со своей узкой областью.
Обычно код сколько-нибудь крупного проекта состоит из трех частей: готовые сторонние библиотеки, библиотеки, содержащие связанные с предметной областью проекта классы и функции, и код, реализующий конкретную функциональность. Сторонние библиотеки и библиотеки предметной области могут также навязывать правила написания кода, например, что каждому классу серверного интерфейса соответствует Javascript «класс», или что рядом с классами, работающими с базой данных, должен лежать соответствующий XML-файл.
Для сторонних библиотек вы можете ожидать, что их поддержка со стороны IDE будет написана сторонними же разработчиками. Со своими собственными библиотеками вам никто не поможет.
С помощью MPS вы можете добавить в IDE знания о своих библиотеках предметной области. И проблема «вавилонского столпотворения» угрожает вам в той же мере, что и без использования MPS. Не стоит в своем проекте использовать плохо совместимые технологии, и точно также надо стараться, чтобы код на ваших DSL выглядел единообразно.
Конечно, вы можете наделить IDE знаниями о дополнительной семантике конструкций вашей программы, самостоятельно написав плагин для Eclipse или IntelliJ IDEA, но в MPS сделать это значительно проще.
Хорошая новость состоит в том, что качественную поддержку остальных языков в MPS начали делать люди, не имеющие отношения к JetBrains. Например, компания Realaxy сделала IDE для ActionSctipt на базе MPS. А Markus Völter разрабатывает проект mbedder — Си IDE для встраиваемых систем.
2. Для комментария можно указать группу. В этом случае комментарий будет виден только автору комментария и пользователям этой группы.
3. Синтаксис вики для описания багов и комментариев — базовые конструкции MediaWiki.
Вопрос про авторизацию и форварды не совсем понял.
4. Подсветка кода работает на Google Code Prettify.
Интеграция с различными Version Control тоже есть: автоматическое связывание коммитов в репозиторий с багами, выполнение команд из комментариев к коммитам.
DSL с IDE-поддержкой, кажется, удобнее.
У нас есть фича «недавние поиски» — это в некотором смысле адаптация, о которой вы говорите. Но у сохраненных запросов есть еще дополнительные качества: их можно расшарить с коллегами или вообще со всеми пользователями. Можно подписаться на изменения багов, соответствующих сохраненным запросам. Наконец, бывают длинные запросы, которыми хочется пользоваться каждый день, например, «все открытые критические баги, которые нужно закрыть к ближайшему релизу». Такой запрос можно сохранить, а потом искать в контексте этого запроса.
Эти правила спорные, например:
Почему нет?
По поводу нейтральности/рекламности у меня тоже есть пример. Статья написана в нейтральном стиле с ссылками на авторитетные источники, но помечена плашкой «This article is written like an advertisement». На вопрос автора, что следует переделать и является ли некоторая аффилированность автора противопоказанием, ответа нет. Про аффилированность весьма категорично написано в КОИ, но КОИ — это не правило.
Более того, если КОИ станет правилом в том виде, в котором есть сейчас, то узкие специалисты точно ничего не смогут написать, они ведь аффилированы со своей узкой областью.