- This topic has 2 replies, 3 voices, and was last updated 20 years ago by
.
-
Posts
-
Hi,
I am moving from InteliJ to MyEclipse and trying to figure out if MyEclipse could keep my existing project folder structure format.
We are not moving everyone from IntelliJ to MyEclipse immediately, so by keeping the folder structure similar 2 different developers running different IDE should be able to support the application.
Does anyone know whether I could create a web folder structure as shown below?
On a slightly different note, supporting multiple dir structures would be helpful. (IIRC the appfuse dir structure is somewhat similar to msariman’s structure) The common element in all of these “different” configs is the presence of one or more “staging” dirs. Would this be feasable?
It’s a little difficult to comment on whether or not your current structure can be used because we don’t know what your build / deployment process looks like for this structure.
Overall, I recall using complex project setups in the past because we were writing thousand line Ant scripts to build and deploy everything ourselves and it made everything much simpler. When we set out to build MyEclipse, we wanted to make everything more efficient by removing the necessity to write any Ant files, restart the server very often, while keeping our deployed code and our developed code in sync automatically. However, in order to do this MyEclipse needs to know where all your artifacts are located. So, our J2EE projects are set up like their exploded counterparts by default. However, we do provide quite a bit of deployment flexibility with the advanced deployment options, as documented here:
http://myeclipseide.com/enterpriseworkbench/help/topic/com.genuitec.myeclipse.doc/html/quickstarts/webprojects/index.html#dependent_projects
In addition, we continue to improve the flexibility with each release.All that said, if you’re working with other developers and can’t modify the structure, it might be best to continue to use whatever deployment everyone has agreed on to remove the risk of differences between the environment. While that won’t allow you to use our deployer, you can still use all the editors and debugging capabilities. That’s not to say you can’t make something work with our deployer, only that we don’t have nearly enough information to be of much help there. I’d suggest reading the entire quickstart, above, to see how our deployer works and see if you can spot a method for grafting your current approach and ours together at some point.
