- This topic has 183 replies, 92 voices, and was last updated 16 years, 5 months ago by
.
-
Posts
-
Not sure, but I think WEBROOT/WEB-INF/classes is the correct place. This is simply the exploded view of a standard war file. If you don’t put the classes here, then you will need some special “ant-like’ commands to copy all of the stuff to that location, or to the lib location if you generate jars. If you only put jars in the lib file, then “hot deployment” will does not work correct (which is a very bad thing for development).
Of course – I could be totally wrong, it’s happened before
Ed you are pretty much right. While the changed JARs will be copied out to the app server, chances are (on windows) you will get a read-lock collision anyway, and even on Linux, I don’t know that the classloader will honor the new JAR without a restart anyway; so it’s not going to give you the instant updates you are going to want during development.
Ed, Riyad,
I understand that this is the correct place to compile from a J2EE project perspective.
The problem is if I make my Maven /src/main/webapp folder the MyEclipse Webroot folder, then MyEclipse will compile my classes into /src/main/webapp/WEB-INF/classes
This is putting .class files in the /src/ folder. This is completely wrong by Maven standards.
David
David & Others,
This is one of the reasons that Maven support hasn’t been a drop-in for us. It *requires* us to go back to the drawing board with a lot of the project structure and functionality in order to support the layout/deployment of a Maven project.Telling management we are going to re-implement the project structure (the basis for *everything*) and keep our fingers crossed that we don’t break 50% of our user’s installs after they update in the process is like asking someone to roshambo over something. It’s a very hard sell and it’s been under research by two of our developers for quite a while now of exactly what will need to change, how it will be changed, how that effects current users, how we can migrate users, what will happen if XYZ breaks and so on.
I hope that shines a little more light on why it wasn’t done already. We like the technology and want to utilize it for quite a bit more than just projects, so we are thinking very seriously on this subject.
edross: Thanks for your elaborate explanation.
How do you make sure a change in the DAO project is picked up? When you create the projects with maven, then Eclipse will have no idea the DAO project and your web project are related (it will load the DAO jar from the M2_REPO instead of including the project).
rkalla: Why do you think the ME project structure has to change?
As I see it, you just have to add three functions:
1. Allow to specify a set of files which shouldn’t be deployed (like unit tests, resources and servlet.jar).
2. It should be possible to specify a different folder for class files (so maven users don’t have to set output dir to src/main/web/WEB-INF/classes)
3. ME should support filters while copying resources
I see no need to have to change the project structure for everyone else. These three changes should be simple to do, wouldn’t break existing projects and could be useful for others, as well.
1. Allow to specify a set of files which shouldn’t be deployed (like unit tests, resources and servlet.jar).
This is being worked on now.
2. It should be possible to specify a different folder for class files (so maven users don’t have to set output dir to src/main/web/WEB-INF/classes)
This is not supported, which is why the project model would need to change to allow logical -> physical mappings.
3. ME should support filters while copying resources
I don’t quite understand this… you mean the same as #1, what is the use case here?
These three changes should be simple to do, wouldn’t break existing projects and could be useful for others, as well.
Please don’t assume so, if they were, they would have been done for the 4.0 release which is when we started looking at Maven support seriously. Our plan for Maven isn’t simply to drop it in, hi-five eachother and call it a day. We want to do more with it.
I’d also point out there has never been a feature that has *ever* been simple… even adding some external plugin that has a very simple task… it’s always after a major release that we’ll find out that when you combine that plugin with some other setup configuration, it kills your children. So now management is extremely methodical when adding new features and functionalities.
@support-rkalla wrote:
2. It should be possible to specify a different folder for class files (so maven users don’t have to set output dir to src/main/web/WEB-INF/classes)
This is not supported, which is why the project model would need to change to allow logical -> physical mappings.
Well, it should be simple to allow to configure this single setting? It needs an option in the config file, refactoring of the code (add a “getOutputFolder()” method) and that’s it.
3. ME should support filters while copying resources
I don’t quite understand this… you mean the same as #1, what is the use case here?
Maven can filter (= replace variables) in files while it copies them to the classes folder. For example, you have to define the project version in the POM and then you can tell Maven in which files you want it to replace ${project.version} with it. This is also possible for additional properties.
These three changes should be simple to do, wouldn’t break existing projects and could be useful for others, as well.
Please don’t assume so, if they were, they would have been done for the 4.0 release which is when we started looking at Maven support seriously. Our plan for Maven isn’t simply to drop it in, hi-five eachother and call it a day. We want to do more with it.
I’d also point out there has never been a feature that has *ever* been simple… even adding some external plugin that has a very simple task… it’s always after a major release that we’ll find out that when you combine that plugin with some other setup configuration, it kills your children. So now management is extremely methodical when adding new features and functionalities.
I understand. OTOH, as it is right now, inexperienced users can’t use Maven and ME at all! Therefore, I’d like a quick’n’dirty solution so we have something which at least works for the simple cases. It would generate more bug reports but I usually feel a solution which covers the standard case is better than no solution at all. Feedback from users will then give you the right ideas where you should improve the solution.
So my comment wasn’t that it’s simple for you to do but I’d like to ask you to aim for the most simple solution which you can release in March (even if it has to cut corners. Fix those in the November release :))
You might also want to have a look at the Eclipse Extension for Maven (ie. an Eclipse plugin which supports Maven projects). That might get a bit closer to where we want to be.
One more vote for maven integration.
And some more thoughts: I understand, that the project structure is the very heart of your tool and cannot be easily changed. But I think this is a major drawback: to introduce a tool in existing projects depends on how the tool can handle an existing project structure. To handle it vice-versa and change the project structure would mean to face the same issues as you. I suppose the decision will be clear and will be against the tool.
Mavenizing a project is possible most of the time, MyEclipsing not necessarily 🙁
Last I checked Maven does allow for custom project structures. It’s a hastle to configure but you can do it. so the work would be to be able to generate the pom based on the current structure of existing projects.
We will also have to deal with an external repo of jar files instead of embedding them into the project, which is just a pain point of moving to maven.
or am I misunderstanding something? are we not talking about how we structure our source, etc… directories.
my problem has always been with depending on an external build tool and having it integrate well, which is what I want from a maven2 plugin.
so +30 (Development team) We are planning to go to maven2 for all of our internal projects this year.
Can we expect it in 5.5? Or in the next release after that? You just GOT to have a roadmap for Maven!
@manudewan wrote:
Can we expect it in 5.5? Or in the next release after that? You just GOT to have a roadmap for Maven!
True. In my company we recently switched to using Maven as our build system.
Since ME isn’t able to do debug + hot-code-replace any more (when using the Maven project structure), we really don’t use much of ME anymore. We just use ME as a ‘glorified text editor’ for .java and .jsp files. SNAP would actually fit in quite nicely at our place, but so would any other combination of good editors for the file types we edit.As long as we don’t have a full-fledged IDE that supports the Maven way of doing projects, we simply don’t need an IDE anymore. We are currently investigating a switch to IDEA if we find that IDEA supports our/Maven’s project structure better than ME.
I agree with all the folks stating that maven support is the most needed feature. A lot of dev teams are switching to maven and as far as I know they are dropping ME because of its lack of maven support. Our team is doing the same, keeping the current subscriptions but thinking not to renew it because of that; this is bad because of the great features of ME (and support!!) and because a lot of time has been spent in training developers to use ME.
I think that ME team should at least be clear about the dates or roadmap for maven integration in ME; it would allow companies to know what to expect and decide whether to keep using ME or drop it. Without knowledge of the future decisions of ME team, the only option is drop it, unfortunately.
Francesco
