- This topic has 32 replies, 5 voices, and was last updated 18 years, 10 months ago by Brian Janes.
-
AuthorPosts
-
Brian JanesMemberHi,
I’m trying to use MyEclipse for the first time and I have questions about how to create a project that will work with my existing environment. I’ve been using the ObjectWeb Lomboz editor plug-in for Eclipse for about 2 years and have always wanted more capability. This plug-in does only simple highlighting and sytax help for JSP so it doesn’t care so much about the directory structure. MyEclipse seems to have a pre-conceived idea of how the structure should look. Here is my environment, please bear with me as I am by no means an expert in web development (I’m a EE who does this for my department in my spare time):
>>> I’m using Apache HTTPD with Tomcat.
>>> I have 3 stage directories (dev, qa, prod) on a NAS server on the network. Each directory is the document root for the web server. I edit my files directly in the ‘dev’ location and sync to ‘qa’ and ‘prod’ when I’m ready to publish them. I have 3 web servers running that point to each storage location respectively (etiwebdev, etiwebqa, and etiweb). I edit the files in ‘dev’ and view with the ‘etiwebdev’ server to make sure things are good, then I sync.
>>> There is only one actual web application (one context) that contains many directories that represent the different groups in my department. There is also a ‘webapps’ directory that contains cross-department tools that interact with our database (Oracle). I did it this way because I wanted to share a global menu with all groups in my department, but couldn’t get cross-context to work. So I’m stuck with it now.
>>> There is a top-level include directory that each group uses to get the department header, which includes a global menu that each group tailors with variables in a configuration file.
>>> There is a WEB-INF that contains a ‘lib’ directory for jars, a ‘tld’ directory for tag libraries, a ‘classes’ directory for custom classes, and a ‘src’ directory for the source for those classes.
I at first tried to create a new project in MyEclipse and import my files in. I would then export the files to my ‘dev’ directory. I felt this was much safer than creating the project in my exisiting space. Here are some things I’ve noticed so far that have me puzzled:
>>> MyEclipse likes to have a ‘src’ directory for all JSPs to go into. In my environment, I have them spread out across multiple directories.
>>> It also likes to have a ‘classes’ directory that is hidden from view in the package explorer. All JSPs are compiled into this location for some reason. I already have a ‘classes’ directory in my existing environment and this is creating a conflict.
Does anyone have any recommendations on what to do? Is my existing structure way off base? Would MyEclipse totally trash my existing structure if I tried to create the project there? Is there something with ‘deployment’ that I can take advantage of here? Sorry for so many questions, especially ones that are so basic.
Just for reference, here is an example tree of my structure:
WEB-INF
..classes
..lib
..src
..tld
css
images
include
..header.jsp
..footer.jsp
group1
..index.jsp
..config.jsp
..page1.jsp
group2
..index.jsp
..config.jsp
..page1.jsp
webapps
..webapp1.jsp
..webapp2.jspThanks in advance for any help you can give me to get started using MyEclipse.
Brian
Riyad KallaMember>>> MyEclipse likes to have a ‘src’ directory for all JSPs to go into. In my environment, I have them spread out across multiple directories.
I don’t quiet follow what brought you to this, but I assure you it doesn’t. A preferred project layout looks something like this:
http://www.myeclipseide.com/FAQ+index-myfaq-yes-id_cat-30.html#111Notice how the Java source (/src) dir is outside of the scope of the WebRoot directory? This is intention, you shouldn’t be deploying your source code. In your case you mentioned you hide it under your WEB-INF dir, while this is technically acceptable I would consider it sloppy. So maybe consider pulling it to the top level of your project as shown in the link above, outside of your WebRoot entirely.
>>> It also likes to have a ‘classes’ directory that is hidden from view in the package explorer. All JSPs are compiled into this location for some reason. I already have a ‘classes’ directory in my existing environment and this is creating a conflict.
The /WEB-INF/classes dir is required by the web specification, this directory is where all non-JAR’ed compiled classes belong in your web application. Because of this, the classes dir is set as your default OUTPUT dir in Eclipse, additionally, your OUTPUT dir is never visible in eclipse from your Package view, not even in normal Java projects, that is why you can’t see it.
Would MyEclipse totally trash my existing structure if I tried to create the project there?
I would *never* suggest you wing something like this until you have it setup perfectly on your local machine. Make like 10 backups of everything if you do decide to try and create it in place.
Is there something with ‘deployment’ that I can take advantage of here?
I would suggest that you locally mount the remote webapps dir of your Tomcat install on dev, and then setup an Exploded deployment of your web project from MyEclipse to that location, you will get your changes hotsynced imediately with the running server (As long as you have it’s context configured to be reloadable).
WEB-INF
..classes
..lib
..src
..tld
css
images
include
..header.jsp
..footer.jsp
group1
..index.jsp
..config.jsp
..page1.jsp
group2
..index.jsp
..config.jsp
..page1.jsp
webapps
..webapp1.jsp
..webapp2.jspAll of this looks like a single Web Application until I get down to the /webapps dir… I don’t understand it’s purpose, each web application must have it’s own layout like the link I gave you above (WEB-INF dir, web.xml file, WEB-INF/classes dir, WEB-INF/lib dir, etc.). If you are trying to combine multiple web applications with the same WEB-INF contents then that won’t work in MyEclipse, you will need to break these out into separate web applications.
Remember, you can always make common Java classes that all apps share a plain Java Project, and then set it up as a dependency of all the projects, they will package and deploy the project automatically for you. We don’t yet have a way for you to share web artifacts in this way yet (common images, css files, etc.).
Bob McCuneMemberPersonally, I find the directory structure imposed by MyEclipse to be a major limitation of the product. The WAR file spec is a deployment constraint, not a development constraint. I’ve had the opportunity to work for a variety of organizations and the one thing they have in common is they all do things differently. Each has its own preferred project structure and a build process to accomodate it.
I think the usefulness of MyEclipse would be greatly enhanced if you could specify how your project’s directory structure maps into the deployment structure; much like you can do with ANT’s war task.
Riyad KallaMemberPersonally, I find the directory structure imposed by MyEclipse to be a major limitation of the product
We do too, it will be lifted soon enough. We wrote the requirement specification for the flexiproject support that is going into WTP (and some of it is already in) and have been waiting for the implementation to be complete before rolling it into MyEclipse. Rational has been doing an excellent job and this will become one of the big features in MyEclipse 5.0 as we have it planned out now. Of course this is subject to change if management decides so, but we ALL really want this in.
Each has its own preferred project structure and a build process to accomodate it.
We know Bob. Don’t feel like you need to convince us, we are on *your* side. We’ve just been trying to squeeze the last mile out of the current impl until the flexiproject implementation was done. There was no reason for us to duplicate the effort and implement our own version, but now that it is starting to roll out in the WTP builds things are looking good.
I think the usefulness of MyEclipse would be greatly enhanced if you could specify how your project’s directory structure maps into the deployment structure
Then we think ME 5 will rock your socks off (just be sure to put socks on before downloading it when we release it).
Scott AndersonParticipantI will also point out that MyEclipse 4.0 already implements the most flexible deployment model available in any commercial IDE, short of hand-crafting your own Ant scripts, of course. Which you can still do if you prefer. You won’t be able to use our automatic deployers, but you’ll still be able to use all the editors, validation, and debug capabilities in the product. So, if you’d rather layout your development artifacts in a more arbitrary format, you can certainly do that, as long as you don’t mind deploying it yourself at this point. Often this is the best solution with complex legacy development efforts.
Brian JanesMember@support-rkalla wrote:
This is intention, you shouldn’t be deploying your source code.
Well, if you’re talking about my JSP source, I’m not sure I understand that. Tomcat directly compiles and displays my jsp files as they are requested. Are you saying that I should setup each JSP as a servlet in the web.xml file instead? Or are you talking about custom class source only? This morning, I imported all of my source (JSP and Java) to the src object in the package explorer. I will just handle these differently when I export my files I suppose.
@support-rkalla wrote:
In your case you mentioned you hide it under your WEB-INF dir, while this is technically acceptable I would consider it sloppy.
The only source code that I am storing in the WEB-INF directory is the source for my custom classes. The only reason I’m storing it there is so that it will be preserved so all of my teammates have access to it. I can move it out if it’s not a recommended practice.
@support-rkalla wrote:
All of this looks like a single Web Application until I get down to the /webapps dir…
I know what you’re saying. My ‘webapps’ directory isn’t for true web applications. Like I said, I’m no pro and certainly wasn’t back when I started this whole project. I named it ‘webapps’ so that we would have a place to store web-based applications (in the functional sense as opposed to the true sense). Sounds like I chose an improper name in this case, that’s all.
Thanks for your input.
Riyad KallaMemberWell, if you’re talking about my JSP source, I’m not sure I understand that. Tomcat directly compiles and displays my jsp files as they are requested. Are you saying that I should setup each JSP as a servlet in the web.xml file instead? Or are you talking about custom class source only? This morning, I imported all of my source (JSP and Java) to the src object in the package explorer. I will just handle these differently when I export my files I suppose.
Source meaning Java source files. Your /src dir is ONLY intended for Java source files and property/resource files. Your JSPs need to live under your WebRoot dir. Don’t combine the two. Think of your JSP files as HTML files, it helps to separate them conceptually more.
The only source code that I am storing in the WEB-INF directory is the source for my custom classes. The only reason I’m storing it there is so that it will be preserved so all of my teammates have access to it. I can move it out if it’s not a recommended practice.
This is waht I was referring to. Move it out and setup a CVS repository so everyone has access to it.
Brian JanesMemberOK, everything is starting to makes sense now. I have now moved all of my JSP to the WebRoot directory. The only problem I’m having now is that my include directive is not being resolved. My structure is:
WebRoot
..eds
….index.jsp
….config.jsp
..include
….declarations.jsp
….header.jsp
….footer.jspMy ‘eds/index.jsp’ file includes ‘eds/config.jsp’ via “<%@ include file=”config.jsp” %>”. This works fine. However, my ‘eds/config.jsp’ file includes ‘include/declarations.jsp’ via “<%@ include file=”/include/declarations.jsp” %>”. This doesn’t work. It appears to be resolving only within the current directory and not resolving the path to root. Any ideas?
Riyad KallaMember“<%@ include file=”/include/declarations.jsp” %>”.
Always try and use relative paths when you can: ../include/declarations.jsp, because absolute path resolution can make for some weird results between the IDE and app server especially depending on context root you deploy too (root or not).
Brian JanesMemberRiyad,
OK, I’ve done a couple of things to try to correct this. The first one, although I don’t like it, is to convert my paths to relative instead of referring to the root. The second, I followed the recommendation in one of the FAQ items and named my include files as .jspf because they are truly segments. However, after doing both of these, it still doesn’t work. I noticed that the error hint still shows ‘File “/include/declarations.jsp” not found.’ So for some reason, it’s not recognizing the changes. I have closed and reopened the files and the changes are there. I don’t know if it’s relevant, but I’ve also noticed that when I press the ‘delete’ key, it says “The command for the key you pressed failed. Reason: The command for the key you pressed failed.”
Riyad KallaMemberBrian,
Close all the editors and close the project. Shut down MyEclipse.Edit the shortcut you use to start it, and add -clean at the beginning of it and fire it up, then reopen the project and do a Project > Clean… and cause the project to rebuild. If the errors are there, reeopen the files, are the changes there are have the files reverted? The bug you are seeing is a sneaky bastard of a bug we are trying to track down.
Brian JanesMemberThat worked, except my includes aren’t showing up in the preview window. My pages are setup like this, and work fine in Tomcat:
config.jspf (a collection of variable settings that dictate the contents of the menu) includes declarations.jspf (nothing but variable declarations)
index.jsp includes config.jsp, header.jspf (the opening <html> tag, <meta> tags, <body> tag, opens a table, and the menu code that is driven by the config file), and footer.jsp (closes table, body, and html)
All the preview window shows me is the contents of the index.jsp file and nothing that is displayed from the included menu. Is there any debugging I can do to figure out why the preview window isn’t showing everything?
Also, another issue has popped up. It is complaining about my web.xml file around the closing </web-app> tag, saying “The content of element type ‘web-app’ must match (blah, blah, blah…)” and spits out a bunch of acceptable parameters to <web-app>. It’s like it’s not recognizing the closing tag and is treating it like an opening tag. Any ideas? Here is my web.xml file for reference:
<?xml version=”1.0″ encoding=”ISO-8859-1″?>
<!DOCTYPE web-app
PUBLIC “-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN”
“http://java.sun.com/dtd/web-app_2_3.dtd”><web-app>
<display-name>Enterprise Tool Integration</display-name>
<description>
Welcome to Tomcat
</description><taglib>
<taglib-uri>/upload</taglib-uri>
<taglib-location>/WEB-INF/tld/upload.tld</taglib-location>
</taglib><taglib>
<taglib-uri>/lastmod</taglib-uri>
<taglib-location>/WEB-INF/tld/lastmod.tld</taglib-location>
</taglib><servlet>
<servlet-name>
LdapGlobalCache
</servlet-name>
<servlet-class>
net.simya.ldap.servlet.LdapGlobalCache
</servlet-class>
</servlet><servlet-mapping>
<servlet-name>
LdapGlobalCache
</servlet-name>
<url-pattern>
/LdapGlobalCache
</url-pattern>
</servlet-mapping><taglib>
<taglib-uri>/ldap</taglib-uri>
<taglib-location>/WEB-INF/tld/ldap.tld</taglib-location>
</taglib><security-constraint>
<web-resource-collection>
<web-resource-name>Protected Area</web-resource-name>
<url-pattern>/webapps/admin/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>CN=ET_etiwebappsadmin,OU=Groups,OU=Cedar,OU=Collins,DC=ccanet,DC=rockwellcollins,DC=com</role-name>
</auth-constraint>
</security-constraint><!– Define the Login Configuration for this Application –>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>ETI Web Administration</realm-name>
</login-config><security-constraint>
<web-resource-collection>
<web-resource-name>Protected Area</web-resource-name>
<url-pattern>/webapps/phone/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>CN=ET_ldap_userid_search,OU=Groups,OU=Cedar,OU=Collins,DC=ccanet,DC=rockwellcollins,DC=com</role-name>
</auth-constraint>
</security-constraint></web-app>
Riyad KallaMemberBrian,
The preview window is not sufficient enough to view what you are doing. It doesn’t do real time evaluations that are necessary to display JSPs and is meant as a handy tool for HTML designers. Our new preview window will be smarter and support Struts tags and JSF going forward (but dynamic includes will be an issue). Always use a browser to preview your pages for maximum accuracy.Secondly, your web.xml file needs some serious reordering. The complain the XML validator is giving you is correct. The DTD and Schema for the web spec require a specific ordering of the elements, when you invoke autocomplete in the file you can get a feel for what order that will be. The problem with your current web.xml file is that it is all out of whack.
You can see the order by reading the “blah blah” part of the error message to know what needs to come before what… I can’t believe this runs without error in Tomcat to be honest =/
Brian JanesMemberRiyad,
OK, I reordered my web.xml file. Thanks for the tip, I’ll pay attention to that in the future. As for the preview window, what is the ETA for the more dynamic functionality? M3? M4?
Also, I got sick of trying to run everything on my crappy Windows box so I installed everything on Linux and it’s performing much better. However, there is no longer a preview tab and no built-in web browser. Are these supposed to be supported on Linux?
Riyad KallaMemberBrian,
You should have a Web browser tool bar button up by the deployment button, it will popup the internet web browser for you.The new preview view should be in M3, and it won’t be supported on Linux. The old preview view is still in M2 and should be supported on linux. However using the Web browser view works around that quickly enough.
-
AuthorPosts