You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by Jasha Joachimsthal <j....@onehippo.com> on 2011/09/22 13:59:58 UTC
JSTL taglib resolving in IDE
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?
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
Re: JSTL taglib resolving in IDE
Posted by Jasha Joachimsthal <j....@onehippo.com>.
On 28 September 2011 08:17, Jasha Joachimsthal
<j....@onehippo.com>wrote:
>
>
> On 23 September 2011 15:31, Jasha Joachimsthal <
> j.joachimsthal@onehippo.com> wrote:
>
>>
>>
>> On 22 September 2011 15:17, Ate Douma <at...@douma.nu> 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
Re: JSTL taglib resolving in IDE
Posted by Ate Douma <at...@douma.nu>.
On 09/28/2011 08:17 AM, Jasha Joachimsthal wrote:
> On 23 September 2011 15:31, Jasha Joachimsthal
> <j....@onehippo.com>wrote:
>
>>
>>
>> On 22 September 2011 15:17, Ate Douma<at...@douma.nu> 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
>
RE: JSTL taglib resolving in IDE
Posted by "Ciancetta, Jesse E." <jc...@mitre.org>.
>-----Original Message-----
>From: Jasha Joachimsthal [mailto:j.joachimsthal@onehippo.com]
>Sent: Wednesday, September 28, 2011 2:18 AM
>To: rave-dev@incubator.apache.org
>Subject: Re: JSTL taglib resolving in IDE
>
>On 23 September 2011 15:31, Jasha Joachimsthal
><j....@onehippo.com>wrote:
>
>>
>>
>> On 22 September 2011 15:17, Ate Douma <at...@douma.nu> 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 -- sounds good to me.
>Jasha
RE: JSTL taglib resolving in IDE
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
>>>
>>If nobody objects, I'd like to add the provided dependencies (option a).
>
>+1 -- sounds good to me.
+1
Re: JSTL taglib resolving in IDE
Posted by Jasha Joachimsthal <j....@onehippo.com>.
On 23 September 2011 15:31, Jasha Joachimsthal
<j....@onehippo.com>wrote:
>
>
> On 22 September 2011 15:17, Ate Douma <at...@douma.nu> 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
Re: JSTL taglib resolving in IDE
Posted by Jasha Joachimsthal <j....@onehippo.com>.
On 22 September 2011 15:17, Ate Douma <at...@douma.nu> 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
Re: JSTL taglib resolving in IDE
Posted by Ate Douma <at...@douma.nu>.
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
>