On Wed, 14 Sep 2005, Ashley Williams wrote: Hi,
> Just been playing around with eclipse projects. I see that > eclipse:eclipse makes a separate project for each pom, whilst > retaining the option to add project references if you want to. > Wouldn't it make more sense though, for eclipse:eclipse to add a new > source folder under an existing eclipse project? As a graphical > illustration: Currently it will retain the project structure for eclipse that has been established for m2. Since there probably was a good reason to split up the project sources into multiple maven projects, why shouldn't the same go for eclipse? > Current eclipse:eclipse result: > > MyUtilProj [classpath REPO/junit] > MyModelProj [ref MyUtilProj] [classpath: REPO/jaxen, REPO/junit, > REPO/myutil.jar] > MyGUIProj [ref MyModelProj] [classpath: REPO/servlets, REPO/ > httpunit, REPO/mymodel.jar] > > > Suggestion: > > MyKillerApp [classpath: REPO/jaxen, REPO/servlets, REPO/junit etc, > REPO/httpunit] > - utilsrc > - modelsrc > - guisrc We've had this request before. It's possible, but it would complicate the plugin a lot - we need to merge the dependencies, for instance. > which would seem more in keeping with how you would manage a project > before you had heard of Maven (maybe not in the experience of > others). The risk of doing this is that when you manage your eclipse project, it's easy to use the wrong classes. For instance, when you have an api project and an impl project (SPI framework), it's tempting to use the implementation directly, or to use other classes that you're not supposed to touch. Keeping the projects separate, with either jars on the classpath or references to other projects, will enforce the dependency rules specified in the pom for that project. > Also there is a practical advantage that when you press F3 > to navigate to a type, you go straight to the source file. With the > current arrangement (maybe its my ide settings, but I don't think so) > you get the unwanted choice of going the the class in the jar file > artifact (and "would you like to attach source" etc). That's been solved a while back: you need to run m2 eclipse:eclipse in the root of the project hierarchy (optionally using -r if not all projects are referenced from the modules section). It will: o use available reactor projects to make project references instead of classpath entries to the jars in the local repository. and if you specify -Declipse.workspace=/path/to/workspace: o generate a subdirectory there for each project encountered in the reactor; o create eclipse folder links to the (generated) source/resource directories; o create a file link to the pom; This will help in creating a flattened project tree (a list, actually), to circumvent eclipse's limitation of nesting projects. It will also add pom projects (or will, when I commit :)). > Additionally, my personal favourite, is that when you go to the Java > Browsing perspective, you can see all the code under one package > source tree - just make sure MyKillerApp is highlighted on the left! Yup, that's an advantage. It's also a disadvantage because you can't see which package belongs to which project. But class hierarchies etc. will work as expected. > I believe to get this to work, you would need to configure the > eclipse plugin with the location of an existing eclipse project for > it to append a source folder to (it would create the project if it > doesn't exist). Although this is extra info to tell the plugin you > would get to remove the info about project dependency. > > In fact because all the artifact poms have a parent pom in common, > you wouldn't even have to specify an eclipse project, it would create > one based on the name of the parent. Not necessarily true - they don't have to share a parent pom to have dependencies on each other. But generally it's true. -- Kenney --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
