Override core JSP module - what type of module?

[Dave Weitzel, modificado 6 Anos atrás.]

I am trying to follow the tutorial on overriding the core JSP's as I have a need to "edit" html/common/themes/portlet.jsp
the tutorial https://dev.liferay.com/develop/tutorials/-/knowledge_base/7-0/overriding-core-jsps is great and the example in the blade samples is also great BUT an important step is missing.

I find this all the time :-) and wonder if there are any staff who validate these tutorials from a basic user viewpoint and try to follow all the steps and can fill in the gaps.

The missing step is what type of module do I create? using either the Blade CLI or IDE (I think I am leaning more to the Blade CLI for creating modules etc). Is it a fragment (that is the case for non Core JSPs), or is it something else?

the fragment module type requires hostBundleSymbolicName and hostBundleVersion which you can find for non-Core JSPs (next weeks job) but I don't think exist for core JSP as they are in the ROOT webapp not a separate jar file. I couldn't detect any core-Web bundle from the gogo shell lb command.

So can anyone tell me how I create the basic module (fragment or not) for core JSP override. I can then ensure from the examples I am doing things right and tread carefully in the edit I need to make to what is an important file.

As an aside - how do I establish which bundles particular files are in? The API documentation doesn't cover non-java files like jsps and portal properties.

[David H Nebinger, modificado 6 Anos atrás.]

Dave Weitzel:

The missing step is what type of module do I create? using either the Blade CLI or IDE (I think I am leaning more to the Blade CLI for creating modules etc). Is it a fragment (that is the case for non Core JSPs), or is it something else?

So here's the thing you figure out once you've been doing these awhile - it doesn't really matter that much.

The templates tend to do two basic things:

1) Populate build.gradle and bnd.bnd based on given arguments.
2) Copy in starter files based on the type.

So choosing the right template when you're getting started is important in that it provides the basic pattern you need to complete for a working module.

But after you cut your teeth on a few modules, you realize that, in fact, they really are just a jar file with contained files and special markers in the bnd.bnd file. Knowing that you can usually start with any template and lay out the files that you need.

The one exception, though, is the service builder template since it is actually creating the two interlinked modules. Of course, it also is not necessary as you can copy what the template does for you too.

All of that said, none of the templates are really a good fit for what you are looking for. All you need is a regular module jar, you'll be adding your JSP override and the annotated Java class to register the CustomJspBag component.

So when none of the actual templates are close to what you need, I typically will just use the API template because that gives the fewest files to get rid of later on.

the fragment module type requires hostBundleSymbolicName and hostBundleVersion which you can find for non-Core JSPs (next weeks job) but I don't think exist for core JSP as they are in the ROOT webapp not a separate jar file. I couldn't detect any core-Web bundle from the gogo shell lb command.

Nope, they are not a JSP fragment bundle, it is just a regular module jar with a CustomJspBag and the override JSP files.

So can anyone tell me how I create the basic module (fragment or not) for core JSP override. I can then ensure from the examples I am doing things right and tread carefully in the edit I need to make to what is an important file.

Yep, use an API bundle.

As an aside - how do I establish which bundles particular files are in? The API documentation doesn't cover non-java files like jsps and portal properties.

Well, sure it does. The link you provided covers overriding core jsps and you can use JSP fragment bundles for OSGi bundle overrides of jsps. Portal properties are non-starters, you don't deploy overrides/settings for those in modules any more.









Come meet me at the 2017 LSNA!

[Dave Weitzel, modificado 6 Anos atrás.]

Many thanks for your reply David.
The advice to use the API template is great and I was planning on delete/overwriting the created files as necessary - the blade samples download is great as it has exactly the customJspBag override I need for today's module and then there are others for more advanced listeners postlogin etc tha I have to port from 6.2

A couple of follow ups though.
1) what is a module fragment? Can I be combining different changes int one module - eg language file and jsp overide for core and then for individual apps.
2) when I build a module I don't see any jar file being generated. If I deploy using the IDE I know one got generated and deployed but the module folder doesn't have a dist or other directory. the tmp/jar folder only has the manifest file. Is this a configuration setting somewhere? We will be checking into bitbucket and using Jenkins to build and deploy and the devOps guys were wanting to know how this was managed.

Thanks again for speedy response

[David H Nebinger, modificado 6 Anos atrás.]

Dave Weitzel:

1) what is a module fragment? Can I be combining different changes int one module - eg language file and jsp overide for core and then for individual apps.

Well, the term is "fragment module" for the JSP fragment files. Except for those, you can actually combine classes into a single module jar, you just have to get the bnd.bnd straight.

2) when I build a module I don't see any jar file being generated. If I deploy using the IDE I know one got generated and deployed but the module folder doesn't have a dist or other directory. the tmp/jar folder only has the manifest file. Is this a configuration setting somewhere? We will be checking into bitbucket and using Jenkins to build and deploy and the devOps guys were wanting to know how this was managed.

With gradle, your artifacts should be in build/libs directory.









Come meet me at the 2017 LSNA!