On 09/28/2011 08:17 AM, Jasha Joachimsthal 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).
+1
Ate
Jasha
