On 28 September 2011 08:17, Jasha Joachimsthal <[email protected]>wrote:
> > > 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). > > Done. Jasha
