Who deleted the Eclipse settigns from svn?

Sry, but can you give me a link or something that gives me some hints about the importance of the build.xml? I searched the wiki for some time and had a look at the ant-script itself and I actually don’t see the point!?

I’m not that much experienced with jME3 yet, but my workflow would be first to setup a jme3-project in the sdk. Then import that in eclipse with setting a dependecy on my jme3-engine in eclipse (the one imported from svn).

Doing my work in eclipse and at the very end if needed using the sugar you created with the sdk especially the export-stuff. I don’t see any need of using the build.xml with eclipse. Maybe you can point to the right direction…

A build.xml file is like a makefile for C or C++ programs, ANT is the standard build environment for java projects. You just use it to build/run the project and any distribution jar files…

In our case it also builds the android library which needs the android.jar and the two bullet versions which need to be compiled separately as they overlap namespace-wise. Its no problem building e.g. only the desktop-relevant source parts of jME3 in an eclipse project as said. I outline the changes in the jme distribution that are realized by the script here:

http://hub.jmonkeyengine.org/groups/development-discussion-jme3/forum/topic/library-and-source-cleanups-bye-bye-jmonkeyengine3-jar/



Exactly because of the “standard” workflow you outline the project file was removed. We’d have to maintain eclipse project files for jme with bullet, jme with jbullet, jme for android, jme with blender libraries, without blender libraries etc etc etc. Rather we provide a normal build script that creates jar files that can be combined to your liking.

@ttrocha the idea is to have a a pair of .project and .classpath files that are automatically maintained by Hudson when the nightly builds are run so that when a new dependency is added in NetBeans, its added to the Eclipse project.

BTW, there is some forward momentum on this. Eclipse has functionality built in to generate projects from preexisting ANT files. The problem, for us, is that it won’t follow linked ANT files which is where the javac directives are. I’m stumped by this one, but it may be as simple as making a patch for Eclipse and submitting it. It can’t be that hard, can it?

Ok, thx for the (try of) clearification. I understand that you want the system to be perfect and consistent and you are doing a great job with this. Having this build-files creating the jars is invaluable.

But what has building jars and dll/so to do with using the engine?



When I write my application I write against the source of the engine. I do not care about having all the source-folders included during development-process. Of course I have to setup my engine-project as I want it to be. (Don’t see a reason why you have to provide different setups for that. A standard setup, that would have to be tweaked, would be enough . That worked for the last years and I don’t see a reason why that should work for the next years as well).



Once I would like to deploy my application somewhere I can use the the jars instead of the source-dependency and make a starter by hand or use JMP.



Well,sry seems that I didn’t get it :frowning:



edit: @sbook yeah, tried this as well! Too bad that this didn’t worked

Yes @ttrocha, and other people want to have a maven pom file or maybe build it with a makefile… But we cannot keep all these files updated. Try adding all source folders of jME3 to one Eclipse project and you will see what I mean about “no standard project”.



The Eclipse project file for jME3 isn’t there for years and the fact that there was one for jME2 is only due to the fact that the core developers accidentally also used Eclipse. They also did, like any good java project, supply an ant build file that they in fact used for building the project and the releases. I am sorry that it seems otherwise to many Eclipse users but creating, importing and generally using jar files for libraries is a standard in java. I seriously am, I don’t know why so many java standards like “having a library on the classpath” seem to make no sense to Eclipse users, maybe the user-friendliness goes too far, I don’t know.



What is exact the issue you have? In NetBeans I can perfectly well browse the source and javadoc while still using the jar files… If you don’t constantly modify the engine what is the point in having a project that references the whole source of a library in your build process? What exactly does make that seem feasible? (Actual question!)

@normen said:
1. What is exact the issue you have? In NetBeans I can perfectly well browse the source and javadoc while still using the jar files..
2. If you don't constantly modify the engine what is the point in having a project that references the whole source of a library in your build process?
3. What exactly does make that seem feasible? (Actual question!)


1. This is possible in Eclipse as well, tho you have to configure it manually AFTER each update from svn, if any path changed, since the svn updates kills my .project file. (Well more the revert, but I usually do revert, update, because I often modify the testcases to prototype stuff quickly). Changing a few details in the shaders, to test if it lokks better for my usecase. (and if it does only then i create a own seperate version)

2. Well i somewhat do, see 1.

3. Also continues integration, I only need to rightclick, team, update, and then maybee fix 1-2 errors and I'm building against the actual api.
Else I could run that build.xml once a day of course, however I will probably forget it (since it does not run automatically at the end of svn update, while the eclipse builder does. Probably possible to configure so that it will, but after next update that eclipse file is lost again -> 4) and only do it every few weeks then, wich means I need to change much more at once.

4. Thinking about this, how about a compromise, having a eclipse project setup, taht configures the build.xml as the default builder, that is automatically executed on code changes. Then eclipse users would use the offical build system, the eclipse .project would never outdate as long as the file is still named build.xml, and all configs like where the javadoc folder is could be saved, and updated from svn.
1 Like

@normen:

First, of all I want to clearify that I’m not “fighting” (only) for myself here. It is absolutely no problem to download the engine and setup a project.

BUT only because I know about the structure (more or less). When I start playing around with a new project e.g. jME3, I love to checkout the latest

svn, will be happy to see a huge folder with millions of self explanatory tests and find a default-setup that just compiles and let me just start some tests. And I’m quite sure others would do it the same way…Still don’t (and won’t?) understand it…



By the way the eclipse-project was uptodate until the end…at least one or two weeks ago…No problem that the eclipse-people keep that update on their own…



Actually, I just started to argue against your points. But I think it’s senseless…



I’m out here :smiley: Keep on your good work. Now I will concentrate on starting over again with the competition :smiley:



Keep on rocking…

This is like talking to a wall… I said from the start the Eclipse project should use the build script and that would be fine. Still all my points are valid. Everything you mentioned as “practical” about having an Eclipse project can be done (better) by setting up your own eclipse project. Updating from svn and everything else. Especially Empire’s issue with his project shows nicely why its silly to use a project file from somebody else. None of you answered my question though, so I guess I will never understand the issues of Eclipse users. Again, we will not provide build scripts or project files for every IDE and build system out there.

Well the wall are you … it’s just as try to net see our point of view with all power you have. Also you stil have nto answerd about a default project for eclise taht simply uses the official build.xml.



Not to meintion, you always talk about all othe ide’s… THERE ARE ONLY ECLIPSE AND NETBEANS for serious java developing, those two share around 80-90% of all java developers. (Well actually eclipse has around 80% alone, so basically saying we support eclipse as the main build system would be more logical)



Not to mention, if you realy want this IDE independent, why is the nbproject folder still there? I assume for netbeans just a folder with stuff and a build.xml would be good enough as well.



But you know what, forget it, A discussion is senseless if the other side does not listen.

1 Like
@normen said:
sbook is looking into getting a project for eclipse to work that uses the build.xml, if that works out we'll add that.

@normen said:
I said from the start the Eclipse project should use the build script and that would be fine. Still all my points are valid.

@EmpirePhoenix said:
Well the wall are you … it’s just as try to net see our point of view with all power you have. Also you stil have nto answerd about a default project for eclise taht simply uses the official build.xml.

:? :? :? You are really just trying to upset me right? You are the ones not giving me any reasons when I ask for them.

If you carefully look at the build script, the nbproject folder is part of it. A normal xml build script would be fine as well, I for one have no issue setting up a project for that xD But this build script is better, it doesn't recompile stuff etc etc. I am sorry that the Eclipse developers did not choose to support standard java build procedures this way or that most core devs use NetBeans but the project is set up with that.

Again, the purpose of a project build file is to build the resulting product. Thats what this build file does. You would not expect a site to install two forums on one site and link the same database content into both of them just because some users like one forum software better, would you? Obviously thats way too cumbersome to handle and leads to problems. If you want the source of jME3 then download and use it like you would download and use any source. If you want the properly built project, use the build file.. its easy.

Also again, having an Eclipse project file would imply that a) it builds the resulting product like expected or b) that developers that want to contribute can use it to create code for the engine, neither of which is true. When using that project file you are prone to miss dependency issues or ignore parts of the code altogether (native bullet, android etc.) so its better its not there at all. And there indeed ARE OTHER BUILD SYSTEMS (sorry, gotta scream back if being screamed at) as for example maven and we do not support that too.

By the way let me mention that I cannot remember any NetBeans or other IDE user being *this* upset about the project not having a *project* file for their IDE set up for them. I think I understand you better than you think and it would definitely have been better it wouldn't have been there in the first place.
@normen said:
If you carefully look at the build script, the nbproject folder is part of it. A normal xml build script would be fine as well, I for one have no issue setting up a project for that xD But this build script is better, it doesn't recompile stuff etc etc. I am sorry that the Eclipse developers did not choose to support standard java build procedures this way or that most core devs use NetBeans but the project is set up with that.


The project and classpath files aren't about building, they're about working with source. One can simply use the build.xml to distribute the jME.


Which build target should I be trying against? Most of the targets are private and create-zip-distribution needs the directories already built. This isn't an Eclipse thing, this is an ant thing. Checked it out through command line on a linux box and just running that target from the command line is a no-joy.

@normen said:
Again, the purpose of a project build file is to build the resulting product. Thats what this build file does. You would not expect a site to install two forums on one site and link the same database content into both of them just because some users like one forum software better, would you? Obviously thats way too cumbersome to handle and leads to problems. If you want the source of jME3 then download and use it like you would download and use any source. If you want the properly built project, use the build file.. its easy.


[Emphasis above is mine] Except it won't work from the CLI without manually creating the directories that the target needs. Which means that the user needs to: a) know what ANT is and b) have the gusto to open the file, read through it, and make sense of which directories to create.
1 Like

Theres ant jar which creates the jar files and ant run which runs the tests, both work out of the box.

OK cool, that’s a start. There’s still the all-encompassing jMonkeyEngine3.jar being built by default I noticed. Should be able to ignore that in favor of the lib and opt folders, right?

Theres no all-encompassing jMonkeyEngine3.jar, its just a jar containing the tests and a manifest that references all libraries (also the native bullet ones so they can just be dropped in the lib folder).

OK, so the thing that’s still getting me is that NetBeans isn’t doing everything from the build file. There’s still the very important project.xml that splits up the source directories. This is what drives to the root of the problem for most of us.



EDIT: so the follow-up is: will NetBeans generate the structure automatically if the project.xml file disappeared?

No, theres simply separate javac commands for the separate source folders, nothing to do with project.xml

Actual if the ant file would work under eclipse, I would only haft that pissed…



This is what happens if you use a clean svn download, and run the ant file

[patch]Buildfile: C:workspacejme3nbprojectbuild-impl.xml

-pre-init:

-init-private:

-pre-init-libraries:

-init-private-libraries:

-init-libraries:

-init-user:

-init-project:

-init-macrodef-property:

-do-init:

-post-init:

-init-check:

-init-ap-cmdline-properties:

-init-macrodef-javac-with-processors:

-init-macrodef-javac-without-processors:

-init-macrodef-javac:

-init-macrodef-junit:

-init-debug-args:

-init-macrodef-nbjpda:

-init-macrodef-debug:

-init-macrodef-java:

-init-presetdef-jar:

-init-ap-cmdline-supported:

-init-ap-cmdline:

init:

-deps-jar-init:

[delete] Deleting: C:workspacejme3buildbuilt-jar.properties

deps-jar:

-warn-already-built-jar:

[propertyfile] Updating property file: C:workspacejme3buildbuilt-jar.properties

-check-automatic-build:

-clean-after-automatic-build:

-verify-automatic-build:

-pre-pre-compile:

-pre-compile:

-copy-persistence-xml:

-compile-depend:

-do-compile:

[javac] Compiling 783 source files to C:workspacejme3buildclasses

[javac] warning: [options] bootstrap class path not set in conjunction with -source 1.5

[javac] C:workspacejme3srcblendercomjme3scenepluginsblenderconstraintsConstraintInverseKinematics.java:47: warning: unmappable character for encoding UTF-8

[javac] //TODO: to nie mo�e by� null, utworzy� dane bez ruchu, w zale�no�ci czy target si� rusza

[javac] ^

[javac] C:workspacejme3srcblendercomjme3scenepluginsblenderconstraintsConstraintInverseKinematics.java:47: warning: unmappable character for encoding UTF-8

[javac] //TODO: to nie mo�e by� null, utworzy� dane bez ruchu, w zale�no�ci czy target si� rusza

[javac] ^

[javac] C:workspacejme3srcblendercomjme3scenepluginsblenderconstraintsConstraintInverseKinematics.java:47: warning: unmappable character for encoding UTF-8

[javac] //TODO: to nie mo�e by� null, utworzy� dane bez ruchu, w zale�no�ci czy target si� rusza

[javac] ^

[javac] C:workspacejme3srcblendercomjme3scenepluginsblenderconstraintsConstraintInverseKinematics.java:47: warning: unmappable character for encoding UTF-8

[javac] //TODO: to nie mo�e by� null, utworzy� dane bez ruchu, w zale�no�ci czy target si� rusza

[javac] ^

[javac] C:workspacejme3srcblendercomjme3scenepluginsblenderconstraintsConstraintInverseKinematics.java:47: warning: unmappable character for encoding UTF-8

[javac] //TODO: to nie mo�e by� null, utworzy� dane bez ruchu, w zale�no�ci czy target si� rusza

[javac] ^

[javac] C:workspacejme3srcblendercomjme3scenepluginsblenderconstraintsConstraintInverseKinematics.java:47: warning: unmappable character for encoding UTF-8

[javac] //TODO: to nie mo�e by� null, utworzy� dane bez ruchu, w zale�no�ci czy target si� rusza

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletPhysicsSpace.java:64: error: duplicate class: com.jme3.bullet.PhysicsSpace

[javac] public class PhysicsSpace {

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletcollisionPhysicsCollisionEvent.java:44: error: duplicate class: com.jme3.bullet.collision.PhysicsCollisionEvent

[javac] public class PhysicsCollisionEvent extends EventObject {

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletcollisionPhysicsCollisionEventFactory.java:40: error: duplicate class: com.jme3.bullet.collision.PhysicsCollisionEventFactory

[javac] public class PhysicsCollisionEventFactory {

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletcollisionPhysicsCollisionObject.java:55: error: duplicate class: com.jme3.bullet.collision.PhysicsCollisionObject

[javac] public abstract class PhysicsCollisionObject implements Savable {

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletcollisionPhysicsRayTestResult.java:42: error: duplicate class: com.jme3.bullet.collision.PhysicsRayTestResult

[javac] public class PhysicsRayTestResult {

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletcollisionPhysicsSweepTestResult.java:40: error: duplicate class: com.jme3.bullet.collision.PhysicsSweepTestResult

[javac] public class PhysicsSweepTestResult {

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletcollisionshapesBoxCollisionShape.java:47: error: duplicate class: com.jme3.bullet.collision.shapes.BoxCollisionShape

[javac] public class BoxCollisionShape extends CollisionShape {

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletcollisionshapesCapsuleCollisionShape.java:46: error: duplicate class: com.jme3.bullet.collision.shapes.CapsuleCollisionShape

[javac] public class CapsuleCollisionShape extends CollisionShape{

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletcollisionshapesCollisionShape.java:46: error: duplicate class: com.jme3.bullet.collision.shapes.CollisionShape

[javac] public abstract class CollisionShape implements Savable {

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletcollisionshapesCompoundCollisionShape.java:53: error: duplicate class: com.jme3.bullet.collision.shapes.CompoundCollisionShape

[javac] public class CompoundCollisionShape extends CollisionShape {

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletcollisionshapesConeCollisionShape.java:20: error: duplicate class: com.jme3.bullet.collision.shapes.ConeCollisionShape

[javac] public class ConeCollisionShape extends CollisionShape {

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletcollisionshapesCylinderCollisionShape.java:47: error: duplicate class: com.jme3.bullet.collision.shapes.CylinderCollisionShape

[javac] public class CylinderCollisionShape extends CollisionShape {

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletcollisionshapesGImpactCollisionShape.java:53: error: duplicate class: com.jme3.bullet.collision.shapes.GImpactCollisionShape

[javac] public class GImpactCollisionShape extends CollisionShape {

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletcollisionshapesHeightfieldCollisionShape.java:31: error: duplicate class: com.jme3.bullet.collision.shapes.HeightfieldCollisionShape

[javac] public class HeightfieldCollisionShape extends CollisionShape {

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletcollisionshapesHullCollisionShape.java:16: error: duplicate class: com.jme3.bullet.collision.shapes.HullCollisionShape

[javac] public class HullCollisionShape extends CollisionShape {

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletcollisionshapesMeshCollisionShape.java:54: error: duplicate class: com.jme3.bullet.collision.shapes.MeshCollisionShape

[javac] public class MeshCollisionShape extends CollisionShape {

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletcollisionshapesPlaneCollisionShape.java:22: error: duplicate class: com.jme3.bullet.collision.shapes.PlaneCollisionShape

[javac] public class PlaneCollisionShape extends CollisionShape{

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletcollisionshapesSimplexCollisionShape.java:20: error: duplicate class: com.jme3.bullet.collision.shapes.SimplexCollisionShape

[javac] public class SimplexCollisionShape extends CollisionShape {

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletcollisionshapesSphereCollisionShape.java:46: error: duplicate class: com.jme3.bullet.collision.shapes.SphereCollisionShape

[javac] public class SphereCollisionShape extends CollisionShape {

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletjointsConeJoint.java:52: error: duplicate class: com.jme3.bullet.joints.ConeJoint

[javac] public class ConeJoint extends PhysicsJoint {

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletjointsHingeJoint.java:52: error: duplicate class: com.jme3.bullet.joints.HingeJoint

[javac] public class HingeJoint extends PhysicsJoint {

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletjointsPhysicsJoint.java:45: error: duplicate class: com.jme3.bullet.joints.PhysicsJoint

[javac] public abstract class PhysicsJoint implements Savable {

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletjointsPoint2PointJoint.java:51: error: duplicate class: com.jme3.bullet.joints.Point2PointJoint

[javac] public class Point2PointJoint extends PhysicsJoint {

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletjointsSixDofJoint.java:60: error: duplicate class: com.jme3.bullet.joints.SixDofJoint

[javac] public class SixDofJoint extends PhysicsJoint {

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletjointsSliderJoint.java:50: error: duplicate class: com.jme3.bullet.joints.SliderJoint

[javac] public class SliderJoint extends PhysicsJoint {

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletjointsmotorsRotationalLimitMotor.java:38: error: duplicate class: com.jme3.bullet.joints.motors.RotationalLimitMotor

[javac] public class RotationalLimitMotor {

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletjointsmotorsTranslationalLimitMotor.java:40: error: duplicate class: com.jme3.bullet.joints.motors.TranslationalLimitMotor

[javac] public class TranslationalLimitMotor {

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletobjectsPhysicsCharacter.java:50: error: duplicate class: com.jme3.bullet.objects.PhysicsCharacter

[javac] public class PhysicsCharacter extends PhysicsCollisionObject {

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletobjectsPhysicsGhostObject.java:58: error: duplicate class: com.jme3.bullet.objects.PhysicsGhostObject

[javac] public class PhysicsGhostObject extends PhysicsCollisionObject {

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletobjectsPhysicsRigidBody.java:62: error: duplicate class: com.jme3.bullet.objects.PhysicsRigidBody

[javac] public class PhysicsRigidBody extends PhysicsCollisionObject {

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletobjectsPhysicsVehicle.java:66: error: duplicate class: com.jme3.bullet.objects.PhysicsVehicle

[javac] public class PhysicsVehicle extends PhysicsRigidBody {

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletobjectsVehicleWheel.java:46: error: duplicate class: com.jme3.bullet.objects.VehicleWheel

[javac] public class VehicleWheel implements Savable {

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletobjectsinfosRigidBodyMotionState.java:47: error: duplicate class: com.jme3.bullet.objects.infos.RigidBodyMotionState

[javac] public class RigidBodyMotionState {

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletutilDebugShapeFactory.java:51: error: duplicate class: com.jme3.bullet.util.DebugShapeFactory

[javac] public class DebugShapeFactory {

[javac] ^

[javac] C:workspacejme3srcbulletcomjme3bulletjointsSixDofSpringJoint.java:67: error: cannot find symbol

[javac] enableSpring(objectId, index, onOff);

[javac] ^

[javac] symbol: variable objectId

[javac] location: class SixDofSpringJoint

[javac] C:workspacejme3srcbulletcomjme3bulletjointsSixDofSpringJoint.java:72: error: cannot find symbol

[javac] setStiffness(objectId, index, stiffness);

[javac] ^

[javac] symbol: variable objectId

[javac] location: class SixDofSpringJoint

[javac] C:workspacejme3srcbulletcomjme3bulletjointsSixDofSpringJoint.java:77: error: cannot find symbol

[javac] setDamping(objectId, index, damping);

[javac] ^

[javac] symbol: variable objectId

[javac] location: class SixDofSpringJoint

[javac] C:workspacejme3srcbulletcomjme3bulletjointsSixDofSpringJoint.java:82: error: cannot find symbol

[javac] setEquilibriumPoint(objectId);

[javac] ^

[javac] symbol: variable objectId

[javac] location: class SixDofSpringJoint

[javac] C:workspacejme3srcbulletcomjme3bulletjointsSixDofSpringJoint.java:86: error: cannot find symbol

[javac] setEquilibriumPoint(objectId, index);

[javac] ^

[javac] symbol: variable objectId

[javac] location: class SixDofSpringJoint

[javac] C:workspacejme3srcbulletcomjme3bulletjointsSixDofSpringJoint.java:89: error: method does not override or implement a method from a supertype

[javac] @Override

[javac] ^

[javac] Note: Some input files use or override a deprecated API.

[javac] Note: Recompile with -Xlint:deprecation for details.

[javac] Note: Some input files use unchecked or unsafe operations.

[javac] Note: Recompile with -Xlint:unchecked for details.

[javac] 40 errors

[javac] 7 warnings



BUILD FAILED

C:workspacejme3nbprojectbuild-impl.xml:665: The following error occurred while executing this line:

C:workspacejme3nbprojectbuild-impl.xml:346: Compile failed; see the compiler error output for details.



Total time: 3 seconds

[/patch]



Also we have some russian javadoc somewhere in the source ^^



btw is there some way to post in the forum something in a way taht slashes are not killed? treid code, java and patch as tags :frowning:

How do you run the ant file? It works with normal ant from 1.7 on. Hudson also uses ANT (not NetBeans in any way) to build the project. I checked it out like 10 times the last days on windows, linux and mac. Actually the default target was calling the tests target which is broken (fixed in svn), but “ant jar” always worked on all platforms.

Hm ok, is not anymore present after updateing again from svn.



The russian TODOs are still present :slight_smile: ^^

and around 38000 erros when eclipse fails to setup the project … How about at least a null project file, that simply tells eclipse that it shall not try to compile anything itself, so a fresh checkout would not give several thousand error of errors after checkout.



.classpath

Code:
<?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.7"/> <classpathentry kind="output" path="bin"/> </classpath>

.project
Code:
<?xml version="1.0" encoding="UTF-8"?> <projectDescription> <name>jme3</name> <comment></comment> <projects> </projects> <buildSpec> <buildCommand> <name>org.eclipse.jdt.core.javabuilder</name> <arguments> </arguments> </buildCommand> </buildSpec> <natures> <nature>org.eclipse.jdt.core.javanature</nature> </natures> </projectDescription>