Как Вы “осуществляете рефакторинг” муравья файлы build.xml?

Метод matches() проверяет полное совпадение строк, поэтому вместо этого используйте метод find() , который проверяет соответствие подпоследовательности. Наконец, вы можете использовать метод group() для получения подходящей строки подпоследовательности.

public static void main(String[] args) {
Pattern pattern = Pattern.compile("(?<=pp_).*(?=')");
String input = "['newPage', 'pp_vii', -1])";
Matcher m = pattern.matcher(input);
boolean a = m.find(); 

if(a){
    String out = m.group();
    System.out.println("Match : " + out);
}

14
задан timday 17 April 2009 в 17:41
поделиться

5 ответов

Вы можете быть заинтересованы в:

Проверьте также эту статью на тему « Муравьиные функции для больших проектов ».

13
ответ дан 1 December 2019 в 12:02
поделиться

Если правила повторяются, то вы можете вписать их в макрос ant с помощью macrodef и повторно использовать этот макрос.

Если размер файла неуправляем, то можно разбить его на более мелкие файлы и в основном build.xml вызывать цели в этих файлах.

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

5
ответ дан 1 December 2019 в 12:02
поделиться

Generally, if your build file is large and complex then this is a clear indication that the way you have your code layed out, in terms of folders and packages, it complex and too complicated. I find that a complex ant script is a clear smell of a poorly laid out code base.

To fix this, think about how your code is laid out. How many projects do you have? Do those projects know how to build themselves with a master build script that knows how to bundle the individual projects/apps/components together into a larger whole.

When you are refactoring code, you are looking at ways or breaking things down so that they are easier to understand--smaller methods, smaller classes, methods and classes that do one thing. You need to apply these same principles to your code base as well.

Create smaller components that are functionally cohesive and are very loosely decoupled from the rest of the code. Use a build script to build that component into a library. Do this with the rest of your code. Now create a master build script that knows how to bundle up all of your libraries and build them into your application. If you have several applications, then create build script for each app and a master one that knows how to bundle the apps into distributables.

You should be able to see and understand the layout and structure of your code base just by looking at your build scripts. If they/it is not clean and understandable then neither is your source code.

3
ответ дан 1 December 2019 в 12:02
поделиться

Использовать файлы Antlib. Это очень чистый способ

  1. удалить скопированный / вставленный код
  2. определить значения по умолчанию

Если вы хотите увидеть пример, вы можете взглянуть на некоторые из скриптов сборки I ' пишу для своих проектов в песочнице.

3
ответ дан 1 December 2019 в 12:02
поделиться

I would try Ant-Ivy- the agile dependency manager. We have recently started using it for some of our more complex systems and it works like a charm. The advantage here is that you dont get the overhead and transition cost to maven (it uses ant targets so will work with your current set up). Here is a comparison between the two.

1
ответ дан 1 December 2019 в 12:02
поделиться
Другие вопросы по тегам:

Похожие вопросы: