Please enable JavaScript.

Coggle requires JavaScript to display documents.

maven (phases (package (Creating a jar, produces also MANIFEST.mf and…

- - - - lik pom.properties jest plikiem generowanym przez Maven, który zawiera metadane dotyczące budowanego artefaktu. Jest umieszczany wewnątrz pliku JAR w katalogu META-INF/maven/<groupId>/<artifactId>/. Plik ten zawiera podstawowe informacje o artefakcie, takie jak jego grupa, identyfikator, wersja oraz nazwa.
  - - - process-resources
        
        filtering is disabled by default, works only on build time (<build> section in pom.xml) .
        <build> <resources> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> </resource> </resources> </build>
        
        build lifecycle phase where the resources are copied and filtered (i.e. they are substituted with the values from pom.xml, settings.xml external properties file, or a system property - e.g. in application.properties set property like this
        application.name = ${project.name)
        and it will get the project's name from pom. )
      - generate-resources - generate resources for inclusion in the package.
      - integration-test: process and deploy the package if necessary into an environment where integration tests can be run
      - process-resources - generate any source code for inclusion in compilation.
      - process-classes - post-process the generated files from compilation, for example to do bytecode enhancement on Java classes.
- - - - dependency:copy-dependencies
      - jar:jar
- - - - if parent pom is in not in the direct parent directory, add relativepath attribute <relativePath>../parent/pom.xml</relativePath>
      - if we want the groupId and / or the version of your modules to be the same as their parents, you can remove the groupId and / or the version identity of your module in its POM.
      - If you have several Maven projects, and they all have similar configurations, you can refactor your projects by pulling out those similar configurations and making a parent project. Thus, all you have to do is to let your Maven projects inherit that parent project, and those configurations would then be applied to all of them.
    - - is similar to Project Inheritance. But instead of specifying the parent POM from the module, it specifies the modules from the parent POM.
      - we have to change parent's packaging to pom and add submodules
        <packaging>pom</packaging> <modules> <module>my-module</module> </modules>
      - if you have a group of projects that are built or processed together, you can create a parent project and have that parent project declare those projects as its modules. By doing so, you'd only have to build the parent and the rest will follow.
- - - - Profiles can be activated in the Maven settings, via the <activeProfiles> section. This section takes a list of <activeProfile> elements, each containing a profile-id inside.
      - <settings> ... <activeProfiles> <activeProfile>profile-1</activeProfile> </activeProfiles> ... </settings>
    - - Profiles can be automatically triggered based on the detected state of the build environment. These triggers are specified via an <activation> section in the profile itself. Currently, this detection is limited to prefix-matching of the JDK version, the presence of a system property or the value of a system property. Ranges can also be used
      - <profiles> <profile> <activation> <jdk>[1.3,1.6)</jdk> </activation> ... </profile> </profiles>
- - - - When 2 dependencies refer to different versions of a specific artifact, which one will be included by Maven? The answer here is the “nearest definition”. This means that the version used will be the closest one to our project in the tree of dependencies. This is called dependency mediation. Note that if two dependency versions are at the same depth in the dependency tree, the first declaration wins.
        A -> B -> C -> D 1.4 and A -> E -> D 1.0 - here 1.0 will be used
  - - - provided
        
        It indicates that the dependency is provided by JDK or web server or container at runtime,
        
        This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. This scope is only available on the compilation and test classpath, and is not transitive.
        
        Maven dependency scope provided is used during build and test the project. They are also required to run, but should not be exported, because the dependency will be provided by the runtime, for instance, by servlet container or application server.
        
        Zakres provided w Maven jest używany do oznaczenia zależności, które są wymagane podczas kompilacji, ale które będą dostarczane przez środowisko uruchomieniowe (np. serwer aplikacji) podczas działania aplikacji. Oznacza to, że zależności te nie będą pakowane w artefakt końcowy, ponieważ zakłada się, że środowisko uruchomieniowe zapewni te biblioteki.
      - Runtime
        
        This scope indicates that the dependency is not required for compilation, but is for execution. It is in the runtime and test classpaths, but not the compile classpath.
        
        Dependencies with maven dependency scope runtime are not needed to compile, but are part of the classpath to test and run the project.
        
        runtime dependencies are not included in the artifact
      - test
        
        This scope indicates that the dependency is not required for normal use of the application, and is only available for the test compilation and execution phases. This scope is not transitive.
        
        Dependencies with maven dependency scope test are not needed to build and run the project. They are needed to compile and run the unit tests.
      - System
        
        it indicates you have to provide the system path
        
        system dependency
        
        Dependency with scope system is always available and is not looked up in the repository, they are usually used to tell Maven about dependencies that are now provided by the JDK, but were available as separate downloads earlier. Typical example are the JDBC standard extensions. Thus, system dependencies are especially useful for resolving dependencies on artifacts that JDK normally provides.
        
        This scope is similar to provided except that you have to provide the JAR which contains it explicitly. The artifact is always available and is not looked up in a repository.
        
        <project> ... <dependencies> <dependency> <groupId>sun.jdk</groupId> <artifactId>tools</artifactId> <version>1.5.0</version> <scope>system</scope> <systemPath>${java.home}/../lib/tools.jar</systemPath> </dependency> </dependencies> ... </project>
      - import
        
        this indicates that the identified or specified POM should be replaced with the dependencies in that POM’s section
        
        This scope is only supported on a dependency of type pom in the <dependencyManagement> section. It indicates the dependency to be replaced with the effective list of dependencies in the specified POM's <dependencyManagement> section. Since they are replaced, dependencies with a scope of import do not actually participate in limiting the transitivity of a dependency.
        
        Do not attempt to import a pom that is defined in a submodule of the current pom. Attempting to do that will result in the build failing since it won't be able to locate the pom.
      - compile
        
        it is the default scope, and it indicates what dependency is available in the classpath of the project
        
        Compile dependencies are available in all classpaths of a project. Furthermore, those dependencies are propagated to dependent projects.
        
        Scope compile is to be required in most of the cases to resolve the import statements into your java classes sourcecode. Dependencies with compile scope are needed to build, test, and run the project.
    - - is used to limit the transitivity of a dependency, and also to affect the classpath used for various build tasks
      - is used to specify the visibility of a dependency, relative to the different lifecycle phases (compile, test, runtime etc)
      - allows you to only include dependencies appropriate for the current stage of the build
      - helps to make path smaller, which may result in faster build time, smaller artifact size and dependency conflict possibility
  - - - You can mark any transitive dependency as optional using the “optional” element. As an example, A depends upon B and B depends upon C. Now B marked C as optional. Then A will not use C unless you expilcitly add it in A.
      - It may be helpful to think of optional dependencies as "excluded by default".
      - Suppose there is a project named X2 that has similar functionality to Hibernate. It supports many databases such as MySQL, PostgreSQL, and several versions of Oracle. Each supported database requires an additional dependency on a driver jar. All of these dependencies are needed at compile time to build X2. However your project only uses one specific database and doesn't need drivers for the others. X2 can declare these dependencies as optional, so that when your project declares X2 as a direct dependency in its POM, all the drivers supported by the X2 are not automatically included in your project's classpath. Your project will have to include an explicit dependency on the specific driver for the one database it does use.
      - Optional dependencies are used when it's not possible (for whatever reason) to split a project into sub-modules. The idea is that some of the dependencies are only used for certain features in the project and will not be needed if that feature isn't used.
    - - Since Maven resolves dependencies transitively, it is possible for unwanted dependencies to be included in your project's classpath. For example, a certain older jar may have security issues or be incompatible with the Java version you're using. To address this, Maven allows you to exclude specific dependencies. Exclusions are set on a specific dependency in your POM, and are targeted at a specific groupId and artifactId. When you build your project, that artifact will not be added to your project's classpath
      - <dependency> <groupId>sample.ProjectA</groupId> <artifactId>Project-A</artifactId> <version>1.0</version> <scope>compile</scope> <exclusions> <exclusion>  <groupId>sample.ProjectB</groupId> <artifactId>Project-B</artifactId> </exclusion> </exclusions> </dependency>
    - - When you include a maven dependency and it has it’s own other dependencies (i.e. transitive dependencies) then you may want to be clear about the scope of these transitive dependencies as well.
      - provided and test scopes are not transitive so dependencies with such scopes will not be visible if dependency having such dependencies is included in our project.
      - However if those transitive dependencies have scope compile or runtime, then scope explicitly stated in our project on dependency will always propagate to transitive dependencies, except transitive dependency with scope runtime and explicit dependency in our project with scope compile - only then scope of trans. dep. will be runtime.
- - - - contains 2 folders: classes (holds java compiled classes written by us) and lib (which contains jars of libraries used by us)
    - - contains MANIFEST.MF file and maven folder
      - example of MANIFEST.MF
        
        Manifest-Version: 1.0 Implementation-Title: Spring Boot Atmosphere Sample Implementation-Version: 2.2.4.RELEASE Start-Class: sample.atmosphere.SampleAtmosphereApplication Spring-Boot-Classes: BOOT-INF/classes/ Spring-Boot-Lib: BOOT-INF/lib/ Build-Jdk-Spec: 1.8 Spring-Boot-Version: 2.2.4.RELEASE Created-By: Maven Archiver 3.4.0 Implementation-Vendor: Pivotal Software, Inc. Main-Class: org.springframework.boot.loader.JarLauncher
      - zawiera metadane dotyczące archiwum JAR.
        Plik manifestu może zawierać informacje takie jak wersja pliku JAR, informacje o twórcy, główna klasa do uruchomienia (Main-Class) oraz ścieżki klas (Class-Path).
  - - - use cases
        
        Fat JARs are handy when you need to build an executable JAR file, e.g. a microservice executable. You can package your microservice and all of its dependencies into a single JAR file. This makes execution much easier, because you don't have to list all the JAR files your microservice depends on, on the classpath. That simplifies the command to startup the microservice.
        
        Fat JARs are also handy if you need to package your application inside a Docker container. Instead of having to add each JAR file your application depends on to the Docker container, you only have to add the Fat JAR of our application. Again, this is much shorter, easier, and it makes your Dockerfile independent of what external dependencies (JAR files) your application uses.
      - A Fat JAR (also known as uber-jar) is a single JAR file that contains all the compiled Java classes from your project, and all compiled Java classes from all JAR files your project depends on
      - Plik JAR zawierający swoje zależności (Fat JAR) jest przydatny w sytuacjach, gdzie prostota wdrożenia, kompatybilność wersji bibliotek i izolacja są kluczowe.
      - Spring Boot Maven Plugin automatycznie tworzy Fat JAR, co jest standardem w aplikacjach Spring Boot
      - Nie jest zalecany do użycia jeśli aplikacja jest wdrażana na serwer aplikacyjny (np. Tomcat, WildFly, GlassFish), który już zarządza zależnościami (jak serwlety, JPA), nie ma potrzeby dołączania tych bibliotek do JAR, gdyz w przypadku odpalenia kilku aplikacji na 1 serwerze te zaleznosci moga byc wspoldzielone.
  - - - Plik EAR jest używany do pakowania aplikacji enterprise, które mogą składać się z modułów EJB, modułów webowych (WAR) i modułów aplikacji (JAR), przeznaczonych do wdrożenia na serwerach aplikacyjnych zgodnych z Java EE (np. WildFly, GlassFish).
    - - Plik WAR jest używany do pakowania aplikacji webowych (serwletów, JSP, HTML, JSF) przeznaczonych do wdrożenia na serwerach aplikacyjnych lub serwerach webowych (np. Tomcat, Jetty)
- - - - java
      - resources
    - - java
      - resources
- - - - The default lifecycle handles your project deployment,
      - consists of validate, compile, test, package, verify, install and deploy phases
      - default lifecycle: validate -> initialize -> generate-sources -> process-sources -> generate-resources -> process-resources -> compile -> process-classes -> generate-test-sources -> process-test-sources -> generate-test-resources -> process-test-resources -> test-compile -> process-test-classes -> test -> prepare-package -> package -> pre-integration-test -> integration-test -> post-integration-test -> verify -> install -> deploy
    - - the clean lifecycle handles project cleaning
      - phases: pre-clean, clean, post-clean
    - - the site lifecycle handles the creation of your project's site documentation.
      - phases
        
        pre-site execute processes needed prior to the actual project site generation
        
        site generate the project's site documentation
        
        post-site execute processes needed to finalize the site generation, and to prepare for site deployment
        
        site-deploy deploy the generated site documentation to the specified web server
      - when run, a site with metadata about our project is generated which contians meticulous description of our pject - team developing it, dependencies, plugins, everything. This goal generates site folder in target directory. Inside we can find css, images and html files which form a full-fledged site.,