Elliot Metsger wrote: > > > Eric Dalquist wrote: >> I'm working on mavenizing the trunk of uPortal and have run into a >> few questions I'd like to pose to the group. >> >> The big one is packaging. > > Are you referring to packaging up uPortal for a release (i.e. a binary > distribution) or are you talking about a developer deploying from the > command line (say, someone who has checked out the tag from SVN) using > Maven? Well actually we need to figure out both. > >> Using maven for build management really lends itself to generating an >> EAR since it allows multiple WARs (uPortal and each portlet app) and >> shared libraries. For uPortal 3 sandbox development we already have >> an EAR -> Tomcat deployer tool which puts the WARs and JARs in the >> correct locations. > > It has been a while - did the sandbox ear deployer ever correctly > deploy shared libraries, or did we punt on that? The sandbox deployer would put the JARs in the EAR into shared/lib and then deploy the WARs to webapps named based on info in META-INF/application.xml > >> The problem with the EAR approach is it does not (as far as I can >> tell) allow for differentiation of what libraries are shared by just >> the WARs (pluto) and what libraries need to be shared with the >> servlet container (jdbc driver for JNDI datasource). > > I agree, afaik ear packaging isn't able to specify what goes into a > shared classloader. If a webapp jar has a dependency on a shared > library, it needs to add the shared library in its MANIFEST.MF file, > but the ear itself doesn't contain the shared lib. > > I think of it as the <provided> dependency scope in M2. The > dependency exists but it is provided by the container at runtime. EARs can contain JAR resources. The problem comes in that Tomcat has different places for shared libraries, some go in shared/lib some go in common/lib and differentiating that isn't possible as far as I can tell. > >> I'm not quite sure what to do about this. We don't really need to use >> JNDI for the DataSource in the quickstart / out of the box >> configuration but providing a way to do it without having to come up >> with a custom development process would be very good. > > I think if we're talking about a binary distribution (not a > quickstart), it is reasonable to ask deployers of uPortal to download > their JDBC driver and put it into the shared classloader of their > servlet container. Perhaps the uPortal binary distribution ships with > some common JDBC drivers, and an ant installer takes care of the rest. I thought about that, it is a similar approach to what I've seen other projects do. The downside to this is almost everyone is going to be putting their JDBC driver in shared/lib and configuring context.xml (though that can go in uPortal/META-INF) with JNDI datasources. Since most people are going to want to include that process in their overall build having something in the default build process that addresses this would be nice. At this point I'm thinking of a combination of building an EAR (that has a lot of appeal to me as it is a standard packaging) with an assembly profile for tomcat to get packaging figured out. > > Or perhaps I'm not fully understanding the issue, > Elliot >
smime.p7s
Description: S/MIME Cryptographic Signature
