[
https://issues.jboss.org/browse/JBIDE-12087?page=com.atlassian.jira.plugi...
]
Snjezana Peco commented on JBIDE-12087:
---------------------------------------
{quote}
Referencing the JDK in the factory path is irrelevant to that bug.
{quote}
I have said this bug is caused by adding jars from the classpath to .factorypath. This way
the project's classpath is included in the OSGi classpath so that the problem happens
in many places. The problem with jboss-as7 is only one of them.
{quote}
As for all the jars being put to the factory path, I haven't found a better way : CLI
builds use all the APs found in the project classpath, and we have no way to know what
jars are irrelevant to annotation processing. If you have any suggestions to improve the
current implementation, I'm all ears.
{quote}
You can't use the same technique in the Eclipse environment as in CLI. CLI has only
one classloader when compiling a project. Eclipse's plugins have their own
classloaders.
Adding all project's jars to .factorypath will cause different issues because
annotation processing happens in the context of the Java builder. The Eclipse apt is a
Java compiler participant.
Beside, in most of the cases the user won't use all the annotations processors defined
on the classpath. Annotation processing decreases performance of the Java builder.
Annotation processors are being added only if they are necessary. I suppose that is the
main reason why it isn't added to Eclipse automatically.
Why would somebody, for instance, add apt from tools.jar if he doesn't use JDK's
jaxrs services.
In my opinion, it would be the best to enable APT when existing .factorypath in the
project's root because we can't know when APT is required and what jars need to be
added to .factorypath. This idea coming from WELD-835. Since .factorypath is already
defined, you don't have to regenerate it.
Re the workaround
I propose m2e-apt to be disabled by default. Otherwise, there will be different issues in
Eclipse/JBT/JBDS because of incorrectly defined .factorypath.
JBoss AS 7 is just an example Craig found.
JDS5 beta 3 crashes when importing JBoss AS 7.1.1.Final Maven
project
---------------------------------------------------------------------
Key: JBIDE-12087
URL:
https://issues.jboss.org/browse/JBIDE-12087
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: maven
Environment: $ uname -a
Linux ichindar.localdomain 3.3.7-1.fc17.x86_64 #1 SMP Mon May 21 22:32:19 UTC 2012 x86_64
x86_64 x86_64 GNU/Linux
$ lsb_release -a
LSB Version: :core-4.0-amd64:core-4.0-noarch
Distributor ID: Fedora
Description: Fedora release 17 (Beefy Miracle)
Release: 17
Codename: BeefyMiracle
$ java -version
java version "1.7.0_b147-icedtea"
OpenJDK Runtime Environment (fedora-2.1.fc17.6-x86_64)
OpenJDK 64-Bit Server VM (build 22.0-b10, mixed mode)
Reporter: Craig Ringer
Assignee: Fred Bricon
Priority: Blocker
Fix For: 3.3.0.CR1
Attachments: import-error-log.log.gz
When attempting to import JBoss AS 7.1.1.Final, checked out from git, as a Maven project
into JBoss Developer Studio 5.0 beta 3 on an x64 Fedora machine with JDK7, JBoss Developer
Studio becomes unresponsive partway through the import. It sometimes then fails with an
error message, and sometimes just ends up stuck in what appears to be some kind of
infinite loop until killed.
I haven't installed any add-ons or extras, it's stock JBoss Developer Studio 5.0
Beta 3.
I've tried increasing the memory parameters from the already generous initial
allocations to:
-Xms512m
-Xmx1592m
with no improvement. I have 8GB to play with so I'll be throwing a ridiculous amount
of RAM at and trying again, but this should not be necessary in any case, not just to
*import* a maven project, even a big one.
All I'm trying to do is import AS7 so I can add the AS7 project to the source search
path when debugging a test case that's triggering a bug in AS7, so I don't have to
manually add each and every source jar from as7 to my source search path. This seemed like
the easy way to do it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira