https://bamboo-ci.codehaus.org/browse/MOJO-MASPECTJ-39
I've excluded tools.jar from the enforceBytecodeVersion and set
mojo.java.target to 1.6, which is also required to get the correct JDK
requirement on the project summary page.
I think we're all happy now, right?
Robert
Op Mon, 08 Sep 2
I basically added a
1.6
property to the a-m-p pom, and upped the JDK version for one of the Bamboo
jobs. (Implying that the a-m-p now builds OK on Bamboo).
This works for the a-m-p alone, but it would of course be a good idea if
all the Mojos from Codehaus have the same basic requirements.
Along
This is an interesting case, because the compile-time JDK is less then the
runtime JDK (1.5 and 1.6 in same order). Normally it's the other way
around.
However, to be able to run the integration tests, you will still need 1.6.
So I'd prefer to change the minimum required Java version to 1.6 so
I don't believe I would need to challenge Mark. (Other than in a Swedish
Poetry slam, of course... )
My point is that the Maven process running a-m-p (i.e. ajdoc) needs access
to the JavaDoc tools and classes which are currently packaged in *tools.jar*.
If these classes are packaged in another jar
Ah, I forgot. Mark position was that there shouldn't be any need for using
tools.jar directly today (JDK 7 or 8 I guess) as everything should be
possible through the JDK API. Dare you challenge him? ;-)
/Anders
On Mon, Sep 8, 2014 at 10:25 AM, Anders Hammar wrote:
> Me and Dennis talked to Mark
Me and Dennis talked to Mark Reinhold at Jfokus earlier this year about the
changes that the jigsaw project will bring and what the impact would be on
the Maven world. One of the things that popped up was that tools.jar is
going away. As I know that there are several plugins that has this
dependenc
This dependency problem is basically caused by the way that the *adjoc*
works - not the a-m-p itself.
*ajdoc* is part of the AspectJ release, and uses standard JDK functionality
to generate a sort of javadoc.
The JavaDoc dependencies are packaged within *tools.jar*.
... so even if the *tools.jar*
My understanding is that tools.jar is going to be removed in the (Oracle)
Java 9 JDK. So it would be good to get away from that dependency, unless
you want a new problem when Java 9 is released.
/Anders
On Mon, Sep 8, 2014 at 8:30 AM, Lennart Jörelid
wrote:
> So - let's see if we can get the JD
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
Op Tue, 02 Sep 2014 23:44:10 +0200 schreef Lennart Jörelid
:
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
If comes from the extra maven-enforcer-plugin rule that was added in the
last checkin.
I will take a look at this tomorrow and see if I can get everything to
build properly.
2014-09-03 0:02 GMT+02:00 Dan Tran :
> i meant, I am NOT able to build this plugin any more ( maven 3.2.3, java
> 1.7.x)
i meant, I am NOT able to build this plugin any more ( maven 3.2.3, java
1.7.x)
On Tue, Sep 2, 2014 at 3:01 PM, Dan Tran wrote:
> btw, I am able to build this plugin any more ( maven 3.2.3, java 1.7.x)
>
> [INFO] Artifact com.sun:tools:jar:1.7.0_55:system contains .class compiled
> with incorre
btw, I am able to build this plugin any more ( maven 3.2.3, java 1.7.x)
[INFO] Artifact com.sun:tools:jar:1.7.0_55:system contains .class compiled
with incorrect version
[INFO] Artifact org.aspectj:aspectjtools:jar:1.8.0:compile contains .class
compiled with incorrect version
[WARNING] Rule 0: org
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.
Therefor
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, p
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
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
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 th
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.
what do we need from codehaus bamboo?
Thanks
-D
On Tue, Sep 2, 2014 at 9:06 AM, Lennart Jörelid
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
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 :
> should we go ehead to push
should we go ehead to push this release out?
Thanks
-D
On Wed, Aug 20, 2014 at 12:08 PM, Anders Hammar 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
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 wrote:
> Hi Sergei, you are right, i have a convenient script to 'cd' into my dev
> tree like this
>
> @echo off
> cd c:\views\d
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
wrote:
> Hi Dan,
>
> Looks like the drive letter C: differs in case between
Hello all,
In the interests of limiting these kinds of problems in the future, it
would be really great to run a CI server slave on the Windows OS as well.
While I'm certain that at least committer has the facilities to set this
up, I'm thinking that it would be really great for us all if such a C
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 :
>no problem building on linux for both j
25 matches
Mail list logo
