On 09/22/2011 01:59 PM, Jasha Joachimsthal wrote:
Since the restructuring my IDE (IntelliJ) doesn't recognise the JSTL taglibs
in rave-portal-resources which breaks the code completion.
I had to add these 3 dependencies to the pom to make it work:
<dependency>
<groupId>org.glassfish.web</groupId>
<artifactId>jstl-impl</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.apache.rave</groupId>
<artifactId>rave-web</artifactId>
<scope>provided</scope>
</dependency>
Scope "test" didn't do the trick. Any other suggestions that are less ugly?
Hi Jasha,
Yes, I can see this is a problem we need to solve.
The reason to package the rave-portal-resources as "shallow" war only (no
dependencies at all) was to prevent the often occurring war-overlay problem of
conflicting dependencies, because Maven isn't aware of the embedded jars within
a war. That could also be prevented by explicitly excluding WEB-INF/lib/* in the
maven-war-plugin overlay config, but in my experience that typically is forgotten.
But indeed, IDEs have their own share of problems dealing with war overlays :(
And honestly, I really would prefer not having to rely on or use war overlays in
the first place. But the way the servlet spec is, there isn't really a
simple/simpler alternative.
So, AFAIK we have two options two solve this problem at hand:
a) Allow and make use of *only* provided dependencies for the
rave-portal-resources war. This will ensure it remains "shallow" without causing
dependencies ending up embedded within the war.
The downside of this solution is that you'll have to keep these "local"
dependencies in sync with those bundled in the final (rave-portal) war, which
derives these (hopefully the same or a super set of) from rave-portal-resources pom.
b) Merge rave-portal-resources back into rave-portal again.
This will not have the downside of a) but will push down the obligation to end
users to exclude the embedded dependencies if/when they need to "extend" from
rave-portal to build their own custom portal war. They certainly will need to be
more careful in doing so and it will become easier to "break" stuff.
But one additional (nice) benefit from this solution is that it'll be easier on
JRebel users as well ;)
I'm not specifically in favor of either choice: neither is perfect IMO, but the
current problem is more hindrance for ourselves, so I'm OK fixing it through a)
or b).
WDYT?
Ate
Jasha Joachimsthal
Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522 4466
US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll free)
www.onehippo.com
