Что лучший способ состоит в том, чтобы совместно использовать БАНКИ через несколько проектов?
Основываясь на ответе Конрада Моравского, я создал усовершенствованный метод расширения:
public static MethodInfo GetMethod (this Type i_oContainingType,
string i_sMethodName,
BindingFlags i_enBindingFlags,
Type[] i_aoArgumentType,
bool i_bGeneric)
{
if (i_oContainingType == null)
throw new ArgumentNullException (nameof (i_oContainingType));
var aoMethod = i_oContainingType.GetMethods (i_enBindingFlags);
var listoMethod = new List<MethodInfo> ();
foreach (var oMethod in aoMethod)
{
if (!string.Equals (oMethod.Name, i_sMethodName))
continue;
if (oMethod.IsGenericMethod != i_bGeneric)
continue;
var aoParameter = oMethod.GetParameters ();
if (aoParameter.Length != i_aoArgumentType?.Length)
continue;
int iParamMatch = 0;
for (int ixParam = 0; ixParam < aoParameter.Length; ixParam++)
{
if (aoParameter[ixParam].ParameterType == i_aoArgumentType[ixParam])
iParamMatch++;
}
if (iParamMatch != aoParameter.Length)
continue;
listoMethod.Add (oMethod);
}
if (listoMethod.Count != 1)
{
string sError = "Method with Name '" + i_sMethodName + "' and BindingFlags '" + i_enBindingFlags + "' and Parameter Types '" + i_aoArgumentType?.ToString ("', '") + "'";
if (listoMethod.Count == 0)
throw new MissingMethodException (sError + " has no match.");
else
throw new AmbiguousMatchException (sError + " has " + listoMethod.Count + " matches.");
}
return listoMethod[0];
}
public static MethodInfo GetPrivateInstanceMethod (this Type i_oContainingType,
string i_sMethodName,
Type[] i_aoArgumentType,
bool i_bGeneric)
{
return GetMethod (i_oContainingType, i_sMethodName, BindingFlags.NonPublic | BindingFlags.Instance, i_aoArgumentType, i_bGeneric);
}
public static MethodInfo GetPublicInstanceMethod (this Type i_oContainingType,
string i_sMethodName,
Type[] i_aoArgumentType,
bool i_bGeneric)
{
return GetMethod (i_oContainingType, i_sMethodName, BindingFlags.Public | BindingFlags.Instance, i_aoArgumentType, i_bGeneric);
}
Примечание:
i_aoArgumentType.ToString (..) - это другой метод расширения. Я думаю, вы могли догадаться, что он делает.
7 ответов
Используйте Maven или Ivy для обработки этих общих jar-файлов. Если вы опасаетесь слишком много менять свои проекты, вы можете просто использовать Ivy для управления дополнительным путем к классам для вас.
Оба имеют хорошие плагины Eclipse:
m2eclipse
Контейнер Maven classpath http://img229.imageshack.us/img229/4848/mavendependencies.png
IvyDE
Вы заметите, что оба они ссылаются на jar-файлы за пределами рабочей области, поэтому дублирование удалено.
Обновление (запрашивается комментариями):
Я рекомендую этот подход потому, что твердо верю, что он Проще и яснее объявлять зависимости, а не включать их вручную. С этим связаны небольшие единовременные затраты - меньшие для Ivy, чем для Maven, - но в конечном итоге они окупаются.
Другое, меньшее преимущество - обработка транзитивных и конфликтующих зависимостей. Легко забыть , зачем вам нужен commons-logging-1.1.jar в пути к классам и нужно ли вам обновиться до 1.1.1. И также неинтересно использовать все зависимости, необходимые для , например, комбинацию Hibernate + Annotation + Spring. Сосредоточьтесь на программировании, а не на строительстве.
преимуществом является обработка транзитивных и конфликтующих зависимостей. Легко забыть , зачем вам нужен commons-logging-1.1.jar в пути к классам и нужно ли вам обновиться до 1.1.1. И также неинтересно использовать все зависимости, необходимые для , например, комбинацию Hibernate + Annotation + Spring. Сосредоточьтесь на программировании, а не на строительстве. преимуществом является обработка транзитивных и конфликтующих зависимостей. Легко забыть , зачем вам нужен commons-logging-1.1.jar в пути к классам и нужно ли вам обновиться до 1.1.1. И также неинтересно использовать все зависимости, необходимые для , например, комбинацию Hibernate + Annotation + Spring. Сосредоточьтесь на программировании, а не на строительстве.Вы можете отредактировать «Установленные JRE», чтобы включить ваш JAR-файл («Добавить внешние JAR-файлы»), добавить файл в каталог jdk \ jre \ lib \ ext \ или указать переменную среды CLASSPATH содержащий путь к нему.
Я бы порекомендовал проект «библиотечный».
Но даже лучше - отдельный проект библиотеки для каждого внешнего jar-файла - это позволяет отслеживать зависимости между сторонними jar-файлами и знать, что нужно изменить при обновлении зависимости.
Убедитесь, что вы отметили эти проекты, чтобы все пользователи использовали одни и те же версии сторонних библиотек, и вы могли легко восстановить версию программного обеспечения (используйте теги / метки в вашем управлении версиями, чтобы сгруппировать, какие версии проектов подходят друг другу)
Это зависит от ваших потребностей, но есть несколько жизнеспособных вариантов. В моей работе используется внешняя папка, и все проекты ссылаются на эту папку, что упрощает работу над сборками за пределами eclipse. Пользовательская библиотека - это немного более приятный способ делать что-то, если вы не возражаете против небольшой зависимости от затмения. Я не вижу особой пользы от проекта библиотеки как такового, но если у вас есть какой-то универсальный проект типа «util», который уже загружен всеми другими проектами, вы можете просто поместить все внешние jar-файлы в этот проект.
Вы не поверите, но ваш «утомительный» подход, вероятно, является самым простым, чистым и наименее трудоемким из существующих.
Прежде, чем вскочить на подножку maven, вы должны подумать, что на самом деле не так в том, как вы делаете то, что делаете сейчас. Вы упомянули, что это утомительно и что у вас есть много файлов jar. Я создал процесс сборки для большого многомодульного проекта с помощью Maven, а затем провел следующие 18 месяцев, постоянно борясь с ним. Поверьте мне, это было утомительно, и там валялось много jar-файлов.
После возвращения к Ant и передачи jar-файлов в систему управления версиями вместе с проектами, которые их используют, все прошло гораздо легче. Спасибо за отзыв и обновленные комментарии. Это может показаться немного аргументированным, но, боюсь, я не могу согласиться с вами в том, что Maven проще и понятнее, или что это сэкономит ваше время в долгосрочной перспективе.
Из вашего сообщения:
«Я твердо уверен, что проще и понятнее объявить зависимости, чем включать их вручную. С этим связаны небольшие единовременные затраты - меньше для Ivy, чем для Maven, - но в конечном итоге это окупается»
. ] Возможно, будет проще заставить Maven загрузить файл jar, чем загружать его самостоятельно, но это единственное преимущество. В противном случае Maven не проще, не яснее, а его сложности и ограничения в конечном итоге будут стоить вам денег.
Ясность
Два объявления зависимостей ниже делают то же самое. Я считаю, что Ant намного понятнее, чем Maven.
Ant Style:
<path id="compile.classpath">
<pathelement location="${log4j.jar}" />
<pathelement location="${spring.jar}" />
</path>
Maven Style:
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>${log4j.version}</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
<version>${spring.version}</version>
<scope>compile</scope>
</dependency>
Simplicity
В версии Ant вы можете навести курсор на свойство $ {log4j.jar}, и оно появится покажет вам абсолютный путь к файлу jar. Вы можете искать использование compile.classpath. Там' Вам не намного больше нужно знать.
Нет никаких сомнений в том, что Maven более сложен, чем подход, который я предлагаю. Когда вы начинаете работать с Maven, это лишь некоторые из вопросов, на которые необходимо ответить.
- Что означает groupId?
- Что означает artifactId?
- Откуда взялась банка?
- Где находится банка сейчас?
- Что предоставляется прицел? Кто его предоставляет?
- Как этот jar-файл оказался в моем WAR-файле?
- Почему у этой зависимости нет элемента версии?
- Я не понимаю это сообщение об ошибке. Что, черт возьми, это означает?
- Откуда на Земле этот jar-файл? Я не объявлял об этом.
- Почему у меня есть 2 версии одного и того же файла jar в моем пути к классам?
- Почему проект больше не строится? Ничего не изменилось с тех пор, как я построил его в последний раз.
- Как мне добавить сторонний jar, которого нет в репозитории Maven?
- Скажите мне еще раз, откуда я беру этот плагин Eclipse.
Transitive Dependencies
«Еще одно, меньшее преимущество - это обработка транзитивных и конфликтующих зависимостей »
. По моему опыту, транзитивные зависимости создают больше проблем, чем они того стоят. В итоге вы получаете несколько версий одного и того же файла jar, и в итоге вы получаете дополнительные файлы jar, которые вам не нужны. Я закончил тем, что объявил почти все с предоставленной возможностью, чтобы избежать хлопот.
Долгосрочная выгода
«Сосредоточьтесь на программировании, а не на строительстве».
Я согласен. С тех пор, как я вернулся к Ant и поместил свои файлы jar в систему управления версиями, я смог тратить гораздо меньше времени на решение проблем сборки.
Вот на что я трачу меньше времени:
- Чтение плохой документации Maven.
- Чтение еще более плохой документации Codehaus Mojo.
- Настройка общих внутренних репозиториев.
- Обучение членов команды.
- Написание плагинов Maven для заполнения пробелов.
- Попытка решить эту проблему. обходной путь неисправные плагины (выпуск, сборка).
- Установка плагинов Eclipse для Maven.
- Ожидание, пока плагин вернет мне контроль над Eclipse.
В любом случае, извините за долгую публикацию. Может быть, теперь, когда я избавился от этого, я смогу завершить свой долгий и болезненный опыт Maven. :)
В любом случае, извините за долгую публикацию. Может быть, теперь, когда я избавился от этого, я смогу завершить свой долгий и болезненный опыт Maven. :)
В любом случае, извините за долгую публикацию. Может быть, теперь, когда я избавился от этого, я смогу завершить свой долгий и болезненный опыт Maven. :)
Мы выбрали более утомительный метод, но он позволяет нам иметь все внутри компании, но, вероятно, будет работать только для небольшой группы разработчиков.
Каждый набор файлов jar настроен. как проект Eclipse, названный соответствующим образом после набора jar, добавленный в путь сборки, исходные jar-файлы и javadoc-файлы, правильно установленные для каждого jar в пути сборки, а затем каждый проект включает в себя проекты библиотек, необходимые для этого проекта. Получающееся в результате многопроектное рабочее пространство затем экспортируется в виде файла ProjectSet.psf, который затем может быть прочитан в необработанном Eclipse, снова вводя всю рабочую область. Затем у нас есть все вышеперечисленные проекты в CVS, включая файлы jar.
Это сработало очень хорошо
Если вы работаете в более крупной организации, обработка зависимостей в Maven может сработать для вас. У вас обязательно должен быть локальный кеш артефактов, чтобы весь мир не остановился, если ваше интернет-соединение будет потеряно.
Также обратите внимание, что в новом Eclipse 3.5, выходящем этим летом, будет «Create Runnable Jar», который может выводить необходимые jar-файлы рядом с сгенерированным runnable jar-файлом и правильно настройте строку Class-PAth в манифесте. Надеюсь, это сэкономит много времени - проверьте это.
Один из подходов состоит в том, чтобы поместить все ваши файлы jar в одно место на вашем компьютере, в вашем eclipse ide, определить переменную среды, скажем, LIB_LOCATION, которая указывает на этот каталог, и ваши проекты будут использовать jar относительно этой переменной. Таким образом, вы получаете простоту использования, отсутствие нескольких jar-файлов, переносимых между машинами, если у вас правильно определена переменная. Я пробовал maven для группы проектов приличного размера, и мне кажется, что мне приходится бороться, по крайней мере, столько же, сколько раньше. Ошибки и проводное поведение в плагинах m2eclipse и q4eclipse.