Removing samples from an AEM Maven project

Transcript

So, I just want to quickly show you how you can clean up some of the example or sample code that the EDM project archetype ads generated projects. So, this project was generated using version 30 of the AM Maven project archetype and we’re just going to go in and get rid of some of these sampler examples, which can absolutely be helpful if you’re getting started with AEM and playing around with it. But, you certainly don’t want the sample code to end up in your production code base or deployed to production itself, since it is sample code and you never want sample code on production. So, let’s get started. First, we’ll go to core, and this is where the Java code resides in the project. So, this is going to generate the OSJ bundle and you can see that the Maven archetype has generated a bunch of sample classes for us. and so we don’t want any of these. We are going to simply go through and delete all of these packages as well as the Java code therein. Let’s go ahead and delete the servlets. It’s the last one. Next, we want to head over to tests. And since there are tests for each of the files, we just deleted, we need to get rid of those tests as well. Otherwise, the Maven build would of course fail.

So, let’s go ahead and delete all of our tests.

And now we’ve cleaned up our core Java code.

Next, let’s head over to the UI apps project. So this is what’s going to install into the slash apps folder and usually contains things like component definitions or other configurations. So, let’s head in here and you’ll see that under apps, your project, name, and components there are a bunch of components listed here. So all but one of these are core component proxies, and you’ll want to keep these because you’ll actually be using these to build out your AEM site. However, there is this hello world component that is added as a sample component, and we are going to want to delete this as well. And do note that this component actually references the sling model that we deleted from the core project. All right, so we’ve gotten rid of our hello world, so we should be good with our components. And now let’s head down to the UI front end project, and this contains the front end code. So, the CSS or JavaScript used to style our components as well as provide any client side behavior. So, if we drill into source Web pack components and scroll down, you’ll see that we have some JavaScript as well as a CSS or in this case, SCSS that support our hello world component. we just deleted. So, let’s go ahead and get rid of these as well.

And note that all of these other files are in support of those core component proxies, so we’ll want to keep them. The last thing we want to do in UI front end is head over to the static .HTML, and we’ll go ahead and search for the hello world component.

And you can see we have a sample here and delete that as well.

And do note that with the deletion of this hello world component from the static file, when you do open this up to develop against it will appear quite empty.

All right, the last thing we want to do is head over into UI content and this contains any of the content definitions that are part of this project. So if we go into source main content going to JCR, which represents the JCR root, go to content, go to our site, click into USEN, and click on the .content .XML folder. Here, we have the XML definition for our CQ page that represents our homepage. And similar to the static index at HTML, if we scroll down, we’ll see an example of the hello world component embedded in here. And since we’ve deleted this component from our project, it won’t, it will no longer render. So, let’s just go ahead and remove this as well. All right. So that should about do it. We’ve cleaned up all of our samples and example code that we wouldn’t want deploy to a production instance.

Before we go, I do want to call out these two projects here. IT tests as well as UI tests. So if we click into these, we can actually see that the, that the Maven archetype has generated some sample tests for us. And secondly, these tests actually ensure and validate that custom code that you may have added to your project and deployed AEM aren’t breaking out of the box AAM functionality. So it does a nice to keep these in your project to help avoid accidents.

And if we go into the UI tests under the specs, you can see that there are a handful of specs here as well, that help validate that some of the out of the box functionality isn’t broken.

So, that’s about it. Let’s just run a quick meeting clean verify, and just to make sure that our project still builds, and we don’t have any issues based on our deletions here.

All right. So looks like the build succeeded the last thing we’ll want to do, of course is make our, is commit our changes to git. And now you should be ready to go and start adding your production code to your project. -