For help with installation, bugs reports or feature requests, please head over to our new forums.
Genuitec Community on GitHub
- This topic has 7 replies, 3 voices, and was last updated 20 years, 8 months ago by
.
-
Posts
-
Waited almost too long to submit this. Took 2 half-nights in february to find out what’s wrong with this arrangement…
Suppose you have VERY long classpath’s, I mean really long and the obscure JSP compiler chokes because of that all the time. Then you might try to minimize the path lengths. I tried this in Windows by mapping a drive letter, deep in the directory tree.
Example:
net use x: \\compname\e$\deep\deep\...\deeper\dir\testprjThen import the project again, it’s now directly under drive x: !
But when trying to deploy (Tomcat 5, exploded), the following error occurs permanently:
Deployment is out of date due to changes in the underlying project contents. You'll need to manually 'Redeploy' the project to update the deployed archive.The solution is to map the drive one directory higher, “…\deeper\dir”, but in my eyes it’s a bug.
E 3.0.2, ME 3.8.4 + QF2, JRE & JDK 1.4.2_latest & 1.5.0_latest, WinXP+SP2
PS
Some might argue that E 3.0.2 did not exist in february: for this posting I reproduced the issue with the mentioned E & ME versions.Wow! Thanks for letting us know what’s up. The path length problem is a Windows issue – it’s limited to 256 characters and there’s nothing we can do about it, so your workaround sounds like a great way to go.
The solution is to map the drive one directory higher, “…\deeper\dir”, but in my eyes it’s a bug.
Actually, that’s likely because the project is always one directory level below the workspace, so mapping all the way down to the project is likely confusing the deployer because it’s expecting the project to be one deeper.
With all due respect:
- * afaik, the path and env variables size limit is larger, depending on the Windows flavour.
- * I understand that for the ‘javac’ call not the PATH size is the problem, but the CLASSPATH size. Have you already considered using argument files for ‘javac’: http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/javac.html#commandlineargfile ? [PS yes, it really works, even with CLASSPATH of 14k+ length and the key library at the end 😉 ]
Woops, yes they liked it and I filed it soon after as an enhancement for us to implement. Not target release yet though.
That’s good news and bad news 🙁 I’m asking because the knife has hit the bone, so to say: none of my current projects is able to be validated by MyEclipse… And I’m already using project paths like e:\entA, e:\entB, etc.
Being at this already, I’d like to ask if the necessity of having javac in the PATH for JSP validation will persist in the future. I can’t understand why this has to be like this!? Can’t the javac be taken from the projects JDK setting? I mean the path to the JDK is in the project preferences, why not use that? We’re maintaining projects which still require JDK 1.2.2 (WebSphere 3.5) and developing the replacements based on JDK 1.5 AND 1.4 (some projects use libs which do not like 1.5). I only hope you understand the difficulties and side effects induced by the javac-in-PATH requirement.
I’m asking because the knife has hit the bone, so to say: none of my current projects is able to be validated by MyEclipse… And I’m already using project paths like e:\entA, e:\entB, etc.
I am upset to hear that you are not able to have validation work for you. I just discussed this with the dev that would likely implement this and when I mentioned getting this into 4.0 he had heart palpatations, suffice it to say they have too much to do so this won’t be in 4.0.
Can’t the javac be taken from the projects JDK setting? I mean the path to the JDK is in the project preferences, why not use that?
We would if this were the case, but what these settings you refer to infact to the built in JDT compiler which is a IBM-created Java compiler, it is not the javac executable. We used to use this compiler and will likely move back to using it again in the future but switching back to it is a rediculous amount of work that we are postponing for 5.0+
If you are referring to the “Installed JREs” this is another problem, they are just that, JREs, not JDKs so we can’t key off of these values from Eclipse either. So yes javac in the path is an ugly wart, no doubt about it, but that is what is needed right now.
We’re maintaining projects which still require JDK 1.2.2 (WebSphere 3.5) and developing the replacements based on JDK 1.5 AND 1.4 (some projects use libs which do not like 1.5). I only hope you understand the difficulties and side effects induced by the javac-in-PATH requirement.
There is nothing to understand, you are really caught between a rock and a hard place, I feel for you and I did what I could to push this into 4 but it just didn’t make the cut. I’m sorry, we want to help when we can but we are just too maxed out right now (Everyone has a todo list about a mile long and about 1/2 of it are “last minute changes” like this).
