proctor-tomcat-deps-provided

[da...@vast.com]

I've never seen that maven idiom before, and my google-fu is weak.

Guessing: it's intent is to allow consumers to specify their dependencies in this way?

        <dependency>
            <groupId>com.indeed</groupId>
            <artifactId>proctor-tomcat-deps-provided</artifactId>
        </dependency>
        <dependency>
            <groupId>com.indeed</groupId>
            <artifactId>proctor-common</artifactId>
        </dependency>
        <dependency>
            <groupId>com.indeed</groupId>
            <artifactId>proctor-consumer</artifactId>
        </dependency>

And then lean on maven's dependency resolution?

[Ketan Gangatirkar]

Hi, Danil.  Proctor uses the Unified Expression Language, which is an merger/evolution of both JSP Expression Language and JSF Expression language.  An implementation of this is provided by newer application containers such as Tomcat 7.  In those cases, there's no need to pull in a dependency on Unified EL via Proctor; in fact, it is harmful because you will have the same classes in your classpath more than once.

However, there are use cases for Proctor where it is not hosted inside an application container like Tomcat 7.  In those cases, you want your dependency on Proctor to pull in an implementation of Unified EL, otherwise it just won't work.

I personally don't know much about Maven; is there a more idiomatic way to accomplish this same thing?

--
You received this message because you are subscribed to the Google Groups "indeedeng-proctor-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to indeedeng-proctor...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Ketan Gangatirkar
ke...@indeed.com
Contiñuous Delivery, Mister DscManagger

[Charles Duffy]

To be entirely explicit:

All components of Proctor which depend on packages provided by Tomcat intermediate this through a package "proctor-tomcat-deps". If you don't do anything, proctor-tomcat-deps will be automatically pulled into your project, so when you generate a WAR, it will contain a series of jars which are already present in Tomcat itself, leading to potential for conflicts.

Including "proctor-tomcat-deps-provided" will prevent proctor-tomcat-deps from pulling in these packages. You can also mark these as provided individually inside your own pom.xml, which is probably the more widely used idiom (and, for that matter, which proctor-demo does in addition, given its direct use of several Tomcat-provided APIs) -- but generates a support burden on you the user (of needing to list all Tomcat dependencies used by the Proctor library), which is why this alternative is provided.