So - let's see if we can get the JDK versions and idea behind
banning
certain dependencies straight here.
There are 3 Java/JDK versions of relevance for the a-m-p:
1. The Java bytecode version when compiling the a-m-p. This is
normally defined in the mojo-parent POM using the variable
"mojo.java.target" (which has the value 1.5 in version 33 of the
mojo-parent).
2. The Java version of the JRE used when running the a-m-p as
part
of a maven POM. Assuming that the correct JDK specification is
used within
the target POM, the AJC compiler invoked by the a-m-p will
generate
bytecode of the same java version as the compiler expects.
3. The Java version of the JDK used within the Maven process
building the site for the a-m-p-enabled project. This defines the
*tools.jar* used to generate the documentation (or, rather, used
by the *ajdoc* tool to generate the AspectJ documentation). If
tools.jar is not found on the classpath, the following message
is shown in
the debug log: *ajdoc requires a JDK 1.4 or later tools jar -
exiting*
Now - if I understand things correctly:
1. We should include the latest stable aspectjtools dependency
(i.e. in the 1.8 version series). The 1.8 version of AspectJ is
built using
a JDK later than 1.5 - implying that we cannot enforce max JDK
version as
1.5. This leaves us with 2 choices:
1. Explicitly increase the JDK version requirements in the
a-m-p POM
2. Refrain from enforcing a max JDK when building the a-m-p.
(Simpler, but possibly laden with bytecode version errors in
runtime).
2. The AJC Java compliance version supplied must simply match
the target JDK version. No changes here.
3. Unless the tools.jar dependency is actually included in the
classpath of the A-M-P, the ajdoc tool cannot produce the
AspectJ site. We
can cope with this in 2 ways:
1. Simply include the tools.jar dependency in the a-m-p plugin
POM and brace for tools.jar change impact when generating
sites with an
unknown tools.jar/JDK version. Mostly, this seems to be an
approach that
works well.
2. Force a-m-p users to explicitly include a *tools.jar*
dependency in every parent POM where the a-m-p is used in
order to be able
to generate the AspectJ site. I believe it would be overly
complex.
Unless someone has strong opinions for another approach, I intend
to:
- Remove the bytecode-level enforcement from the a-m-p POM, as
per
the thoughs under 1 above.
- Keep the tools.jar dependency in the a-m-p POM, as per the
thoughts under 3 above.
2014-09-04 21:07 GMT+02:00 Robert Scholte
<codeh...@sourcegrounds.com>
:
Op Tue, 02 Sep 2014 23:44:10 +0200 schreef Lennart Jörelid <
lennart.jore...@gmail.com>:
I just noted, but adding a Max JDK version doesn't seem to make
any
sense
in this case.
The AspectJ compiler will generate bytecode compliant with a
certain
JDK
version, implying that performing bytecode manipulation (i.e.
calling AJC)
without that JDK version present will cause problems.
No, you misunderstood the reason for this rule.
It means that dependencies must be compiled with JDK5 or less (for
that reason it is called Max).
Since the aspectjtools.jar is compiled with JDK6 (or higher), which
means that you can't use it with JDK5.
This has *nothing* to with the generated bytecode by AspectJ, only
with the runtime requirement of the AspectJ compiler.
Ideally you use both animal-sniffer for sources and
enforceBytecodeVersion for dependencies. In fact, let's do this
for the
mojo-parent so all plugins will work fine.
thanks,
Robert
Therefore, I believe we must validate the AspectJ Maven plugin on
appropriate JDKs.
It might make sense to restrict the JDK used (by bamboo etc.) to
be
equal
to the Java version specified in the AJC runtime arguments,
though.
That would effectively be the same as setting a *maximum* JDK
version.
2014-09-02 23:30 GMT+02:00 Robert Scholte <
codeh...@sourcegrounds.com>:
Hi,
I've added the enforceBytecodeVersion rule to see which jar(s)
are
causing
problems.
It seems that aspectjtools can't run with JDK5.
As long as org.aspectj.tools.ajc.Main.Main() is called within the
same
JVM, we need to upgrade the JDK requirement.
Otherwise we need to start a new JVM, preferably with toolchains
to
manage
the JDK versions. Not sure if it's worth it to implement, though.
For me this is a valid reason to change the required JDK, I'll
leave it up
to you.
Robert
Op Tue, 02 Sep 2014 23:00:26 +0200 schreef Robert Scholte <
codeh...@sourcegrounds.com>:
Hi,
I've fixed the unittest, next step is to fix the integration
tests.
I've added a JDK8 task to the integration tests, so now it will
be
tested
with the minimum (JDK5) and maximum, both with Maven-2.2.1.
There are only linux bambooo-agents available right now.
According
to
JIRA[1] there has never been a request to support more operating
systems,
so go ahead and ask.
In the meantime I can verify it with Win7 + most of the JDKs
available at
home.
thanks,
Robert
ps. to log on and configure: https://bamboo-ci.codehaus.
org/userlogin!default.action
[1] https://jira.codehaus.org/browse/HAUS/component/12684
Op Tue, 02 Sep 2014 21:25:33 +0200 schreef Dan Tran <
dant...@gmail.com>:
Hi Anders, Robert, Karl
Are you able to help with this issue at bamboo setup?
Thanks
-D
On Tue, Sep 2, 2014 at 10:33 AM, Lennart Jörelid <
lennart.jore...@gmail.com>
wrote:
We need to set up a few projects in Bamboo where the
aspectj_maven_plugin
is compiled using different kinds of JDKs. This is to validate
that the
AspectJ compiler options for the respective JDKs do not cause
java.lang.UnsupportedClassVersionError: Bad version number in
.class
file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:
620)
... as is currently the case with a unit/integration test for
the
AspectJ
maven plugin.
We would also really need a Windows execution environment on
Codehaus
Bamboo - although I'm aware that this is stretching things a
bit. This
is
simply to ensure that none of our ITs and plugins fail to
properly
encode
paths and other OS-specific things.
2014-09-02 18:30 GMT+02:00 Dan Tran <dant...@gmail.com>:
what do we need from codehaus bamboo?
Thanks
-D
On Tue, Sep 2, 2014 at 9:06 AM, Lennart Jörelid <
lennart.jore...@gmail.com> wrote:
No, we should not.
https://bamboo-ci.codehaus.org/browse/MOJO-MASPECTJ
Fails since we have been unable - thus far - to create a new
project
with JDK 8 support.
If we could get that done, we would be one step closer to
release.
2014-09-02 17:46 GMT+02:00 Dan Tran <dant...@gmail.com>:
should we go ehead to push this release out?
Thanks
-D
On Wed, Aug 20, 2014 at 12:08 PM, Anders Hammar <
and...@hammar.net>
wrote:
I filed a ticket for this:
http://jira.codehaus.org/browse/MASPECTJ-135
Feel free to add more info as you see fit.
/Anders
On Wed, Aug 20, 2014 at 3:56 PM, Dan Tran
<dant...@gmail.com
>
wrote:
Hi Sergei, you are right, i have a convenient script to
'cd' into
my
dev tree like this
@echo off
cd c:\views\dev
so the fix is ( for now)
@echo off
cd C:\views\dev
On Tue, Aug 19, 2014 at 11:35 PM, Sergei Ivanov <
sergei_iva...@mail.ru> wrote:
Hi Dan,
Looks like the drive letter C: differs in case between
expected
and
actual. You may want to change the test script to use
case-insensitive
comparison on windows.
Regards,
--
Sergei Ivanov
Wednesday, 20 August 2014 07:26 +0100 from Dan Tran <
dant...@gmail.com>:
no problem building on linux for both java 7 and 8
also works inside my windows eclipse IDE.
Must have someting to do with my env.
Thanks
-D
On Tue, Aug 19, 2014 at 11:04 PM, Dan Tran <
dant...@gmail.com >
wrote:
>not sure why, but i am not able to build it locally
using
both
java
7 and 8 on windows (have not try it on linux yet )
>
>[INFO] Building: JavaSourcesDefault\pom.xml
>[INFO] run script verify.groovy
>[INFO] ..FAILED (2.7 s)
>[INFO] The post-build script did not succeed. assert
execLine.endsWith( fooClazz.getAbsolutePath() )
> | | | |
> | false |
c:\views\dev\mojo\mojo\aspectj-maven-plugin\target\
it\JavaSourcesDefault\src\main\java\foo\Clazz.java
> |
c:\views\dev\mojo\mojo\aspectj-maven-plugin\target\
it\JavaSourcesDefault\src\main\java\foo\Clazz.java
> [DEBUG] Running : ajc -1.4 -classpath
C:\views\dev\mojo\mojo\aspectj-maven-plugin\target\
local-repo\org\aspectj\aspectjrt\1.8.0\aspectjrt-1.8.
0.jar;C:\views\dev\mojo\mojo\aspectj-maven-plugin\t
>arget\it\JavaSourcesDefault\target\classes -d
C:\views\dev\mojo\mojo\aspectj-maven-plugin\target\
it\JavaSourcesDefault\target\classes
C:\views\dev\mojo\mojo\aspectj-maven-plugin\target\
it\JavaSourcesD
>efault\src\main\java\foo\Clazz.java
>[INFO] Building: JavaSourcesEmpty\pom.xml
>[INFO] run script verify.groovy
>[INFO] ..SUCCESS (2.1 s)
>[INFO] Building: JavaSourcesList\pom.xml
>[INFO] run script verify.groovy
>[INFO] ..FAILED (2.5 s)
>[INFO] The post-build script did not succeed. assert
execLine.endsWith( fooClazz.getAbsolutePath() )
> | | | |
> | false |
c:\views\dev\mojo\mojo\aspectj-maven-plugin\target\
it\JavaSourcesList\src\java\foo\Clazz.java
> |
c:\views\dev\mojo\mojo\aspectj-maven-plugin\target\
it\JavaSourcesList\src\java\foo\Clazz.java
> [DEBUG] Running : ajc -1.4 -classpath
C:\views\dev\mojo\mojo\aspectj-maven-plugin\target\
local-repo\org\aspectj\aspectjrt\1.8.0\aspectjrt-1.8.
0.jar;C:\views\dev\mojo\mojo\aspectj-maven-plugin\t
>arget\it\JavaSourcesList\target\classes -d
C:\views\dev\mojo\mojo\aspectj-maven-plugin\target\
it\JavaSourcesList\target\classes
C:\views\dev\mojo\mojo\aspectj-maven-plugin\target\
it\JavaSourcesList\sr
>c\java\foo\Clazz.java
>
>
>
>On Tue, Aug 19, 2014 at 10:44 PM, Lennart Jörelid <
lennart.jore...@gmail.com > wrote:
>>Yes.
>>
>>We have presently some Bamboo setup issues, but the
code
has
built
locally for me since quite awhile.
>>Thus, it is presently more of a Bamboo issue than a
development
one.
>>
>>
>>2014-08-19 22:42 GMT+02:00 Dan Tran <
dant...@gmail.com
> :
>>
>>>Hello MOJO team,
>>>
>>>any plan to push 1.7 out for JDK 8 support?
>>>
>>>Thanks
>>>
>>>-D
>>
>>
>>--
>>--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: l...@jguru.se
| URL: www.jguru.se
| Phone
| (skype): jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: l...@jguru.se
| URL: www.jguru.se
| Phone
| (skype): jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: l...@jguru.se
| URL: www.jguru.se
| Phone
| (skype): jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
------------------------------------------------------------
---------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
------------------------------------------------------------
---------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: l...@jguru.se
| URL: www.jguru.se
| Phone
| (skype): jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
