On 22 September 2011 15:17, Ate Douma <[email protected]> wrote: > 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. >
Having an outdated or missing "provided" dependency won't break the build, it will only be an annoyance in the IDE which can easily be solved. > > 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? > Merging the resources back into rave-portal brings back the situation that one can only overlay a war with all dependency hell issues again. So my preference is option a). Then there's indeed a different issue with JRebel. Since the restructuring JRebel doesn't reload the classes or web resources out of the box because of the moduralised structure (i.e. it doesn't know where the source of my controller is). This is something that is a very nice to have because it saves me a lot of time, but if I'm the only one using JRebel at the moment (?) not an urgent must have. Jasha
