Adding aspectj module broke the build...

[Kalle Korhonen <ka...@gmail.com>]

Bah, I just managed to break the build by adding the new aspectj
module. It fails on:
[INFO] Compilation failure
/export/home/hudson/hudson/jobs/Shiro/workspace/trunk/support/aspectj/src/test/java/org/apache/shiro/aspectj/DummyServiceTest.java:[32,-1]
cannot access org.apache.shiro.aspectj.AspectjAnnotationsAuthorizingMethodInterceptor
bad class file:
/export/home/hudson/hudson/jobs/Shiro/workspace/trunk/support/aspectj/target/classes/org/apache/shiro/aspectj/AspectjAnnotationsAuthorizingMethodInterceptor.class
class file has wrong version 50.0, should be 49.0

I.e. the builder jdk is 1.5 but 1.6 is required. What I don't get
though is that it just compiled that
AspectjAnnotationsAuthorizingMethodInterceptor but I suppose it's
actually the imported AspectJ classes that are built on jdk 1.6. Now,
1.5 was end-of-lifed last October. Funny, but I don't even have 1.5
jdk anymore on my system and Sun has really made it difficult to get
to it anymore (just checked).

What's our policy regarding supporting jre versions? The easiest fix
is probably to use a different builder on Hudson, but we might be
using jdk 1.5 for a reason. I can detach the new module in the
meantime.

Kalle

Re: Adding aspectj module broke the build...

[Kalle Korhonen <ka...@gmail.com>]

Well - that was simple. Mostly my fault, just changing the aspectj
plugin configuration was enough to make it work on 1.5.

Kalle


On Thu, Jan 28, 2010 at 10:36 AM, Les Hazlewood <lh...@apache.org> wrote:
> On Thu, Jan 28, 2010 at 1:18 PM, Kalle Korhonen
> <ka...@gmail.com> wrote:
>>>
>>> quite a few Fortune 100 companies that are tied to JDK 1.5 in one way
>>> or another, and we might abandon those users even if they may not have
>>> a voice represented on the user list.  It'd probably be better not to
>>> have to switch unless there is a really compelling reason to do so
>>> (e.g. new language feature or some critical API).
>>
>> Ah it's always those big dinosaurs. If you know that for a fact then I
>> think it's settled.
>
> I know that some of the big ones use Shiro, but I don't know what JREs
> they're running today, so I really can't say one way or the other.  If
> we can get AspectJ to work with 1.5, naturally that'd be cool, but if
> it is a sufficiently large pain for you to find a workaround - like
> you said, maybe having 1.6 for just that module is the next best
> solution.
>
> Les
>

Re: Adding aspectj module broke the build...

[Les Hazlewood <lh...@apache.org>]

On Thu, Jan 28, 2010 at 1:18 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
>>
>> quite a few Fortune 100 companies that are tied to JDK 1.5 in one way
>> or another, and we might abandon those users even if they may not have
>> a voice represented on the user list.  It'd probably be better not to
>> have to switch unless there is a really compelling reason to do so
>> (e.g. new language feature or some critical API).
>
> Ah it's always those big dinosaurs. If you know that for a fact then I
> think it's settled.

I know that some of the big ones use Shiro, but I don't know what JREs
they're running today, so I really can't say one way or the other.  If
we can get AspectJ to work with 1.5, naturally that'd be cool, but if
it is a sufficiently large pain for you to find a workaround - like
you said, maybe having 1.6 for just that module is the next best
solution.

Les

Re: Adding aspectj module broke the build...

[Kalle Korhonen <ka...@gmail.com>]

On Thu, Jan 28, 2010 at 10:05 AM, Les Hazlewood <lh...@apache.org> wrote:
> Yes, that was my next recommendation - to ask the community :)

Sent the email.

> JavaEnvironment class in Shiro allows you to program to different APIs
> depending on the platform.  I've used this in the past when we
> Would this be usable for your needs Kalle?  I know there are still

No - there's no code in the aspectj module that requires 1.6 - it's
just that the aspectj libs on Central are compiled with 1.6, so going
to 1.6 would merely be for convenience reasons only (for us). I'm sure
I can get it to work with 1.5 one way or another (for example use
earlier versions of aspectj libs, require 1.6 only that module or
re-compile dependencies in 1.6).

> quite a few Fortune 100 companies that are tied to JDK 1.5 in one way
> or another, and we might abandon those users even if they may not have
> a voice represented on the user list.  It'd probably be better not to
> have to switch unless there is a really compelling reason to do so
> (e.g. new language feature or some critical API).

Ah it's always those big dinosaurs. If you know that for a fact then I
think it's settled. Agree with the principle that only if there's a
really compelling reason.

Kalle


> On Thu, Jan 28, 2010 at 12:41 PM, Kalle Korhonen
> <ka...@gmail.com> wrote:
>> Actually I might feel differently :) I know it sucks that for these
>> kind of projects there are much stronger requirements and demand to
>> stick with older version of JVM even if most of the users of
>> JSecurity/Shiro have happily moved on to newer JVMs ages ago. But
>> there's bound to be a few poor souls who are limited to 1.5 Java for
>> one reason or another. Since we've been compiling in 1.5 before an
>> optional aspectJ module (currently detached) I don't think one
>> supporting module is necessarily strong enough reason to move to 1.5,
>> even it being end-of-lifed. But hey, I have a crazy idea, maybe we
>> should just ask our users :) I'll send an email to users list on this.
>> In the meantime, I'll look into making the aspectJ module compile on
>> 1.5 (got the 1.5 jdk downloaded...). We can take the decision later
>> based on that information.
>>
>> Kalle
>>
>>
>> On Thu, Jan 28, 2010 at 6:36 AM, Les Hazlewood <lh...@apache.org> wrote:
>>> I believe the only reason is that we had a discussion thread about 4
>>> or so months ago concurring that we should use 1.5-compatible APIs
>>> moving forward (we used to support 1.4 via RetroWeaver at the time).
>>>
>>> I tend to agree that if 1.5 is already end-of-lifed (and has been for
>>> 4 months), it doesn't make much sense to release a brand new (first
>>> ever) Shiro release that targets a platform that Sun no longer even
>>> supports.
>>>
>>> Does anyone feel differently?
>>>
>>> On Tue, Jan 26, 2010 at 3:23 PM, Kalle Korhonen
>>> <ka...@gmail.com> wrote:
>>>> Bah, I just managed to break the build by adding the new aspectj
>>>> module. It fails on:
>>>> [INFO] Compilation failure
>>>> /export/home/hudson/hudson/jobs/Shiro/workspace/trunk/support/aspectj/src/test/java/org/apache/shiro/aspectj/DummyServiceTest.java:[32,-1]
>>>> cannot access org.apache.shiro.aspectj.AspectjAnnotationsAuthorizingMethodInterceptor
>>>> bad class file:
>>>> /export/home/hudson/hudson/jobs/Shiro/workspace/trunk/support/aspectj/target/classes/org/apache/shiro/aspectj/AspectjAnnotationsAuthorizingMethodInterceptor.class
>>>> class file has wrong version 50.0, should be 49.0
>>>>
>>>> I.e. the builder jdk is 1.5 but 1.6 is required. What I don't get
>>>> though is that it just compiled that
>>>> AspectjAnnotationsAuthorizingMethodInterceptor but I suppose it's
>>>> actually the imported AspectJ classes that are built on jdk 1.6. Now,
>>>> 1.5 was end-of-lifed last October. Funny, but I don't even have 1.5
>>>> jdk anymore on my system and Sun has really made it difficult to get
>>>> to it anymore (just checked).
>>>>
>>>> What's our policy regarding supporting jre versions? The easiest fix
>>>> is probably to use a different builder on Hudson, but we might be
>>>> using jdk 1.5 for a reason. I can detach the new module in the
>>>> meantime.
>>>>
>>>> Kalle
>>>>
>>>
>>
>

Re: Adding aspectj module broke the build...

[Les Hazlewood <lh...@apache.org>]

Yes, that was my next recommendation - to ask the community :)

However, I'm totally ok with staying with 1.5 too.  The
JavaEnvironment class in Shiro allows you to program to different APIs
depending on the platform.  I've used this in the past when we
supported 1.4 to return, say, a integer sequence for session IDs,
whereas on 1.5, I just used the UUID class.  I used the
JavaEnvironment class to turn on or off functionality as necessary.

Would this be usable for your needs Kalle?  I know there are still
quite a few Fortune 100 companies that are tied to JDK 1.5 in one way
or another, and we might abandon those users even if they may not have
a voice represented on the user list.  It'd probably be better not to
have to switch unless there is a really compelling reason to do so
(e.g. new language feature or some critical API).

- Les

On Thu, Jan 28, 2010 at 12:41 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> Actually I might feel differently :) I know it sucks that for these
> kind of projects there are much stronger requirements and demand to
> stick with older version of JVM even if most of the users of
> JSecurity/Shiro have happily moved on to newer JVMs ages ago. But
> there's bound to be a few poor souls who are limited to 1.5 Java for
> one reason or another. Since we've been compiling in 1.5 before an
> optional aspectJ module (currently detached) I don't think one
> supporting module is necessarily strong enough reason to move to 1.5,
> even it being end-of-lifed. But hey, I have a crazy idea, maybe we
> should just ask our users :) I'll send an email to users list on this.
> In the meantime, I'll look into making the aspectJ module compile on
> 1.5 (got the 1.5 jdk downloaded...). We can take the decision later
> based on that information.
>
> Kalle
>
>
> On Thu, Jan 28, 2010 at 6:36 AM, Les Hazlewood <lh...@apache.org> wrote:
>> I believe the only reason is that we had a discussion thread about 4
>> or so months ago concurring that we should use 1.5-compatible APIs
>> moving forward (we used to support 1.4 via RetroWeaver at the time).
>>
>> I tend to agree that if 1.5 is already end-of-lifed (and has been for
>> 4 months), it doesn't make much sense to release a brand new (first
>> ever) Shiro release that targets a platform that Sun no longer even
>> supports.
>>
>> Does anyone feel differently?
>>
>> On Tue, Jan 26, 2010 at 3:23 PM, Kalle Korhonen
>> <ka...@gmail.com> wrote:
>>> Bah, I just managed to break the build by adding the new aspectj
>>> module. It fails on:
>>> [INFO] Compilation failure
>>> /export/home/hudson/hudson/jobs/Shiro/workspace/trunk/support/aspectj/src/test/java/org/apache/shiro/aspectj/DummyServiceTest.java:[32,-1]
>>> cannot access org.apache.shiro.aspectj.AspectjAnnotationsAuthorizingMethodInterceptor
>>> bad class file:
>>> /export/home/hudson/hudson/jobs/Shiro/workspace/trunk/support/aspectj/target/classes/org/apache/shiro/aspectj/AspectjAnnotationsAuthorizingMethodInterceptor.class
>>> class file has wrong version 50.0, should be 49.0
>>>
>>> I.e. the builder jdk is 1.5 but 1.6 is required. What I don't get
>>> though is that it just compiled that
>>> AspectjAnnotationsAuthorizingMethodInterceptor but I suppose it's
>>> actually the imported AspectJ classes that are built on jdk 1.6. Now,
>>> 1.5 was end-of-lifed last October. Funny, but I don't even have 1.5
>>> jdk anymore on my system and Sun has really made it difficult to get
>>> to it anymore (just checked).
>>>
>>> What's our policy regarding supporting jre versions? The easiest fix
>>> is probably to use a different builder on Hudson, but we might be
>>> using jdk 1.5 for a reason. I can detach the new module in the
>>> meantime.
>>>
>>> Kalle
>>>
>>
>

Re: Adding aspectj module broke the build...

[Kalle Korhonen <ka...@gmail.com>]

Actually I might feel differently :) I know it sucks that for these
kind of projects there are much stronger requirements and demand to
stick with older version of JVM even if most of the users of
JSecurity/Shiro have happily moved on to newer JVMs ages ago. But
there's bound to be a few poor souls who are limited to 1.5 Java for
one reason or another. Since we've been compiling in 1.5 before an
optional aspectJ module (currently detached) I don't think one
supporting module is necessarily strong enough reason to move to 1.5,
even it being end-of-lifed. But hey, I have a crazy idea, maybe we
should just ask our users :) I'll send an email to users list on this.
In the meantime, I'll look into making the aspectJ module compile on
1.5 (got the 1.5 jdk downloaded...). We can take the decision later
based on that information.

Kalle


On Thu, Jan 28, 2010 at 6:36 AM, Les Hazlewood <lh...@apache.org> wrote:
> I believe the only reason is that we had a discussion thread about 4
> or so months ago concurring that we should use 1.5-compatible APIs
> moving forward (we used to support 1.4 via RetroWeaver at the time).
>
> I tend to agree that if 1.5 is already end-of-lifed (and has been for
> 4 months), it doesn't make much sense to release a brand new (first
> ever) Shiro release that targets a platform that Sun no longer even
> supports.
>
> Does anyone feel differently?
>
> On Tue, Jan 26, 2010 at 3:23 PM, Kalle Korhonen
> <ka...@gmail.com> wrote:
>> Bah, I just managed to break the build by adding the new aspectj
>> module. It fails on:
>> [INFO] Compilation failure
>> /export/home/hudson/hudson/jobs/Shiro/workspace/trunk/support/aspectj/src/test/java/org/apache/shiro/aspectj/DummyServiceTest.java:[32,-1]
>> cannot access org.apache.shiro.aspectj.AspectjAnnotationsAuthorizingMethodInterceptor
>> bad class file:
>> /export/home/hudson/hudson/jobs/Shiro/workspace/trunk/support/aspectj/target/classes/org/apache/shiro/aspectj/AspectjAnnotationsAuthorizingMethodInterceptor.class
>> class file has wrong version 50.0, should be 49.0
>>
>> I.e. the builder jdk is 1.5 but 1.6 is required. What I don't get
>> though is that it just compiled that
>> AspectjAnnotationsAuthorizingMethodInterceptor but I suppose it's
>> actually the imported AspectJ classes that are built on jdk 1.6. Now,
>> 1.5 was end-of-lifed last October. Funny, but I don't even have 1.5
>> jdk anymore on my system and Sun has really made it difficult to get
>> to it anymore (just checked).
>>
>> What's our policy regarding supporting jre versions? The easiest fix
>> is probably to use a different builder on Hudson, but we might be
>> using jdk 1.5 for a reason. I can detach the new module in the
>> meantime.
>>
>> Kalle
>>
>

Re: Adding aspectj module broke the build...

[Les Hazlewood <lh...@apache.org>]

I believe the only reason is that we had a discussion thread about 4
or so months ago concurring that we should use 1.5-compatible APIs
moving forward (we used to support 1.4 via RetroWeaver at the time).

I tend to agree that if 1.5 is already end-of-lifed (and has been for
4 months), it doesn't make much sense to release a brand new (first
ever) Shiro release that targets a platform that Sun no longer even
supports.

Does anyone feel differently?

On Tue, Jan 26, 2010 at 3:23 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> Bah, I just managed to break the build by adding the new aspectj
> module. It fails on:
> [INFO] Compilation failure
> /export/home/hudson/hudson/jobs/Shiro/workspace/trunk/support/aspectj/src/test/java/org/apache/shiro/aspectj/DummyServiceTest.java:[32,-1]
> cannot access org.apache.shiro.aspectj.AspectjAnnotationsAuthorizingMethodInterceptor
> bad class file:
> /export/home/hudson/hudson/jobs/Shiro/workspace/trunk/support/aspectj/target/classes/org/apache/shiro/aspectj/AspectjAnnotationsAuthorizingMethodInterceptor.class
> class file has wrong version 50.0, should be 49.0
>
> I.e. the builder jdk is 1.5 but 1.6 is required. What I don't get
> though is that it just compiled that
> AspectjAnnotationsAuthorizingMethodInterceptor but I suppose it's
> actually the imported AspectJ classes that are built on jdk 1.6. Now,
> 1.5 was end-of-lifed last October. Funny, but I don't even have 1.5
> jdk anymore on my system and Sun has really made it difficult to get
> to it anymore (just checked).
>
> What's our policy regarding supporting jre versions? The easiest fix
> is probably to use a different builder on Hudson, but we might be
> using jdk 1.5 for a reason. I can detach the new module in the
> meantime.
>
> Kalle
>