0

I'm developing an Adobe CQ application (OSGI) that runs in an Apache Felix environment that provides our JSPs with a huge list of Java packages we can include. I want to pre-compile our JSPs with the maven-jspc-plugin so we can catch compile errors more efficiently (Ref http://dev.day.com/docs/en/cq/aem-how-tos/development/how-to-build-aem-projects-using-apache-maven.html), but my problem is that pre-compiling is impossible unless I import a nigh-endless list of maven dependencies for all of the classes at runtime.

For example, here's a partial list of the packages that various pieces of code might use from the container:

  • com.day.commons.osgi.wrapper.commons-email (99)
  • com.day.commons.osgi.wrapper.commons-httpclient (100)
  • com.day.commons.osgi.wrapper.fop (175)
  • com.day.commons.osgi.wrapper.mail (101)
  • com.day.commons.osgi.wrapper.simple-jndi (102)
  • com.day.commons.osgi.wrapper.svnkit (236)
  • com.day.cq.collab.cq-collab-blog (152)
  • com.day.cq.collab.cq-collab-calendar (153)
  • com.day.cq.collab.cq-collab-commons (154)
  • com.day.cq.cq-analytics (162)
  • com.day.cq.cq-apns-client (163)
  • com.day.cq.cq-authhandler (104)
  • com.day.cq.cq-commons (178)
  • com.day.cq.cq-compat-commons-auth (105)
  • com.day.cq.cq-compat-configupdate (37)
  • com.day.cq.cq-compat-core (183)
  • com.day.cq.cq-compat-cqupgrade (184)
  • com.day.cq.cq-compat-migration (185)
  • com.day.cq.cq-content-sync (188)
  • com.day.cq.cq-i18n (86)
  • com.day.cq.cq-jcrclustersupport (74)
  • com.day.cq.cq-jobs-core (191)
  • com.day.cq.cq-mailer (193)
  • com.day.cq.cq-opensocial (194)
  • com.day.cq.cq-personalization (195)
  • com.day.cq.cq-pinauthhandler (203)
  • com.day.cq.cq-polling-importer (190)
  • com.day.cq.cq-replication (88)
  • com.day.cq.cq-reporting (197)
  • com.day.cq.cq-retriever (198)
  • com.day.cq.cq-rewriter (192)
  • com.day.cq.cq-search (200)
  • com.day.cq.cq-searchpromote (202)
  • com.day.cq.cq-upgrades-executor (148)
  • com.day.cq.cq-widgets (94)
  • com.day.cq.cq-xssprotection (98)
  • com.day.cq.dam.adobe-xmp (214)
  • com.day.cq.dam.commons.nekohtml (216)
  • com.day.cq.dam.cq-dam-core (220)
  • com.day.cq.dam.cq-dam-creativecloud (221)
  • com.day.cq.dam.cq-dam-handler (222)
  • com.day.cq.dam.cq-dam-indesign (223)
  • com.day.cq.dam.cq-dam-scene7 (224)
  • com.day.cq.dam.cq-dam-video (225)
  • com.day.cq.dam.cq-dam-word (226)
  • com.day.cq.mcm.cq-mcm-core (242)
  • com.day.cq.mcm.cq-mcm-exacttarget-integration (241)
  • com.day.cq.mcm.cq-mcm-landingpage (244)
  • com.day.cq.wcm.cq-msm-core (281)
  • com.day.cq.wcm.cq-wcm-content-sync (270)
  • com.day.cq.wcm.cq-wcm-core (273)
  • com.day.cq.wcm.cq-wcm-designimporter (274)
  • com.day.cq.wcm.cq-wcm-emulator (275)
  • com.day.cq.wcm.cq-wcm-foundation (234)
  • com.day.cq.wcm.cq-wcm-geometrixx (151)
  • com.day.cq.wcm.cq-wcm-mobile-core (278)
  • com.day.cq.wcm.cq-wcm-notification (282)
  • com.day.cq.wcm.cq-wcm-siteimporter (284)
  • com.day.cq.wcm.cq-wcm-webservice-support (287)
  • com.day.cq.workflow.cq-workflow-api (211)
  • com.day.cq.workflow.cq-workflow-console (212)
  • com.day.cq.workflow.cq-workflow-impl (213)
  • com.day.crx.crxde-support (235)
  • com.day.crx.sling.server (60)
  • com.day.jcr.vault.com.day.jcr.vault (75)
  • day.commons-gfx (107)
  • day.commons-jrawio (181)
  • day.commons-jstl (108)
  • day.commons.datasource.jdbcpool (109)
  • day.commons.datasource.poolservice (110)
  • org.apache.abdera.client (167)
  • org.apache.abdera.core (168)
  • org.apache.abdera.extensions-media (169)
  • org.apache.abdera.extensions-opensearch (170)
  • org.apache.abdera.parser (172)
  • org.apache.abdera.server (173)
  • org.apache.aries.jmx.api (13)
  • org.apache.aries.jmx.core (14)
  • org.apache.aries.jmx.whiteboard (15)
  • org.apache.aries.transaction.manager (16)
  • org.apache.aries.util (17)
  • org.apache.cocoon.cocoon-xml (174)
  • org.apache.commons.commons-imaging (217)
  • org.apache.felix.configadmin (39)
  • org.apache.felix.eventadmin (40)
  • org.apache.felix.http.whiteboard (24)
  • org.apache.felix.metatype (42)
  • org.apache.felix.org.apache.felix.http.sslfilter (41)
  • org.apache.felix.prefs (43)
  • org.apache.felix.scr (44)
  • org.apache.felix.webconsole (25)
  • org.apache.felix.webconsole.plugins.ds (26)
  • org.apache.felix.webconsole.plugins.event (27)
  • org.apache.felix.webconsole.plugins.memoryusage (28)
  • org.apache.felix.webconsole.plugins.packageadmin (29)
  • org.apache.jackrabbit.jackrabbit-api (65)
  • org.apache.jackrabbit.jackrabbit-jcr-commons (66)
  • org.apache.jackrabbit.jackrabbit-jcr-rmi (67)
  • org.apache.jackrabbit.jackrabbit-spi-commons (112)
  • org.apache.jackrabbit.jackrabbit-webdav (113)
  • org.apache.sling.adapter (114)
  • org.apache.sling.atom.taglib (250)
  • org.apache.sling.auth.core (116)
  • org.apache.sling.bgservlets (117)
  • org.apache.sling.bundleresource.impl (118)
  • org.apache.sling.commons.classloader (119)
  • org.apache.sling.commons.compiler (120)
  • org.apache.sling.commons.html (121)
  • org.apache.sling.commons.log (5)
  • org.apache.sling.commons.logservice (6)
  • org.apache.sling.commons.mime (123)
  • org.apache.sling.commons.osgi (45)
  • org.apache.sling.commons.scheduler (124)
  • org.apache.sling.commons.threads (125)
  • org.apache.sling.engine (126)
  • org.apache.sling.event (127)
  • org.apache.sling.extensions.threaddump (30)
  • org.apache.sling.i18n (128)
  • org.apache.sling.installer.api (7)
  • org.apache.sling.installer.console (31)
  • org.apache.sling.installer.core (8)
  • org.apache.sling.installer.factory.configuration (32)
  • org.apache.sling.installer.provider.file (9)
  • org.apache.sling.installer.provider.jcr (76)
  • org.apache.sling.jcr.base (70)
  • org.apache.sling.jcr.classloader (129)
  • org.apache.sling.jcr.contentloader (131)
  • org.apache.sling.jcr.davex (132)
  • org.apache.sling.jcr.jcr-wrapper (71)
  • org.apache.sling.jcr.registration (72)
  • org.apache.sling.jcr.resource (133)
  • org.apache.sling.jcr.webdav (134)
  • org.apache.sling.launchpad.installer (10)
  • org.apache.sling.resourceresolver (135)
  • org.apache.sling.rewriter (136)
  • org.apache.sling.scripting.api (137)
  • org.apache.sling.scripting.core (138)
  • org.apache.sling.scripting.java (139)
  • org.apache.sling.scripting.javascript (140)
  • org.apache.sling.scripting.jsp (141)
  • org.apache.sling.scripting.jst (251)
  • org.apache.sling.security (33)
  • org.apache.sling.servlets.get (143)
  • org.apache.sling.servlets.post (144)
  • org.apache.sling.servlets.resolver (145)
  • org.apache.sling.settings (11)
  • org.apache.sling.startupfilter (146)
  • org.apache.sling.tenant (269)
  • org.apache.tika.core (57)
  • org.apache.tika.parsers (58)

Including all of the dependencies my container could provide into my pom.xml by hand would be insanely time consuming and very fragile. The moment we upgrade the system the whole list might have to be rewritten, and anyone trying to use a newer class would have to find the dependency and update the pom with it.

How can I use my osgi container to provide the compiler with a list of dependencies that are available at runtime?

AlleyGator
  • 1,266
  • 9
  • 13
  • Why do you want to compile against all the dependencies that you *could* use? Why not compile against just the dependencies that you use in the code? – Neil Bartlett Apr 18 '14 at 22:06
  • The only reason I need the dependencies is to tell maven what is already provided, so that the code can be precompiled from the command line to check for errors. The Adobe CQ product provides a huge library of java classes (approx 280 bundles worth) to the runtime environment, and hundreds of components based on JSPs which use those classes. If we need to tweak anything (which we need to do constantly), these tweaked versions go under source control with tons of "new" dependencies for maven to choke on. Why would I want to maintain a list of dependencies that I don't provide? – AlleyGator Apr 18 '14 at 22:31
  • Hmm I still don't get it, but that's probably because I don't know CQ. Hopefully somebody who does know it will be able to help. – Neil Bartlett Apr 19 '14 at 09:30
  • It seems to be a good idea to handle all the jsp errors in compile time. However what if the existing adobe classes/packages are been changed from adobe and if your code still refers to the older version than you might have to change your code and retest this with the newer version. e.g. The components created with 5.4 version might or might not work with the newer version 5.6.1. How are you sure that upgrading the system will not need any additional changes ? – yash ahuja Apr 21 '14 at 11:30
  • Yash: That's exactly why I want the OSGI container to give me the list to of dependencies the OSGI container provides. I don't want to maintain a list of something somebody else provides. – AlleyGator Apr 21 '14 at 14:47

2 Answers2

2

I located something called the "Archiva" Servlet: http://www.citytechinc.com/us/en/blog/2013/01/cq5-maven-dependency-management.html

"The Archiva servlet is commonly used to allow a CQ5 instance to function as a Maven repository, but there is an additional, undocumented feature of the servlet that generates a POM file for all of the installed bundles in the OSGi container."

This is exactly what I needed.

AlleyGator
  • 1,266
  • 9
  • 13
  • I'll add one more thing: If the OSGI container can export a POM of the system resources, as the link above indicates it can, then you can set up your pom to import that POM at compile time using import. You might need a separate step to parse the exported pom and tweak its contents slightly. Example: since these dependencies are provided at runtime, I would make sure all of the s on the imported dependencies were 'provided'. – AlleyGator Apr 21 '14 at 17:44
  • An even better answer: Adobe answered this question themselves. http://dev.day.com/content/docs/en/cq/aem-how-tos/development/how-to-build-aem-projects-using-apache-maven.pdf, Page 13 "Importing AEM Product Dependencies" – AlleyGator Apr 22 '14 at 19:02
0

You can specify a dependency in Maven and mark it as "provided" so it will compile against it, but not bundle it in the jar.

    <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-lang3</artifactId>
        <version>3.3.2</version>
        <scope>provided</scope>
    </dependency>
jiggy
  • 3,828
  • 1
  • 25
  • 40
  • This will not help the maven-jspc plugin, since the purpose of the jspc plugin (and of my question) is to compile the JSP's outside the container which normally provides the dependencies. It is not something you normally do in CQ but I see a benefit since compile errors inside a JSP can normally only be found at runtime. – AlleyGator May 12 '15 at 21:24