- This topic has 17 replies, 9 voices, and was last updated 16 years, 3 months ago by
.
-
Posts
-
Hello,
I’m trying to check out a java project from Subversion (using the Subversive plugin) that already has a POM.
I’ve tried to Find/Check Out As… into both a new Java Project and a new Java Maven Project.
When I check out into a new Java Project, I see no way to make it Maven aware and use the pom file to set up its classpath.
When I check out into a new Java Maven Project, it ignores Subversion entirely and only generates a shell Maven project. I’m then faced with the problem of “linking” an existing project in eclipse to SVN (AFAIK this isn’t possible)
What is the correct way to check out a project with an existing POM into MyEclipse so that I can take advantage of MyEclipse’s Maven functionality?
I am using MyEclipse Blue 6.5 actually.
Thanks,
AndyMyEclipse 6.5 supports only MyEclipse Maven projects created using MyEclipse wizards. Currently it does not support projects created outside of MyEclipse.
This is, quite frankly, ridiculous, but you’ve already heard that over in other threads. (But it’s sort of unfathomable how you guys didn’t anticipate that this would be a problem — integrating m2eclipse into MyEclipse in such a way that you removed functionality AND prevented users from restoring that functionality with their own local installs of m2eclipse. Did this really, really never cross the drawing board?!?)
delfuego and ayang,
I’m not debating that there’s definitely more needed here in the way of flexibility with Maven 2 (like simple detection of an existing pom.xml when creating a new Java Maven project in MyEclipse. MyEclipse just overwrites any existing pom.xml, rather than using it.)
However, I do have one suggestion for you both, with regards to project management, especially within a team environment, and when using Eclipse in general with SVN: do *not* commit any Eclipse-specific files to SVN. Don’t commit .classpath, .project, .metadata or external tools builders directories, etc. For one, this pins your source to an IDE, and ideally, your source code is best being IDE agnostic. Second, I’ve found working in team environments that Eclipse and various plugins can write user-specific data into their metadata, and if this stuff is committed to SVN, it can cause plugin havoc for everyone other than the last one who committed.
If you avoid committing Eclipse-specific files to SVN, you avoid having user settings stomp on others’ environments. I mention this because the side effect is that when grabbing a project from SVN, the Eclipse project has to be created at that time, and you can use the MyEclipse wizards to do this (you’ll just have to copy in the original pom.xml because MyEclipse will overwrite it….yes, that’s a pain).
But as for the Eclipse SVN plugin, my dev circle decided to punt on it, as it is flaky, and we use a tool called SynchroSVN instead, which is a pretty nice SVN client tool — think it may actually be built on the Eclipse platform as well, but not sure.
Thought that might help — you’ll ditch a lot of headaches if you get rid of Eclipse-specific files in SVN (ironically, it was Maven problems that lead us to do this).
Brad
I need to add one amendment to my reply — if you are using your source within a greater source tree (which you will if you are grabbing a branch from SVN), then there’s a problem, because it appears the Java Maven Wizard’s supposed ability to create its projects in a different directory other than the default workspace doesn’t actually work — it still creates the project in the workspace. This leaves a lot of copy / pasting if you want to tinker your way to a working project within a greater source tree.
I would still avoid putting Eclipse files into SVN, that has served us well for a long time, and solved a lot of problems. But to echo at least part of the sentiment, while it appears a step in the right direction, the Maven 2 integration with MyEclipse appears to address one use case: brand new project not destined for source code control. This will likely result in a MyEclipse downgrade for me for the time being.
delfuego,
Absolutely we did, many many (many many) times. The bottom line for us was that there were quite a few hurdles to clear to get Maven support into the IDE in an integrated and controlled way for it’s *first release* without hosing a bunch of people. For example, the default project layout for quite a few Maven-generated projects is not supported in MyEclipse; also not all project dependencies can be resolved perfectly against public or private repositories automatically. These are all things we had to consider.
When the product team sat down and planned it all out, we *knew* that release #1, whatever it was, had to be a completely passive update with regard to Maven; meaning folks that weren’t using it wouldn’t notice a change at all in their workflow and folks that were using it had an option to stay on MyEclipse 6.0 until we were meeting with needs with the support (yes it sucks, I know, but something had to give).
Our goal now is to figure out how to, in gradual steps, to keep Maven and MyEclipse playing nicely together as we open up more functionality to the more advanced Maven folks. It’s a conversation we’ve been having almost every day in 6.5 was released and the users feedback has been important to this process. We are aware that the current state for existing Maven users is a big soar point, and don’t want to leave it that way.
I guess my question is: why stomp on the namespace of the existing m2eclipse plugin? Why didn’t you create your functionality in an entirely different namespace, and make it so that users could choose whether to use it at all, and if they chose not to use it they wouldn’t have any problem installing m2eclipse right atop MyEclipse 6.5?
Unfortunately I’m not privy to the decisions the product management team makes with regards to clean-room/custom-implementation.
Actually this “new feature” prevents us from using 6.5 with our existing maven projects… which we would like to be able to do as used to. Downgrade ahead of us.
I also tried to use wizard. After deleting all eclipse files from SVN, I chose the option “Check out as project configured using New Project Wizard”. The result was that wizard had created empty project… and that’s it. It looks like obvious bug.
@support-eugene wrote:
MyEclipse 6.5 supports only MyEclipse Maven projects created using MyEclipse wizards. Currently it does not support projects created outside of MyEclipse.
I guess I feel compelled to chime in with my $0.02 worth (being Canadian, this isn’t that expensive for you Yanks 😉
I created a Maven project from scratch at work and checked it in to Subversion. I’m also lucky enough to be able to work from home and have access to that svn repository, and I’m flabergasted that I can’t check out that same project and work on it at a different location and have all the same functionality available to me. I can’t add Maven support to the project. I can’t figure out how to add AspectJ support. It’s a total nightmare trying to get this project working on another machine.
Where is the “Team” support in all of this????
It really sucks.
dmacpher,
I don’t quite follow, are you sure you checked all the project files in too? By default I’ve noticed project files not getting checked in sometimes to a repository (depends on the team plugin you are using). If your project is missing the dot files when it’s checked back out on the other machine MyEclipse doesn’t really know what it is.
Ok, I’m trying my first eclipse maven project, and while horrified to hear this news, it also appears that its using the default JAVA_HOME setting for running maven in, rather than the one that I’ve chose for the project. Bleech!
Ok, nevermind, found the configuration, it would still be nice if it caught what you’d set up as the default project JVM.All,
I received my MyEclipseIDE newsletter this morning, announcing a new version of MyEclipseIDE (7.0M1), with support for Eclipse 3.4 ganymede. I wanted to ask if the Maven support for existing Maven projects has been fixed in this new MyEclipseIDE release? If not, I’m doing nothing more than watching my subscription expire without being able to upgrade.
If the magnitude of the problem isn’t completely clear from this forum thread, just for the benefit of the developer folks, I use Maven 2 for *all* Java projects developed for my company and others I consult for. When I discovered that the initial Maven 2 support in MyEclipseIDE prevented using existing Maven 2 projects, I had to completely uninstall MyEclipseIDE and am unable to use it at all now. So I’m a version behind, and am stuck there until this Maven support issue is resolved. So if this support issue has been resolved, then please let me know, so I can upgrade. If not, then please understand the magnitude of the problem: I cannot use MyEclipseIDE at all until this is resolved.
Thanks,
Brad
Brad, we are working on further extending Maven support (and removing this limitation) in MyEclipse 7.0, I PM’ed you about it.
Riyad, why move this discussion to PM? The rest of us who’re following this (in part to decide whether to stay on the ME platform, in part because it’s amazing that this decision was made in the first place) would definitely like to know more details about the 7.0 changes that’ll come to ME’s Maven implementation.
Jason
