авг 202011
 

Рано или късно, след една, две или няколко преинсталации на операционната система, всеки от нас достига до извода, че трябва да инсталира потребителските програми на дял/твърд диск, различен от системния. Да, но повечето програми, при инсталиране имат предефинирани настройки, които обикновено (поне в случая с Windows) очакват, че инсталацията на сътоветната програма е на системния дял. Подобен е случая и с Eclipse и Maven.

Промяна на Maven хранилището на локалния компютър

Дори Maven да е инсталиран на  дял различен от системния, по подразбиране Maven хранилището  на локалния компютър се очаква, че ще бъде по подразбиране точно на системния дял:

  • за Windows (Vista/7) то е в  C:\Users\<WINDOWS_USERNAME>\.m2\repository
  • за  Linux в ~/.m2/repository

Ако искаме да променим местоположението на локалното хранилище, да бъде на дял различен от системния например, единственото, което е нужно да направим е да променим конфигурационния файл на Maven – settings.xml, намиращ се в инсталационната директория на Maven. За целта, разкоментираме тагът localRepository и добавяме пътя до новата директория, която ще бъде използвана за хранилище:

<settings>
...
<localrepository>/path/to/local/repo/</localrepository>
...
</settings>

В моя случай, промяната изглежда по следния начин:

<settings>
...
<localrepository>D:/config/maven/.m2/repository</localrepository>
...
</settings>

Eclipse и новото хранилище

По подразбиране Eclipse използва собствена инстанция на Maven. За локално хранилище, по подразбиране, използва следните папки:

  • за Windows (Vista/7) в  C:\Users\<WINDOWS_USERNAME>\.m2\repository
  • за  Linux в ~/.m2/repository

Ако инсталираме Maven на място различно от това по подразбиране и конфигурираме локалното хранилище да бъде на място различно от това, което се очаква по принцип, инсталирането на генерираните от Maven архиви (jar,war, и т.н.) в локалното хранилище, ще се записват на новоуказаното място.

Ако не отразим тези промени и в Eclipse, той ще използва собствената инстанция на Maven и собствени настройки за локално Maven хранилище. Съответно, ако Eclipse не намери папката .m2/repository в директорията на текущия потребител (user.home) на системния дял/диск, той я създава и инсталира генерираните архиви от Maven проектите там. Така, компилирането и инсталирането (в термините на Maven) на едни и същи проекти от командния ред и от Eclipse, ще доведе до съхраняването на архивите съответно на две различни места.

Нещо повече, не винаги версията на Maven, която Eclipse използва (M3 за Eclipse 3.6.1 например), съвпада с тази, която използваме в текущия проект (M2 за проекта, по който работя в момента). Както знаем, поради нововъведенията направени във връзка оптимизирането на работата на Maven във версия M3, Maven проектите, компилирани с тази версия са несъвместими с М2 и обратно.

Така можем да обобщим следните проблеми при промяна на локалното хранилище (и инсталация) на Maven, но неотразяването им в Eclipse:

  • Отново съхряняваме потребителски файлове на системния диск (тези генерирани от Eclipse);
  • Нямаме синхронизация при компилирането на проектите през команден ред или през средата за програмиране (компилиране през конзолата не води до промяна в Eclipse);
  • Възможна несъвместимост на файловете генерирани през команден ред и Eclipse в случай, че са използвани различни версии на Maven.

За да ги избегнем, трябва да направим две промени в настройките на Eclipse. Отваряме менюто Window > Preferences и променяме:

  • Указваме на Eclipse да използва новата инсталация на Maven: Maven > Installations > Add... и избираме директорията, %MAVEN_HOME%, която сочи към новата инсталация на Maven и която ще бъде използвана през командния ред.
  • Пренасочваме Eclipse да използва новото хранилище: Maven > User Settings > User Settings > Browse и избираме  местоположението от  settings.xml конфигурационния файл на Maven, което описва къде се намира в новото локално хранилище (обяснено в предходната секция).
По този начин уеднаквяваме версиите на Maven и на Maven хранилището използвани през командния ред и Eclipse.
Share
авг 092011
 
Наков и колектив - Въведение в програмирането със С#

Наков и колектив – Въведение в програмирането със С#

Снощи научих, че официално е излязла и втората книга, в чието писане взех участие – “Въведение в програмирането със С#”.

Малко данни за нея:

Книгата е подробно ръководство по основи на програмирането, структури от данни и алгоритмично мислене. Информацията в нея е изцяло базирана на материала от предшестващата я “Въведение в програмирането с Java”, като на местата, където бе нужно, материалът бе преработен и разширен. Както се подразбира от заглавието на книгата, за илюстрация на концепциите и съпровождащите ги примери, са използвани платформата .NET и езикът C#. Ето и по-синтезирано описание на съдържанието от самият сайт на книгата:

В нея се разглеждат серия уроци по програмиране – от основите на програмирането, среда за разработка, променливи, оператори, масиви и цикли до по-сложни концепции като рекурсия, фундаментални структури от данни и класически алгоритми, списъчни структури, дървета и дървовидни структури, графи, хеш-таблици, оценяване сложността на алгоритми, принципи на обектно-ориентираното програмиране (ООП), LINQ заявки, конструиране на качествен програмен код и решаване на изпитни задачи.

Всяка глава от книгата, следвайки традицията на “Въведение в програмирането  с Java”, е съпътствана с много примери и задачи за упражнение в края на урока. Също така, към книгата има допълнителни материали:

Книгата с отворен код, като електронното издание е безплатно и може да бъде свалено както от официалния сайт – http://www.introprogramming.info/, така и от работния – http://code.google.com/p/introcsharpbook. Книгата може да бъде четена и онлайн на следния адрес – http://www.introprogramming.info/intro-csharp-book/read-online/. По последни данни, хартиеното издание се очаква да излезе в края на септември.

Въпреки, че “Въведение в програмирането с Java” ми е по-любима книга (защото беше първата и защото е свързана с Java), мисля, че “Въведение в програмирането със С#” в доста отношения е по-добра, тъй като наследените печатни грешки от “Въведение в програмирането с Java” са изчистени и с съдържанието е разширено. Въпреки това, намирам мнението на Светлин, че  “Въведение в програмирането с Java” “като цяло не се препоръчва” за начинаещи програмисти, за прекалено крайно. Естествено, той си има своите мотиви да препоръчва новата книга, но според мен и старата книга е изключително качествено четиво и е чудесно ръководство (самоучител) за въведение в програмирането.

Да се надяваме, че с появата на проекти, като тази книга, които събират хора със сходни идеи, интереси и желание да допринасят за обществото без да очакват нещо в замяна, ще се превърнат от единични събития в тенденция и то не само в областта на програмирането. Току виж, все повече хора спрат да се оплакват от състоянието на страната ни, събудят съзидателните сили в себе си и разберат, че единствената надежда да си стъпим на краката като общество и да тръгнем напред се крие в самите нас.

Share
юли 152011
 

Преди месец, на семинар на Българската Java потребителска група, направих презентация, “BDD с JBehave и Selenium”, с която се опитах да представя концепцията за разработка на софтуер ръководена от поведението на софтуера (Behaviour Driven Development) и основите на JBehave (конкретна BDD технология). Презентацията съдържа още и пример, който онагледява как JBehave може да бъде интегриран със Selenium, във връзка с тестването на уеб интерфейси използвайки BDD.

Презентацията може да бъде намерена на профила ми в Slideshare:

Кодът от примерите и самата презентация могат да бъдат свалени също и от Google Code хранилището на групата: http://tinyurl.com/6xoz4sp

Кодът и презентацията са публикувани под CC-BY лиценз.

Share
мар 272011
 
Timothy O'Brien, John Casey, Brian Fox - Maven: The Definitive Guide

Timothy O'Brien, John Casey, Brian Fox - Maven: The Definitive Guide

Автор: Timothy O’Brien, John Casey, Brian Fox
Информация в GoodreadsДа
Налична в Моята библиотека: Не
Оценка: 5/5

Въпреки че книгата е малко старичка (съответно – свързана със по-стара версия на Maven), тя е чудесно въведение в идеите и философията на Maven. Освен това, съдържанието е поднесено по начин следващ педагогическите правила и това допълнително придава още по-голяма ценност на книгата.

Share
окт 102007
 

Във връзка с въпроса:

Къде (и в какъв ред) се търсят *.properties файловете, когато се зареждат с:
ResourceBundle.getBundle(filename)

се поразрових и преведох следната интересна информация:

1) .properties файловете се зареждат от classloader-а, подобно на .java класовете, т.е. трябва местоположението им да е включено в CLASSPATH променливата на средата.

2) .properties файловете имат пълно име (fully-qualified-resource-name), както при .java класовете, с изключение на това, че не може да се извършва import на ресурcи (.properties файлове) в някой .java клас.

3)

ResourceBundle.getBundle("myBundleProps")

указва на classloader-a да зареди ресурс с име myBundleProps в пакета по подразбиране. Това не значи, че ресурса трябва да е в текущия пакет, в който е класа, от който се зарежда.

4)

ResourceBundle.getBundle("package1.package2.package3.myBundleProps")

указва на classloader-a да зареди ресурс myBundleProps с пакет package1.package2.package3. Неговото пълно име (fully-qualified-resource-name) съответно е
package1.package2.package3.myBundleProps.

Т.е. ако директорийната структура на проекта е следната:

project_path
    +-- src
    |      +-- package1
    |            +-- package2
    |                  +-- package3
    |                        +-- TestResourceBundle.java
    +-- classes
           +-- package1
                 +-- package2
                       +-- package3
                             +-- TestResourceBundle.class
                             +-- myBundleProps.properties

и ако в TestResourceBundle.java, ResourceBundel класa се зарежда със следният код:

ResourceBundle myBundleProps = ResourceBundle.getBundle(
                                                   "myBundleProps");

е нужно myBundleProps.properties да се копира в project_path/classes, на същото директорийно ниво на project1 папката. Като алтернатива може да се пакетира myBundleProps.properties в един .jar файл, така че myBundleProps.properties да е в главната директория в .jar архива, който няма никакви поддиректории архивирани в него. След това трябва да се добави този .jar файл в CLASSPATH променливата на средата.

Ако в TestResourceBundle.java се зарежда обект от тип ResourceBundel със следният код:

ResourceBundle myBundleProps = ResourceBundle.getBundle(
                       "package1.package2.package3.myBundleProps");

Тогава е нужно да се копира myBundleProps.properties в
project_path/classes/package1/package2/package3. Като алтернатива, може да се сложи
package1/package2/package3/myBundleProps.properties съответно в един .jar файл (запазвайки директорийната структура на пакетите и в него) и да се добави този .jar файл в CLASSPATH променливата на средата.

Причините за гореописаните начини за употреба на .properties ресурсни файлове са следните:

1) Прозрачност в локализирането на файла – по време на изпълнение на програмата, myBundleProps.properties НЕ е файл, той е просто ресурс, който се зарежда. myBundleProps.properties може да не се съдържа в проекта като цяло, и човека който пише TestResourceBundle.java може изобщо да не види този ресурс. Един URLClassLoader може да го намери в мрежовия път или в URL по време на изпълнение. Това специално е важно за server-side компоненти като EJB, Servlet, JSP и т.н., който по принцип нямат достъп до файловата система. При опит да се получи даден ресурс от classloader, няма значение къде се съхранява съответният ресурс.

2) Mеханизма при работа когато имаш namespaces – конструирайки програмата с пакети, това позволява множество други пакети да съдържат ресурсни файлове (.properties файлове) със същото кратко име (в случая myBundleProps.properties) без това да причинява конфликти в цялата работа на системата. Това е като java пакетите и xml namcesaces.

[Източник: http://blogs.sun.com/chengfang/entry/p_java_util_missingresourceexception_can]

Share