Why upgrade SDK 3.0?
- Support for RAD (Rapid Application Development) and TDD (Test Driven Development) via HotswapAgent and JRebel
- Simpler SDK layout
- Jar packaging by default
- Support for Alfresco version 4.2 to 5.2
- Integration testing webscripts
- Update your pom.xml
- Remove all SDK modules, except for your jar/amp project modules.
- Update your Integration tests.
- Add integration-tests project module, and copy src directory.
- Re-organize your Integration tests into the integration-tests project module, and rename to *IT.java.
- Search and replace default project name with your project name where exists.
The instructions provided in this article is based on an SDK upgrade from Alfresco SDK 2.1.1 to Alfresco SDK 3.0
Vanilla for Reference
To get started with the upgrade, we’ll need a vanilla version of the 3.0 SDK project to get some of the new files and configurations that we’ll need.
Do this by using one of the following maven commands to generate an all in one project:
Update our poms
First pom.xml to update would be the main pom.xml of our project.
In this pom, we will remove the alfresco-sdk-parent. With SDK 3.0, we no longer need a parent project.
Update the properties in this pom.xml with the properties from our vanilla project
Instead of Java 7 source/target, I prefer Java 8 targets.
Next we update the dependencyManagement section with the elements from the vanilla template
In the build section, we will update the pluginManagement, and the plugins section.
For the plugins section, copy and paste the section from our vanilla pom.xml, and update the moduleDependency to include your project’s modules. Your repository module will be under the <platformModules> section, and your Share modules will be under the <shareModules> section.
Add the resources section
[crayon-5dd7571984169061440224/] We will then add the resources section that will provide access to the 3.0 SDK dependencies.
Finally, for this pom.xml, we will remove the <profile> section, and update our <modules> section so that we remove the old SDK module dependencies, and add the new integration-tests module. The update will look like this:
pom.xml for your repository projects
If you’re changing your packaging type, like I did from amp to jar, then, update your packaging type here
[crayon-5dd757198416b533782278/] Remove the following dependency, as it’s no longer needed
[crayon-5dd757198416d703222598/] Remove the profiles section
And add the build section from the vanilla template
Next pom.xml for Share project modules
Again, if you’re switching from amp to jar, then you can update the <packaging> section
[crayon-5dd7571984170886279747/] Update the dependencies section, to remove the integration test suite dependencies, like selenium, etc.
[crayon-5dd7571984171357441645/] Then add the build section, and we’re good to go:
Copy some files
Copy the top level src directory over
Copy the src directory from the vanilla project over to your project at the same level.
From the files we copied, update the platform-hotswap-agent.properties, and share-hotswap-agent.properties, and do a search and replace for the name of your vanilla-project-share-jar, and vanilla-project-platform-jar. For example, my vanilla project was named my-aio-project.
[crayon-5dd7571984174933069872/] and replace with the name of your shareui project module.
Do the same for
[crayon-5dd7571984175068217020/] and replace with the name of your repository project module.
Copy the integration-tests module over
From the files you copied over, remove the sample IT test cases and package, and add your own.
Additionally, update the parent settings in the pom.xml so that the parent is your main project.
Migrating our Integration Tests
In migrating our IT tests, we’ll need to ensure that the test names end in IT. For example MyTest should be MyTestIT.
Next, we’ll remove the old RunWith dependency, and add the new ones.
[crayon-5dd7571984177416402554/] Will become
[crayon-5dd7571984178293199385/] Our IT test, will then need to extend the following class.
[crayon-5dd7571984179626050174/] Different approaches for setting up our integration tests can be found in the vanilla package that we generated. Use the way that best fits your model.
In this approach, @Autowire will not work, so we’ll need to update our @Before method to initialize our service dependencies.
Spin it up
Next, start up your project with the following command
[crayon-5dd7571984180499254083/] If you have the JRebel plugin in intellij, run your command using the jrebel executors
http connection errors when you attempt to start up the repository
Connect to localhost:8080 [localhost/127.0.0.1, localhost/0:0:0:0:0:0:0:1, localhost/fe80:0:0:0:0:0:0:1%1] failed: Connection refused
Review your integration tests and verify that their names end in IT.java. For example MyTestIT.java Test cases that end in *IT.java will not be executed through the maven test phase. Also verify that you’re using the correct version of maven: mvn 3.3.3