- This topic has 183 replies, 92 voices, and was last updated 16 years, 5 months ago by Riyad Kalla.
-
AuthorPosts
-
fermataintlMemberMy company is now using maven for building so I am not using all of the nice features I am accustomed to in myeclipse, like making changing in jsp’s and being able to see the change by simply reloading the browser page. Maven seems to have really caught on so please do your usual best to fully integrate with it.
Thanks!
Dean
msquaredMemberAnybody got a good solution to effectively using maven within eclipse (like debug on tomcat without constant reloading)?
OldSchoolMember+20 or so
We have a small core of programmers here who are quite enthusiastic about Maven. We are already deploying apps to production which are built by our cofig mgmt group using maven.
I’m voting for keeping mvn src’s separate from the build targets even though this would require a change in the underlying structure ME uses. WEB-INF gets built into the target directory from files collected from many other directories such as the local maven repository and the src/main/webapp/WEB-INF directory, etc.
Full integration into WTP including auto deploy on changes, etc would be great. ME is a great platform with great docs. I would like to get our developers to buy into it in major way if we can get some maven integration.
Matt BucknamParticipant+10 at my company who are fighting the IntelliJ crowd for supremacy.
I can get MyEclipse to work perfectly with Maven except for the classes folder issue. MyEclipse will ONLY synch from the classes folder off of the WEB-INF folder in WebRoot. I don’t really understand why it is difficult to allow the use of a different output folder since it is already part of the configuration in Eclipse anyway, but it OBVIOUSLY is difficult as Riyad and others keep saying so.
I have decided to simply accept the MyEclipse output folder being inside src/main/webapp so that hot-deploy works and be happy. I’m just kind of thinking out loud about my experiences so far below:
1. Maven Eclipse plugin is nice but how to modify dependencies between repository-based binary vs. inter-project as the need arises. For instance you add a project to the workspace that is a dependency of another one already in your workspace. You would like to change the dependency from external jar to Project. Not sure how to easily do that with the plugin since the Maven dependency is some sort of library that is not granularly editable that I can see. Using the mvn eclipse:eclipse plugin works well as you can simply drop an external jar dependency and add the project dependency from the build path configuration dialog and all is well. There are already links to a site showing how to add the MyEclipse natures to the .project file. It also has the ability to generate whole files so you can add a section to your POM which generates the .mymetadata file which is nice if you need that kind of control. And if you structure your projects with a parent pom and modules you can get mvn eclipse:eclipse to generate the inter-project dependencies instead of repository-based binary correctly too.
2. Senior Developers can work with Maven and MyEclipse as is I believe. Basically once the project is structured the Maven way, you can quickly configure it to work in MyEclipse. Junior developers I am finding are completely baffled by the intricacies of the process so I am trying to decide if we should create a company-standard configuration and save the .project, .classpath, and .mymetadata files in source control so they then come down magically into MyEclipse fully configured. You then simply need to run mvn package and then mvn clean and this is ONLY to get the dependencies downloaded into the local repository so that the Eclipse external jar dependencies can resolve. After that just periodically running mvn package and mvn clean will refresh the external libraries (If there are any snapshot versions, otherwise this never needs to be done). My opinion is that you use Maven to build and deploy from an SCM copy and you use MyEclipse to develop from another SCM copy but you don’t really need to do both in the same place. In other words, is it really important to be able to do MyEclipse stuff and Maven stuff on the same physical copy of the assets as stored in the SCM (Subversion I hope!).
I have other thoughts but I’ll leave it here for now. Gotta get back to work…
msquaredMemberI am now (somewhat) effectively using Maven and MyEclipse together on a J2EE app (an EAR with 1 Web module). M2Eclipse plugin is great- it exposes all POM dependencies onto the Eclipse project classpath (it appears as a user library which contains all the dependent JAR’s as needed by the POM).
I set MyEclipse’s webrootdir=/src/main/webapp and my .classpath looks like this
<classpath>
<classpathentry kind=”src” output=”src/main/webapp/WEB-INF/classes” path=”src/main/java”/>
<classpathentry kind=”src” output=”src/main/webapp/WEB-INF/classes” path=”src/main/resources”/>
<classpathentry kind=”src” output=”target/test-classes” path=”src/test/java”/>
<classpathentry kind=”src” output=”target/test-classes” path=”src/test/resources”/>
<classpathentry kind=”con” path=”org.eclipse.jdt.launching.JRE_CONTAINER”/>
<classpathentry kind=”con” path=”org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER”/>
<classpathentry kind=”output” path=”src/main/webapp/WEB-INF/classes”/>
</classpath>Notice that Eclipse-compiled classes go into src/main/webapp/WEB-INF/classes .. I know this is not the Maven way (Maven-built classes go into /target/classes) but so what? So far I can’t see much downside to allowing Eclipse classes to be in a different location from the Maven ones. The big upside is that now hot deploy works properly on all my appservers (tested on tomcat, jetty and websphere). I don’t really see the big argument from MyEclipse developers about how this totally changes the MyEclipse directory structure and breaks everything.
Of course Maven filtering does not work, but it’s not a showstopper: so I simply dont use that feature.
My biggest issue (and this borders on showstopper) is the MyEclipse deployment (also the DeploymentBuilder) copies EVERYTHING into WEB-INF/lib including every Maven dependency (recall that M2Eclipse plugin makes these appear in a user library). Now at first glance this seems to be ideal.. and generally it is great.. HOWEVER the problem comes with jars having scope=provided (or test) in the POM (such as servlet-api, jta, jdbc drivers, etc ) . DeploymentBuilder copies these into WEB-INF/lib where they are now loaded by the WebApp’s classloader (instead of the Container’s classloader) so it results in class cast exceptions.
One could argue that M2Eclipse should NOT add those JARS (scope=test or provided) to Eclipse classpath in the first place. But these are needed to compile or run JUnit tests and if you do TDD (test driven development) then it’s a terrible pain to manually add all those JARS onto the classpath of every Debug launch configuration or for building.
The ideal solution is for Genuitec to modify Deployment to have filtering abilities. This could be done quick-and-dirty: just add a new input field on the Library Deployment Policies tab allowing the user to enter a delimited list of jars which should NOT get deployed. Even better (but more work) would be to make Deployment aware of the POM dependent scope and automatically filter out scope=provided, scope=test, etc. Since parsing the POM (and computing transient dependencies) is difficult, I would suggest using the M2Eclipse plugin for doing this.
Here is a perfect case where OpenSource is far superior to commercial software – I would simply do this myself if the source code were available. Instead, I am stuck with options like play around with adding an AspectJ pointcut to com.genuitec.eclipse.ast.deploy.core.DeploymentUtil.copyFileToDirectory() (its not working yet!) or PlanB is I created new IncrementalProjectBuilder which runs AFTER the Genuitec DeploymentBuilder and which deletes the JARS that I want filtered. A hack but it works, except for the initial deployment.
Genuitec- will you please make the source of your Deployment available (under any license at all) so we Maven users can fix these problems? My other option is to add these Maven enhancements to the opensource WTP deployer (and that could tilt a few customers in the wrong direction).
msquaredMemberI have a good solution now for the Maven scope deployment problem. I have submitted a patch for the M2Eclipse plugin http://jira.codehaus.org/browse/MNGECLIPSE-107 which now adds a custom attribute indicating the Maven scope of each individual JAR. Fortunately, Eclipse JDT already supports this idea of custom attributes so it was rather easy.
Now on the MyEclipse side of things, a 10-line change (which has no effect when M2Eclipse is not used) must be made in the deployment phase to look for this new scope attribute and filter out certain JARS. Of course I cannot make this change to the closed-source DeploymentUtil in MyEclipse, but the change goes like this:
boolean deploy=true;
if (“org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER”.equals(iclasspathcontainer.getPath().toPortableString())) {
for (int a=0; a<iclasspathentry1.getExtraAttributes().length; a++) {
IClasspathAttribute cpa = iclasspathentry1.getExtraAttributes()[a];
if (“org.maven.ide.eclipse.scope”.equals(cpa.getName()) &&
((“provided”.equals(cpa.getValue()) || “test”.equals(cpa.getValue())))) {
deploy = false;
break;
}
}
}
if (! deploy)
continue; // dont deploy this JAR (maven scope=test or scope=provided
OldSchoolMemberNow that Eclipse 5.5 is released, what are our prospects of getting full Maven integration (or even partial) in the next release?
jganiMember@msquared wrote:
I have a good solution now for the Maven scope deployment problem. I have submitted a patch for the M2Eclipse plugin http://jira.codehaus.org/browse/MNGECLIPSE-107 which now adds a custom attribute indicating the Maven scope of each individual JAR.
Does your solution still require Eclipse build to output to src/main/webapp/WEB-INF/classes ? If this is the case, running
mvn package
on command line will pick up everything in that directory, including test-scoped resources and JARs, which means that the resulting package (eg the WAR file) will contain them.
But in general I like your solution.
Mike SmithsonMember+1 for me
msquaredMember@jgani wrote:
Does your solution still require Eclipse build to output to src/main/webapp/WEB-INF/classes ?
Yes, but I dont really view this as a bad thing. What evil do you see from this? I have not seen anything bad really.
@jgani wrote:
If this is the case, running
mvn package
on command line will pick up everything in that directory, including test-scoped resources and JARs, which means that the resulting package (eg the WAR file) will contain them.
First of all, there are never any JAR’s in src/main/webapp/WEB-INF/classes. If you meant to say src/main/webapp/WEB-INF/lib then there are not any JARs there either, since the M2Eclipse plugin avoids that need.
Secondly, from what I see happening, maven first copies the web resources (from src/main/webapp) and THEN it copies the classes (from /target/classes) so although you are correct to say that the Eclipse classes do indeed get copied by Maven, those classes are immediately replaced with the Maven-compiled classes
@jgani wrote:
But in general I like your solution.
Thanks, I am happy with it. Wish I could simply patch Genuitec’s code so others too could benefit.
nimmsMemberjgani wrote:
Does your solution still require Eclipse build to output to src/main/webapp/WEB-INF/classes ?Yes, but I dont really view this as a bad thing. What evil do you see from this? I have not seen anything bad really.
It’s a bad thing if developers include their resource directory on their eclipse build path as these get compiled into the WEB-INF directory, then maven comes along and includes them in the target directory. We had a problem with this when we first started using maven, and our test resource files kept turning up in our builds.
By the way, I’ll add another +6 for maven integration to be included as soon as possible. It’s a real headache for us and means we don’t use much of the myeclipse functionality.
msquaredMember@nimms wrote:
jgani wrote:
Does your solution still require Eclipse build to output to src/main/webapp/WEB-INF/classes ?Yes, but I dont really view this as a bad thing. What evil do you see from this? I have not seen anything bad really.
It’s a bad thing if developers include their resource directory on their eclipse build path as these get compiled into the WEB-INF directory, then maven comes along and includes them in the target directory. We had a problem with this when we first started using maven, and our test resource files kept turning up in our builds.
By the way, I’ll add another +6 for maven integration to be included as soon as possible. It’s a real headache for us and means we don’t use much of the myeclipse functionality.
Notice what I posted for my classpath:
<classpath>
<classpathentry kind=”src” output=”src/main/webapp/WEB-INF/classes” path=”src/main/java”/>
<classpathentry kind=”src” output=”src/main/webapp/WEB-INF/classes” path=”src/main/resources”/>
<classpathentry kind=”src” output=”target/test-classes” path=”src/test/java”/>
<classpathentry kind=”src” output=”target/test-classes” path=”src/test/resources”/>
<classpathentry kind=”con” path=”org.eclipse.jdt.launching.JRE_CONTAINER”/>
<classpathentry kind=”con” path=”org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER”/>
<classpathentry kind=”output” path=”src/main/webapp/WEB-INF/classes”/>
</classpath>So yes, resources ARE on my classpath. But test resources are output to a different location, so those are NOT bundled into WEB-INF
dbuecheMemberWe need the ability to have a project’s libraries defined as a set of maven dependencies, rather than redeclare and assign user libraries. This could work as follows:
1. At the IDE level (i.e., not tied to any project), the user can select which Maven repository to use. This configures the IDE to look there for all Maven-configured Eclipse projects.
2. At Eclipse project creation time, or when editing Eclipse project Properties, allow the user to select dependencies from a directory tree of Maven projects and versions currently in the Maven repository.
3. Save these projects in the .project and/or .classpath files, but without any directory path so that any user can load the Eclipse project from configuration control (including the .project & .classpath files), configure their Maven repository location (if not already configured), and the project finds everything it needs.
The main thing is that no absolute directory paths should exist in the .project or .classpath files, the user should be able to simply load the project and run without redefining any depency information.
Greg LloydMemberI recently started a new job that uses Maven and I have switched from MyEclipse to Netbeans because the Maven functionality is central to our development cycle. I desperately want to switch back to MyEclipse but the current eclipse maven plugin lacks maturity.
Key features that would need to be supported are:
Manageing dependencies
Support for sub projects
Allowing the execution of maven goals from the IDE
Creating projects from existing Maven Projects ie. POM filesIf it had these things then I would use it. If it had all these things it would be better than the current eclipse plugin, this isn’t asking a lot, is it not possible for
Genuitec to put a development effort into the current plugin and then intgegrate it into Myeclipse or is there a licensing issue?At this point I am not sure which is worse the eclipse plugin or Netbeans on a Mac.
Aaron DigullaMemberThe “Maven Extension for Eclipse” (= plugin for Eclipse) and the “Maven Eclipse Plugin” (= plugin for Maven) already support most of those features:
The former can manage dependencies and it will automatically include all open projects if there are dependencies. Unfortunately, this doesn’t work nicely with the way MyEclipse handles dependencies, especially scope=provided doesn’t work which leads to duplicated JARs in the classpath and all the problems associated with it.
You can also run maven from the context menu in Eclipse.
The last request is solved the both. Just run “mvn eclipse:eclipse” from the command line or enable maven from the context menu. This creates .project and .classpath files which should work.
-
AuthorPosts