On 23 September 2011 15:31, Jasha Joachimsthal <[email protected]>wrote:
> > > 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 > > If nobody objects, I'd like to add the provided dependencies (option a). Jasha
