2010-02-09 2 views
15

У меня есть проект maven, созданный Spring Roo и использующий несколько инструментов (checkstyle, pmd и т. Д.) Для сбора информации о моем проекте. (А именно я использую codehaus' sonar для этого)Инструменты анализа кода и декларации между типами

Roo makes heavy use of AspectJ Inter Type Declarations (ITD) отделить проблемы, как сохранение, JavaBeans-геттер/сеттеры и т.д.

Эти ITDS-ткут во время компиляции, так как инструменты Checkstyle и PMD (которые работают на исходный уровень) имеют много ложных срабатываний.

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

Любые лучшие идеи?

+0

Я искал это время, а также поговорил с продавцом инструментов для инструментов SCA. Похоже, что это все еще проблема ниши :-( – er4z0r

+0

Мы также используем Roo и Sonar, поэтому мне интересно увидеть ответы на этот вопрос ... –

+0

Ах, чувствую себя хорошо, чтобы не быть единственным. проблемы, о которых я говорю? – er4z0r

ответ

0

Не могли бы вы добавить аннотации/комментарии к конкретному инструменту к Java-коду, чтобы подавить ложные срабатывания? Например, FindBugs имеет собственную аннотацию @SuppressWarnings.

+0

Хмм интересно. Я не знал этого. Хотя это будет работать только на инструменте на основе инструмента, но это может быть отправной точкой. – er4z0r

+0

Согласно документации, вы не должны прикасаться к файлам AspectJ. Эти файлы предназначены для управления самой оболочкой и могут быть обновлены при установке более новых версий Roo – tsunade21

+0

Я имел в виду изменение кода Java, а не ITD; Я обновил свой ответ, чтобы быть более четким. Но, как член команды Roo, приятно видеть, что пользователи знают, что не редактировать ITD!:-) –

1

Сомнение в том, что это будет «проблема ниши» для гораздо более длительного времени :-) Надеемся, что поставщики инструмента будут смотреть на необходимые улучшения.

+0

Ничего себе. Ответ Рода Джонсона. Для меня большая честь :-) Я попросил некоторых продавцов коммерческих инструментов, но ответ еще не принят. Но если я правильно помню, два главных Aspect-J Devs также работают на springsource, может быть, у них есть идея для умного обходного пути? – er4z0r

1

Если вы хотите объяснить исходный код после того, как аспекты были вплетены в код, вы должны сплести аспекты в исходный код, а не в двоичный код.

Многие ткачицы имеют двоичный код, потому что у них нет доступа к информации (таблица символов, имена, типы, типы выражений, ...), создаваемые передним коннектором компилятора. Итак, взломать, используйте код виртуальной машины, созданный компилятором (этот трюк в основном работает только для наборов команд VM, таких как коды .net IL и java), которые часто легко декодировать (красивый, регулярный набор команд), украшенный информация о таблице символов.

Но если вы не можете рассуждать о бинарных результатах такого процесса ткачества, то вы не можете быть уверены, что сплетенная программа не является ошибкой, что является точкой исходного вопроса OP: «Как сделать Я запускаю инструменты SCA на (эффективном) тканом источнике? ».

Вы можете исправить это двумя способами:

  • Получить сообщество писать инструменты SCA, которые обрабатывают байт-коды, а не источник. Это может быть сложно, потому что исходный код может содержать информацию, потерянную в процессе компиляции.
  • Лучшая идея: Получите сообщество аспект, чтобы писать аспектные ткачи, которые работают с исходным кодом и создают исходный код. Это может быть сложно, потому что получение полных языковых интерфейсов затруднено.

Я не могу помочь вам сделать выбор сообщества.

Я могу предложить сильное поощрение, чтобы помочь сообществу выбрать второй способ: наш DMS Software Reengineering Toolkit. Это система преобразования программ, которая выполняет директивы формы «если вы видите это, замените ее на , что», но соблюдая синтаксис и семантику языка, применяя такие изменения к структурам данных компилятора, с помощью полноязычных интерфейсов. (Это программная версия эквациональной замены в математике). Измененные структуры данных могут быть реэкспортированы как компилируемый исходный текст с комментариями.

Если вы понимаете, что могут сделать преобразования вообще, вы можете увидеть это aspect weavers are a special case of program transformation systems. Таким образом, легко использовать для реализации аспектных ткачей с использованием DMS, а результаты - это исходный код, то есть вы можете применить инструменты анализа исходного кода.

Я сомневаюсь, что это на самом деле решает проблему OPS анализа Роо сгенерированный код в краткосрочной перспективе: - {

2

Этот ответ не помог бы вам прямо сейчас, но, надеюсь, это может представлять интерес для Вас, как это обещает решение вашей проблемы в ближайшем будущем. Я не знаю, знаете ли вы IntelliJ IDEA - Java IDE от JetBrains, но в этом направлении уже выполняется работа, и вот ссылка на выделенную проблему, которую вы можете захотеть: http://youtrack.jetbrains.net/issue/IDEA-26959. Просто установите часы на него - и получите уведомление, когда функция реализована. IntelliJ IDEA обеспечивает действительно мощный SCA. Таким образом, поддержка ITD также должна быть высокого качества.

+0

Спасибо за подсказку. Несмотря на то, что мне нравится видеть растущую осведомленность о стороне поставщика инструмента, я бы предпочел решение, которое можно использовать с maven2. Я хочу иметь возможность запускать SCA в безголовой среде, такой как сервер CI. Поэтому я не могу себе позволить в зависимости от конкретной IDE. – er4z0r

+0

Можно выполнить проверки кода из maven и на сервере CI, например TeamCity, как это уже сделано для других функций анализа IntelliJ IDEA. Они могут использоваться независимо от IDE и запускаться удаленно на стороне сервера. –

1

И FindBugs, и Cobertura НЕ работают на уровне источника, но на уровне байт-кода. Таким образом, вы должны волноваться в ваших аспектах статически (что также улучшит время запуска приложения) во время компиляции (например, с использованием плагина AspectJ от maven), а не во время загрузки, а затем запускать инструменты статического анализа в байт-коде результата.

+0

Привет, я проверил его. И ты прав. Большинство ложных срабатываний, которые я получал, пришли из pmd и checkstyle, которые работают на исходном уровне. Тем не менее проблема остается: вы не можете анализировать код, который вы не видите. – er4z0r