mirror of
https://github.com/Alfresco/alfresco-sdk.git
synced 2025-07-31 17:39:14 +00:00
SDK 4.3 (#626)
* Improved the readability of the pom.xml * Introduced 7.1 + upgrade others to the latest version * Handled the new Share's versions separation * Use a variable to set the user in the Dockerfile * Final versions * Updated README [ci skip] * Fixed the broken URL to the new one * Wildcard on the version to prevent further useless updates Co-authored-by: gfertuso <giovanni.fertuso@alfresco.com>
This commit is contained in:
Andrea Ligios
GitHub
@@ -5,7 +5,7 @@ Last reviewed: 2021-02-09
|
||||
---
|
||||
# Working with AMPs
|
||||
|
||||
Since the early days of the Alfresco SDK, the Alfresco Module Packages (AMP) have been the way customizations were packaged. In Alfresco SDK 4.2 everything
|
||||
Since the early days of the Alfresco SDK, the Alfresco Module Packages (AMP) have been the way customizations were packaged. In Alfresco SDK 4.x everything
|
||||
is packaged as a JAR by default, while the AMPs are still available as an optional assembly. This gives you much more control over packaging, and simple
|
||||
modules can easily be deployed as JARs.
|
||||
|
||||
@@ -55,7 +55,7 @@ to your needs.
|
||||
|
||||
## Installing AMPs with the SDK
|
||||
|
||||
The projects created from the Alfresco SDK 4.2 archetypes are configured to deploy either JARs or AMPs to the ACS / Share docker container. The only thing to
|
||||
The projects created from the Alfresco SDK 4.x archetypes are configured to deploy either JARs or AMPs to the ACS / Share docker container. The only thing to
|
||||
do is modify the `pom.xml` file of the corresponding docker module / project in order to properly configure the dependencies and the Maven dependency plugin.
|
||||
|
||||
### All-In-One project
|
||||
@@ -237,7 +237,7 @@ include *.amp in the copy-and-filter-docker-resources-non-filtered
|
||||
## Controlling the order AMPs are applied
|
||||
|
||||
Under some specific circumstances it is necessary to apply different AMPs in a development project in a precise order. The default configuration of the
|
||||
projects generated using the Alfresco SDK 4.2 archetypes doesn't specify any concrete order applying the AMPs to the ACS/Share installation.
|
||||
projects generated using the Alfresco SDK 4.x archetypes doesn't specify any concrete order applying the AMPs to the ACS/Share installation.
|
||||
|
||||
Anyway, that order can be controlled modifying slightly the configuration of the custom Docker images in the project. For instance, let's say we have three
|
||||
third party AMPs that we want to apply in the next order `third-party-amp-01.amp -> third-party-amp-02.amp -> third-party-amp-03.amp`. In this example, we're
|
||||
|
||||
@@ -10,4 +10,4 @@ application server. This section outlines the steps needed to configure Alfresco
|
||||
and to troubleshoot issues by stepping through the code line by line.
|
||||
|
||||
Here we assume you have already generated an Alfresco project using the Alfresco SDK. If you don't have a project already, follow the steps in
|
||||
[Getting started with Alfresco SDK 4.2](../../getting-started.md) to learn how to generate it in a few easy steps.
|
||||
[Getting started with Alfresco SDK 4](../../getting-started.md) to learn how to generate it in a few easy steps.
|
||||
|
||||
@@ -5,7 +5,7 @@ Last reviewed: 2021-02-09
|
||||
---
|
||||
# Remote debugging using Eclipse
|
||||
|
||||
All the projects generated using the Alfresco SDK 4.2 are pre-configured to listen for remote debug connections. Depending on the selected archetypes you'll
|
||||
All the projects generated using the Alfresco SDK 4.x are pre-configured to listen for remote debug connections. Depending on the selected archetypes you'll
|
||||
have a port for remotely debugging ACS, share or both of them.
|
||||
|
||||
By default, the remote debug port for ACS is **8888** and for share is **9898**. This configuration can be changed through the maven properties `acs.debug.port`
|
||||
@@ -79,7 +79,7 @@ application. In our case, we are going to test the behaviour of debugging by run
|
||||
|
||||
8. Open your browser and type `http://localhost:8080/alfresco/s/sample/helloworld`.
|
||||
|
||||
This is a sample webscript generated in every project created using SDK 4.2 and the platform artifact.
|
||||
This is a sample webscript generated in every project created using SDK 4.x and the platform artifact.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ Last reviewed: 2021-02-09
|
||||
---
|
||||
# Remote debugging using IntelliJ
|
||||
|
||||
All the projects generated using the Alfresco SDK 4.2 are pre-configured to listen for remote debug connections. Depending on the selected archetypes you'll
|
||||
All the projects generated using the Alfresco SDK 4.x are pre-configured to listen for remote debug connections. Depending on the selected archetypes you'll
|
||||
have a port for remotely debugging ACS, share or both of them.
|
||||
|
||||
By default, the remote debug port for ACS is **8888** and for share is **9898**. This configuration can be changed through the maven properties `acs.debug.port`
|
||||
@@ -77,7 +77,7 @@ application. In our case, we are going to test the behaviour of debugging by run
|
||||
|
||||
7. Open your browser and type `http://localhost:8080/alfresco/s/sample/helloworld`.
|
||||
|
||||
This is a sample webscript generated in every project created using SDK 4.2 and the platform artifact.
|
||||
This is a sample webscript generated in every project created using SDK 4.x and the platform artifact.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ Last reviewed: 2021-02-09
|
||||
[HotSwapAgent](http://hotswapagent.org/index.html) is the agent that enables you to do hot reloading. This allows you to modify the application code, and
|
||||
view the changes without having to restart Alfresco Tomcat (or the ACS Docker container).
|
||||
|
||||
A prerequisite for this tutorial is to have a project created with the Alfresco SDK 4.2, using the All-In-One archetype or the Platform JAR archetype. It's
|
||||
A prerequisite for this tutorial is to have a project created with the Alfresco SDK 4, using the All-In-One archetype or the Platform JAR archetype. It's
|
||||
worth noting that hot reloading is only supported on the platform, and not in Alfresco Share.
|
||||
|
||||
As an alternative to the HotSwapAgent you can also try out JRebel. It has more features but isn't free.
|
||||
@@ -112,7 +112,7 @@ For more information about HotSwapAgent configuration for Java 8, please check t
|
||||
Using Java 11 and HotSwapAgent, it isn't necessary to configure the java agent and the alternative JVM as in previous versions. Instead, it is required
|
||||
to use an alternative pre-built JDK distribution. That JDK is based on OpenJDK and includes all the required modifications to run the HotSwapAgent properly.
|
||||
|
||||
In the context of the Alfresco SDK 4.2, this change is an issue because the JDK installation is inherited from the [Alfresco java docker image](https://github.com/Alfresco/alfresco-docker-base-java).
|
||||
In the context of the Alfresco SDK 4, this change is an issue because the JDK installation is inherited from the [Alfresco java docker image](https://github.com/Alfresco/alfresco-docker-base-java).
|
||||
It is necessary to modify the project ACS docker image to change the default java installation of the container's OS to the one provided by HotSwapAgent.
|
||||
|
||||
A way to implement the required modifications would be:
|
||||
@@ -250,7 +250,7 @@ You'll recognize HotSwapAgent is working when you see similar log messages:
|
||||
|
||||
2. Before making any changes, let's run the sample webscript by opening your browser and typing `http://localhost:8080/alfresco/s/sample/helloworld`.
|
||||
|
||||
This is a sample webscript generated in every project created using SDK 4.2 and the platform artifact.
|
||||
This is a sample webscript generated in every project created using SDK 4.x and the platform artifact.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ Last reviewed: 2019-10-18
|
||||
[JRebel](https://zeroturnaround.com/software/jrebel/) is the agent that enables you to do hot reloading. This allows you to modify the application code,
|
||||
and view the changes without having to restart Alfresco Tomcat (or the ACS Docker container).
|
||||
|
||||
A prerequisite to this tutorial is having an Alfresco project created with Alfresco SDK 4.2, using the All-In-One archetype, or the Platform JAR archetype.
|
||||
A prerequisite to this tutorial is having an Alfresco project created with Alfresco SDK 4, using the All-In-One archetype, or the Platform JAR archetype.
|
||||
It's worth noting that hot reloading is only supported on the platform, and not in Alfresco Share.
|
||||
|
||||
An open source and free of charge alternative to JRebel is HotSwapAgent. For more details, see the [HotSwapAgent website](http://hotswapagent.org/index.html).
|
||||
|
||||
@@ -11,11 +11,11 @@ in an integration test plan to those aggregates, and delivers as its output the
|
||||
|
||||
Even if the definition of integration testing is a general description, the concept is also valid for Alfresco projects.
|
||||
|
||||
The Alfresco SDK 4.2 keeps the same general idea of integration testing provided by SDK 3.0, but this new version reshapes it slightly to leverage on a
|
||||
The Alfresco SDK 4.x keeps the same general idea of integration testing provided by SDK 3.0, but this new version reshapes it slightly to leverage on a
|
||||
Docker-oriented environment.
|
||||
|
||||
Here are the basics to understanding and using integration testing in the context of projects created with the SDK, from a technical perspective:
|
||||
* SDK 4.2 develops integration tests for the platform only. Currently, the integration tests that the SDK is able to manage by default is related to
|
||||
* SDK 4.x develops integration tests for the platform only. Currently, the integration tests that the SDK is able to manage by default is related to
|
||||
Alfresco Content Services (ACS) only.
|
||||
* Integration tests require an ACS instance to be up and running. You will see that all the scripts and commands are designed to easily manage this
|
||||
requirement, but the prerequisite for the SDK is that an ACS instance is available.
|
||||
|
||||
@@ -5,7 +5,7 @@ Last reviewed: 2021-02-09
|
||||
---
|
||||
# How to run SDK's integration tests
|
||||
|
||||
Running the integration tests of a project generated from the Alfresco SDK 4.2 archetypes is pretty easy. Let's distinguish different cases of executing the
|
||||
Running the integration tests of a project generated from the Alfresco SDK 4.x archetypes is pretty easy. Let's distinguish different cases of executing the
|
||||
integration tests.
|
||||
|
||||
## Command line
|
||||
|
||||
@@ -36,7 +36,7 @@ or set the Java system property `acs.endpoint.path`.
|
||||
|
||||
## Integration tests configuration in the All-In-One project
|
||||
|
||||
So, taking into account the previous section, let's see how the integration tests are configured in a project generated from the SDK 4.2 All-In-One archetype.
|
||||
So, taking into account the previous section, let's see how the integration tests are configured in a project generated from the SDK 4.x All-In-One archetype.
|
||||
|
||||
* The maven dependencies required to execute the integration tests are deployed to the ACS Docker image in the `PROJECT_ARTEFACTID-platform-docker` maven
|
||||
module using the `maven-dependency-plugin`. The configuration is done in the file `PROJECT_ARTEFACTID-platform-docker/pom.xml`:
|
||||
|
||||
@@ -5,7 +5,7 @@ Last reviewed: 2019-10-18
|
||||
---
|
||||
# Switching Alfresco Content Services database
|
||||
|
||||
By default, the projects generated making use of the archetypes provided by the Alfresco SDK 4 are pre-configured to work with a specific database, which is
|
||||
By default, the projects generated making use of the archetypes provided by the Alfresco SDK 4.x are pre-configured to work with a specific database, which is
|
||||
PostgreSQL.
|
||||
|
||||
Anyway, ACS is developed and tested to [support a wide range of platforms and languages](https://www.alfresco.com/services/subscription/supported-platforms).
|
||||
|
||||
@@ -8,7 +8,7 @@ Last reviewed: 2021-02-09
|
||||
The latest version of the Alfresco SDK supports different versions for Alfresco Content Services and Alfresco Share. Since each product is no longer
|
||||
released under one common version number, ACS (i.e. alfresco.war) and the Share UI (share.war) are now released with individual version numbers.
|
||||
|
||||
By default, SDK 4 is configured to generate projects using the most recent version of ACS and Share. You can easily change one (or both) versions by
|
||||
By default, SDK 4.x is configured to generate projects using the most recent version of ACS and Share. You can easily change one (or both) versions by
|
||||
simply updating the `pom.xml` file in your project. The compatibility of these versions is up to you, however you should check in advance the right versions
|
||||
to use.
|
||||
|
||||
@@ -28,7 +28,7 @@ The supported versions are explained in the next sections of this article.
|
||||
|
||||
## Switch to Alfresco version 6.0.x
|
||||
|
||||
Starting from a newly created Alfresco SDK 4.2 project (All-In-One, Platform JAR, or Share JAR), let’s replace the two properties with the following ones.
|
||||
Starting from a newly created Alfresco SDK 4.x project (All-In-One, Platform JAR, or Share JAR), let’s replace the two properties with the following ones.
|
||||
|
||||
1. Open the pom.xml in your generated project.
|
||||
|
||||
@@ -60,7 +60,7 @@ about wrong JDK versions.
|
||||
|
||||
## Switch to Alfresco version 6.1.x or 6.2.x
|
||||
|
||||
Starting from a newly created Alfresco SDK 4.2 project (All-In-One, Platform JAR, or Share JAR), let’s replace the two properties with the following ones.
|
||||
Starting from a newly created Alfresco SDK 4.x project (All-In-One, Platform JAR, or Share JAR), let’s replace the two properties with the following ones.
|
||||
|
||||
1. Open the pom.xml in your generated project.
|
||||
|
||||
|
||||
@@ -3,13 +3,13 @@ Title: Upgrading
|
||||
Added: v4.0.0
|
||||
Last reviewed: 2019-01-29
|
||||
---
|
||||
# Upgrading an SDK 3.0 project to SDK 4.2
|
||||
# Upgrading an SDK 3.0 project to SDK 4
|
||||
|
||||
In these instructions, "base" refers to a freshly instantiated SDK 4.2 and "target" refers to the SDK 3.0.1 project that is being upgraded.
|
||||
In these instructions, "base" refers to a freshly instantiated SDK 4.x and "target" refers to the SDK 3.0.1 project that is being upgraded.
|
||||
|
||||
## Download a base
|
||||
|
||||
Download or instantiate an SDK 4.2 project to use as a base for copying files.
|
||||
Download or instantiate an SDK 4.x project to use as a base for copying files.
|
||||
|
||||
For example, you might create a new project called `test-aio-400` to use as a base from which to copy files into the target project that is to be upgraded.
|
||||
|
||||
@@ -65,7 +65,7 @@ Similar to previous step, the directory should follow the same pattern as the ex
|
||||
|
||||
Need to smartly do this merge so that target project maintains its dependencies, name, version, description, etc.
|
||||
|
||||
1. Copy the entire `<properties>` element from the base 4.2 pom.xml into the target 3.0 pom.xml, replacing the existing one completely.
|
||||
1. Copy the entire `<properties>` element from the base 4.x pom.xml into the target 3.0 pom.xml, replacing the existing one completely.
|
||||
|
||||
2. Change the `acs.host` property to match the target project name.
|
||||
|
||||
@@ -220,7 +220,7 @@ Then that would need to be moved into the share docker module's pom.xml file in
|
||||
|
||||
## Changes to the integration-tests module
|
||||
|
||||
1. Completely replace the pom.xml file with the pom.xml file from the 4.2 pom.xml file under integration-tests.
|
||||
1. Completely replace the pom.xml file with the pom.xml file from the 4.x pom.xml file under integration-tests.
|
||||
|
||||
2. Edit the integration-tests pom.xml to replace references to the base project name with references to the target project name.
|
||||
|
||||
@@ -230,7 +230,7 @@ Then that would need to be moved into the share docker module's pom.xml file in
|
||||
|
||||
## Changes to the platform-jar module
|
||||
|
||||
Smartly merge the pom.xml file from the 4.2 platform-jar module into the existing platform-jar module pom.xml file.
|
||||
Smartly merge the pom.xml file from the 4.x platform-jar module into the existing platform-jar module pom.xml file.
|
||||
|
||||
Maintain the dependencies from the 3.0 platform-jar module pom.xml.
|
||||
|
||||
@@ -238,13 +238,13 @@ Any old "platformModule" dependencies, which are typically AMPs or JARs that nee
|
||||
|
||||
## Changes to the share-jar module
|
||||
|
||||
Smartly merge the pom.xml file from the 4.2 share-jar module into the existing share-jar module pom.xml file.
|
||||
Smartly merge the pom.xml file from the 4.x share-jar module into the existing share-jar module pom.xml file.
|
||||
|
||||
Maintain the dependencies from the 3.0 share-jar module pom.xml.
|
||||
|
||||
Any old "shareModule" dependencies, which are typically AMPs or JARs that need to be installed in the Share tier need to be copied into this pom.xml's depdencies.
|
||||
|
||||
Remove the spring-surf-api dependency from the 4.2 share-jar module. Remove:
|
||||
Remove the spring-surf-api dependency from the 4.x share-jar module. Remove:
|
||||
|
||||
```
|
||||
<dependency>
|
||||
|
||||
@@ -80,7 +80,7 @@ You'll need to update the following settings in the `pom.xml` file:
|
||||
<alfresco.share.version>6.2.0</alfresco.share.version>
|
||||
```
|
||||
|
||||
Making use of the Alfresco SDK 4 it is no longer required the configuration of the Alfresco Surf versions. The inclusion of the BOM and the custom Docker
|
||||
Making use of the Alfresco SDK 4.x it is no longer required the configuration of the Alfresco Surf versions. The inclusion of the BOM and the custom Docker
|
||||
images will take care of that task automatically for you.
|
||||
|
||||
## Purging the project data and running the project
|
||||
|
||||
Reference in New Issue
Block a user