Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Имя/Название проекта в JAVA. Отличие от имени пакета?

java
Теги: #<Tag:0x00007f7b647b9468>

(Vladislav Zolotaryov) #1

Здравствуйте!

  1. Подскажите пожалуйста, в чём разница между пакетом и проектом в JAVA?
  2. Нашёл правила, которых лучше придерживаться при именовании пакетов, классов, методов и так далее, но не нашёл, как правильно именовать проект!?
  3. Также интересует, как обращаться к уже имеющемуся проекту из другого проекта?

(Nik Sidorenko) #2

Какой средой разработки пользуетесь?


(Vladislav Zolotaryov) #3

Eclipse


(Nik Sidorenko) #4

Вот 2 исвестных мне способа:

  1. Добавить существующий проект в Build Path другого проекта. http://prntscr.com/bjivfu -> http://prntscr.com/bjivxc
    Таким образом Вы настраиваете зависимость между проектами. Затем в нужном классе сделать импорт пакета из подключённого проекта. Оба проекта предварительно должны быть импортированы в один Workplace. Плюс такого подхода - изменения в одном проекте сразу же доступны в другом.
  2. Экспортировать проект в Runnable JAR file http://prntscr.com/bjizyd -> http://prntscr.com/bjj0bt
    А затем подключить к другому проекту как JAR библиотеку. Плюс - Вы не выстраиваете зависимость между проектами. Минус - при обновлении первого проекта нужн делать ре-экспорт.

(5am) #5

по п 2 см
https://google.github.io/styleguide/javaguide.html


(Eugene Moskalenko) #6

Если правильно понял задачу, то можно как-то так разбить на слои, и потом core подгружать в разные проекты:

у меня IDEA, c эклипсом никогда не работал, но думаю все также можно сделать…

в core собственно весь фреймворк лежит со всякими там зависимоятми и константами для фреймворка, domain - еще один слой, в котором лежат (на примере автотестов) - странички, константы для работы с этими страничками и какие-то классы, интерфейсы, контейнеры, хелперы, которые нужны именно для этого слоя. В пакете test - лежат сами тесты…

в pom.xml, для core, указать:

<parent>
        <artifactId>web-somesite</artifactId>
        <groupId>com.somesite</groupId>
        <version>1.0-SNAPSHOT</version>
        <relativePath>..</relativePath>
</parent>

<artifactId>core</artifactId>

можно без relativePath - это типо вложенность относительно родительского пакета

в pom.xml, для domain, указать:

<parent>
    <artifactId>web-somesite</artifactId>
    <groupId>com.somesite</groupId>
    <version>1.0-SNAPSHOT</version>
    <relativePath>..</relativePath>
</parent>

<artifactId>domain</artifactId>

в депенденси pom.xml, для слоя domain, подключаем наш фреймворк из core:

<dependencies>
    <!--Core-->
    <dependency>
        <groupId>com.somesite</groupId>
        <artifactId>core</artifactId>
        <version>1.0-SNAPSHOT</version>
    </dependency>
</dependencies>

а в общем pom.xml сделать так:

<artifactId>web-somesite</artifactId>
<groupId>com.somesite</groupId>
<packaging>pom</packaging>
<version>1.0-SNAPSHOT</version>

<modules>
    <module>core</module>
    <module>domain</module>
</modules>

Я пока еще экспериментирую с данным подходом, но если вылить на какую-то репку core, то его можно будет подключать для разных проектов, как отдельный фреймворк из депенденси и юзать… Чтобы один раз написать более менее универсальное решение, залить на опенсорс (возможно кто-то будет делать грамотные пул-реквесты с рефакторингом и улучшениями) и подключать просто через депенденси, в таком виде:

<dependencies>
    <dependency>
        <groupId>com.somesite</groupId>
        <artifactId>uitest-web</artifactId>
        <version>1.1.55</version>
    </dependency>
</dependencies>

Если что-то подобное спроецировать, на ваше последнее сообщение про парсеры, то можно, нафигачить базовый фреймворк для парсинга с многопоточностью, использованием вебдрайвера или без использования, и потом уже через депенденси подключать этот кусок core в разного рода проекты связанные с парсингом…