[Robert Varga]

Our current web project outline is the following:

WebProject
– classes – the output of the src folder
– src (source folder)
– dd (folder) – containing the would-be content of the WEB-INF directory
– lib (folder) – containing the would-be content of the WEB-INF\lib directory
– res (folder) – containing files to be copied into WEB-INF\classes (property files)
– web (folder) – the web document root (does not contain WEB-INF or META-INF)
build.xml – the build file which among other things is capable to build a war from this setup

It would be beneficial if we would be able to use this as a project structure in MyEclipse. Will this be possible with linked folders or otherwise with MyEclipse with either Eclipse 2.1.2 or with Eclipse 3.0?

Regards,

Robert Varga

[Scott Anderson]

Robert,

I believe you can do this now that we have linked folders working in 2.7 GA. You’ll just need to create links from within your web folder to the outer res, lib, and dd, folders so that the web folder looks like an exploded war with the links you added. Does that make sense?

[Robert Varga]

@scott wrote:

Robert,

I believe you can do this now that we have linked folders working in 2.7 GA. You’ll just need to create links from within your web folder to the outer res, lib, and dd, folders so that the web folder looks like an exploded war with the links you added. Does that make sense?

Well, this is not exactly the perfect thing. The problem with this, is that you are not able to make a project-relative linked folder, and therefore, whenever you move the project around, you manually have to update the folder link.

Therefore if a project-relative linked folder is not possible, then the only other way to intuitively manage this problem is to introduce additional folder designation (similar to the web project root) for library folder (which would contain stuff to be copied to WEB-INF\lib) and for WEB-INF folder and for META-INF folder. Properties folder (res) can be handled as an additional source folder.

Similar things would be very useful for the EJB project (META-INF folder and library folder) and the J2EE Application Project (META-INF folder and library folder and APP-INF folder).

Thinking over, library folder designation may not be mandatory, if it is possible for all parts of MyEclipse to find libraries residing in any directory and copying the appropriate ones to the WEB-INF/lib or APP-INF/lib upon build or war generation.

Be aware, that these folder designation should be honored entirely, therefore when debugging a separate WEB-INF folder needs to be set-up and all appropriate stuff should be copied into this folder, and the WEB-INF designated folder should not be used to holding the WEB-INF\classes and WEB-INF\lib stuff, since that would pollute that projects. Of course it is also useful if this separate WEB-INF folder is hidden, so that it does not confuse the developer.

This way there would be no need for absolute paths specified in the classpath file. I know, absolute paths do not look like such a big problem at first. But just imagine a situation when more than one people are working on this project, and they don’t have a uniform setup and therefore have projects checked out into different directories. They would not be able to work on the same project with Eclipse, since they would have to have private .project and .classpath files!

[Riyad Kalla]

Robert,
I’m curious what IDE currently provides you with this flexibility (so we can see a proof of concept in action to get a better idea of what you are asking).

[Robert Varga]

@support-rkalla wrote:

Robert,
I’m curious what IDE currently provides you with this flexibility (so we can see a proof of concept in action to get a better idea of what you are asking).

Unfortunately I don’t know other IDE too well, since I haven’t used anything other than Eclipse in the last two year, so I cannot point out an example to you. This setup is what we use in our project, and it is compiled with ant, we edit the Action files with Eclipse, but we cannot fit the project comfortably in Eclipse because of the above mentioned reasons:
– linked folders are not teamwork compatible because of linked folders are using absolute paths that may not be the same on every team member’s machine
– war build process with linked folders pollutes the WEB-INF physical directory with files copied from other folders if the war-ing process is happening in-place.

I try to explain what I suggested in more detail:

We have a Web project. It has the following folders:

0. classes This is the output folder of the build process of the src and the res folders. All files in this are copied into the WEB-INF\classes directory of the war file during the build process after the normal java compilation step finished.

1. src. This is the normal source folder. Files are compiled into the classes folder.

2. res. This is the folder containing property files and other resource files. This is a source folder as well. All stuff in this directory is copied to the classes folder, as normal resource files usually are.

3. dd. This folder could be designated as a “web-descriptor folder”. Contains all descriptor like files, so web.xml, weblogic.xml, struts configs, tld files, etc.

Everything in this folder needs to be copied to the WEB-INF directory of the war file during the build process.

This should not be the physical storage place of the WEB-INF folder in the staging area, because this way files will show up in this folder during the build process and they possibly won’t get deleted afterwards, and anyway this is a source-purpose folder (not a build-result folder).

4. lib. This is a normal folder containing library jar files. Everything in this needs to be copied to the WEB-INF\lib directory of the war file during the build process.

5. web. This is the web root folder. This folder does not contain a WEB-INF directory in our setup (unless it does contain a WEB-INF/jsp, but even then, it does not contain other folders usually in WEB-INF). This folder contains the web documents. During the build process stuff in this directory is copied to the root of the war file.

6. Another source folder could be added to the project which would be mapped to the directory the servlet container generates sources from jsp files.
Even better would be if this was a folder physically under the project root, and make deployment behave the way, that it sets Tomcat (or other servlet containers) up to generate jsp-s into this folder so that it can be outside of the deployed WEB-INF directory. I don’t know it off my head if this is possible. This would allow not having any extra folders dangling in the project tree.

The staging area during build is a directory outside of these folders.

This structure clearly separates files having a different purpose (java source, resources, libraries, descriptors, web content) into different folders and you don’t have folders dangling in the project because of technical reasons (e.g. parents of source folders that are not the immediate children of the project root directory).

Now, what would be useful is to be able to designate directory dd as a folder which contains stuff going into WEB-INF, and this would be honored
– by the war-ing process,
– the editors
– the debugger
– anything else
so that they would not restrict the specific place of any file in the project, but they would be able to find a source file according to their places in the war file. An example:

Now a tld file is supposed to be in the <webroot folder>\WEB-INF directory. Instead of this it would be searched for in any folder in the project that is designated as a “web-descriptor folder”, and there would not be an error message if I referred onto a tld file in a jsp which resides in a folder designated as a “web-descriptor folder” instead of residing in “WEB-INF”. It could even be extended to use dd files which are provided by different projects (depended upon by the web project).

Also during the build process and after it is done, I would not see class files and resources in a classes directory in WEB-INF which is the place of the descriptors and struts-config.

I hope it is clearer now, but please do ask if it is not clear.

Actually this separation of data depending on its purpose is also a big step into the generalization of the web project tooling since it provides a way on how to allow customization of the deployment structure instead of having hardcoded deployment structures (in this case the structure of a war file). I posted a (even more general-purpose) suggestion on this a couple of months ago in the webtools newsgroup on the eclipse news server that would allow the managing of arbitrary web projects regardless of the used technology (not J2EE only), but that may not be available now. If you want, I can try to dig it up or reproduce it.

Regards,

Robert

[Riyad Kalla]

Robert,
You’re explination was very clear, thank you for taking the time to enter it in for us. I would say that your project layout is very versatile and purposeful, but unfortunately definately not something we currently support.

However, it seems to me that the solution to your problem is the ability to tag pretty much any directory (or set of directories) as TYPES of resources that MyEclipse would then use appropriately… for example (like you said) tagging a directory as a ‘Descriptors’ directory, would allow ME to resolve all XML and TLD references by looking into those folder(s)… same goes for source, binaries, libraries, webroot, etc…

Let me pass this buy Scott/Michael and see what they think. I see this feature either being really easy change or a major change, depending on the direction our project management infrastructure is going.

[support-michael]

Robert,

Thanks for the feedback. We have been discussing various flexibility options for a new project structure. The range of options spans from models where any resource can be assigned a role (or worse roles) to simply splitting out the web-root folder into web-contents src folders and a single user definable web-inf folder. We are looking to strike a balance in the flexibility/usability equation. That is, as flexibility increases so does complexity and consequently usability decreases. We will definitely take your input into consideration.

[Robert Varga]

@support-michael wrote:

Robert,

Thanks for the feedback. We have been discussing various flexibility options for a new project structure. The range of options spans from models where any resource can be assigned a role (or worse roles) to simply splitting out the web-root folder into web-contents src folders and a single user definable web-inf folder. We are looking to strike a balance in the flexibility/usability equation. That is, as flexibility increases so does complexity and consequently usability decreases. We will definitely take your input into consideration.

Actually, I think it would be worth to put some effort into some general solution, because it would then allow to build upon that as a foundation when implementing the web tools project, and trying to implement web project maintenance and deployment for non-J2EE web projects eg. php which does not contain a web-inf folder.

What I have suggested on the webtools newsgroup in short was to provide a tree showing the structure of the staging area of the deployment (staging tree), and allow the user to set up mapping to those directory. The tree mapping can also be composed of similar subtree mappings. You could also create a default mapping newly created projects upon creation which the user may later override. It would probably be easy to understand by example:

Let’s suppose we are speaking about a J2EE web project. It needs the assembling of the following directory structure (staging tree):

/ (war root)
 \---- WEB-INF
 |        \--- classes
 |        \--- lib
 \---- META-INF
 \---- web content directories

Now taking my previous project structure:

you have the following mappings:

Path in project       Path in staging tree
web                -> / (WAR-root)
dd                 -> /WEB-INF
classes            -> /WEB-INF/classes
lib                -> /WEB-INF/lib
meta               -> /META-INF

You could specify more than one source to go the same destination in the staging area, but files can not conflict (you are not allowed to have more than one files to be copied to the same file in the staging area).

You could also use existing deployment mappings to be copied to a place in an other deployment mapping, eg.

Staging tree

/ (Enterprise application exploded directory structure a' la Weblogic 8.1)
\--- EJB Module 1
|      \--- META-INF
\--- EJB Module 2
|      \--- META-INF
\--- Web app 1
|      \--- WEB-INF
|      |       \--- lib
|      |       \--- classes
|      \--- META-INF
\--- APP-INF
|      \--- lib
\--- META-INF

Now here you could tell, to have the following mapping for the J2EE Application project:

Path in project       Path in staging area
{EJB Project A}    -> /EJB Module 1
{EJB Project B}    -> /EJB Module 2
{Web Project C}    -> /Web app 1
lib                -> /APP-INF/lib
meta               -> /META-INF

The {project name} means the staging structure of an other project. You could also specify designated other staging trees.

You can also specify to use only subtrees of an other staging tree with a notation like {project name}/path on the left.

You can also put entries in the mapping file for signifying the invocation of a specific routine (eg. the generation of a descriptor file, or manifest files, or anything) in to the mapping table.

This solution is totally technology neutral, so it could be easily used for assembling an arbitrary staging structure of PHP files, or CGI scripts or anything, or even anything mixed-up, not only J2EE projects.

Afterwards the actual deployment process is then server-specific in the sense that there should be deployment methods which can be used to deploy the staging tree.

Or to make it one point further: you can likewise designate different parts of a staging tree to be deployed with different methods even to different destinations. Example: the whole staging tree goes with normal J2EE deployment to Tomcat, except for a subtree of the web document tree, which contains only static files which go to a separate Apache web server with FTP. A similar mapping table could be used to specify different deployment destinations for parts of the staging tree.

Another thing, you could specify how appropriate areas or the whole staging tree are deployed (in exploded format or in an archive).

Also for either staging or deployment mapping, you could also use specific filters to refer on only this or that kind of file (based on filename regexps, for example) (eg. different mapping for .html and .jsp files in the same directory).

I hope this long braindump influences you a bit when you come up with something hopefully really efficient (like this 🙂 ).

Regards,

Robert Varga

[Robert Varga]

@scott wrote:

Robert,

I believe you can do this now that we have linked folders working in 2.7 GA. You’ll just need to create links from within your web folder to the outer res, lib, and dd, folders so that the web folder looks like an exploded war with the links you added. Does that make sense?

Actually you cannot do that (at least not in 2.1.2, but I think you also cannot do that in 3.0).

Only the immediate child folders of the project can be links, so web\WEB-INF cannot be a linking folder. It makes sense, since folder definitions inside a project is stored in the .classpath file, but you don’t store the whole directory structure in the .classpath file.

And if you make it the other way round, and make dd to be a link on the web\WEB-INF, then you will see the WEB-INF\classes folder in dd, which is not altogether a very clean solution, not to mention being confusing.

And still the problem of links being not teamwork compatible because of different paths on different machines vs. absolute link paths.

[_bjoern]

I have a similar problem like discussed in this thread.

What is the final answer?

I need a more flexible Web Project definition.
My project is not compatible with the standard web app structure.
I want to specify more then one source- and web-root-folder.
(Like in standard Java Projects where I even can define where the compiled classes go for each folder)

The myEclipse deployment process should create the standard web app resp. folder structure.

What happened about the deployment hook idea?

[Riyad Kalla]

bjoern,
It sounds to me like you have combined multiple web projects (multiple web roots) as well as the dependent core Java Project all into a single project; even with our flexible project structure this setup would not be supported as a single project. I would suggest breaking all your Web projects out into single web projects, and then linking them to the single Java project by way of the Java Build Path and “Referenced Projects” project property. Then adjust the MyEclipse deployment settings on how to handle the related project and viola, everything is right with the world again.

[_bjoern]

Thanx for your quick answer.

We have not combined multiple web projects.
I can not change our folder structure.
(Because of version control system)

One problem is that we use different folders for our HTML and JSP sources.
The sources are NOT organized like a web-app.
(Which is not a problem for an ant script)

So, I do not want to define several web-roots. I want to define different
source folders for HTML and JSPs.
(like several java source folders compile into one bin folder)

I want to deploy several HTML and JSP folders in one webapp.
At the moment they are merged by an ant script.

Think about a szenario where you have some common JSPs
shared by several projects. The JSPs can not be placed under
a single application web root. I do not want to move the files
arround because of version control system.

[Riyad Kalla]

Hmm, yes I see your point.

Out of curiosity, do you use an IDE currently that supports this structure? If so, how do you have it setup so that it works the way you need it to?

[_bjoern]

Currently we use ant tasks but we want support of JSP debugging an so on.

[Riyad Kalla]

but we want support of JSP debugging an so on.

Understandable, but what I was asking was if you had or were currently using an IDE that supported JSP coding/debugging/autocomplete/etc. right now with your current project structure? I’m not aware of an IDE that would support it, that is why I’m asking. Obviously the point I’m driving at is that if no other IDE supports this setup, this will most likely signal to your team that if you want some nicer development tools you may need to reorgnize bits of the project.

I’d encourage you to try IntelliJ to see if it supported your configuration, next to us this is the other most flexible IDE I’ve seen with project structure. NetBeans, JBuilder and WSAD have fairly strict requirements on project structure and most all of them do not support any notion of packaging & deployment of projects.

In the end if reorganization simply isn’t possible then there isn’t too much we can do. The most problomatic thing being that the development version of your project doesn’t look anything like the deployment version; its hard (impossible?) for ME to do proper autocomplete, resource resolution and packaging when this is the case (same goes for other IDEs, although I don’t know the specifics so I can’t really comment).

[Author]

Posts