|
Sort Order:
Hi Trygve, Yes, I agree with you. But believe me, that cannot be done in my case. This is my main rant about Maven: it forces the projects to adapt to Maven, not the opposite. I mean, I think the 'Maven way' is the best option in most cases; but when it isn't, it should allow you to adapt it to your needs. Anyways, even if it could be done, this feature would still be useful in other situations. For instance, I could have an images directory located somewhere else and need to access it locally if my project is a web application that is accessed as a context by Tomcat. – Felipe PS: I didn't assign it to me because I'd like to hear some options (like yours) first. But if we decide to implement it, I will do the changes (creating some test cases first). the better solution here is to make the eclipse plugin not overwrite existing linkedResources, and use the GUI to set them up in the first place. I'm -1 to adding a kitchen sink to the eclipse plugin. And -1 to ever allowing an absolute path in a project.properties file. This stuff is meant to be portable. Felipe, as far as your complaint about Maven "forcing" your project to adapt, that's rubbish. Maven's not stopping you doing anything here, it just simply can't support every new feature without getting too complex to use. Hi Brett, I don't want to start a flame war here, but by changing the linked resources on the IDE would require a manual tuning on the .project and I like the way that the whole .project and .classpath are generated automatically by Maven. That's particularly useful in our case, where we have many projects that depend on other projects of ours and these projects versions change frequently - so, with Maven, we just need to run 'maven eclipse' and the dependencies are automatically updated. And of course, Maven is open source, so I can just change the plugin locally at my company (in fact, we have many customizations that either are only useful at our process or that wouldn't be accepted on Maven's code). But I still think that the most the plugin could do automatically, the better. – Felipe > so, with Maven, we just need to run 'maven eclipse' and the If you can change the plugin to update an existing one rather than overwrite, you get that benefit too. If you are using a variable, each user will still need to set something up manually. If you are using a path, each user will still have to do something manually to get it in the right place/change the property. You're not gaining anything here. > And of course, Maven is open source, so I can just change the plugin This is the right thing to do in some cases. Too often changes are made to scratch an itch that are for someone's personal benefit rather than the wider set of users. > But I still think that the most the plugin could do As I've mentioned above, this is by no means automatic. You need to type some very specific, eclipse only properties for this. It's not a derivative of the funcamental metadata of the project. > If you can change the plugin to update an existing one rather than Do you mean adding a merge capability to the plugin? Yes, that would solve the problem, although I have the feeling it would be pretty hard to implement (I might be wrong though). > If you are using a variable, each user will still need to set Yes, but that set must be done only once. In fact, it's not even necessary to use the GUI, it's just a matter of adding some lines to a properties file on the workspace. > If you are using a path, each user will still have to do something I couldn't agree less that using the path is evil. I just mention it to be totally compatible to what Eclipse offers (besides, some companies do have pre-defined paths, as other tools like Rational Rose might need them). > This is the right thing to do in some cases. Too often changes are Yes, I know. But sometimes (not necessarily in this case) the change is generic enough... The fundamental solution for quite a few of these types of "customizations" is to reuse any existing .project or .classpath files. This way the Maven Eclipse plugin doesn't have to attempt to be all things to all people. I have started looking at the Maven 2 MOJO Eclipse plugin, where all the logic is done in Java. This I think would make it simpler to load up an existing xml document, and then manipulate it to do what we need. Anyone have an example of a Maven 2 MOJO plugin working in Maven 1? Eric/Brett, I found another use case wher this customization is useful: when doing expanded deploy on JBoss (or other application server). More specfically, I could have a goal that deploy an expanded ear on JBoss's deploy directory and then set the project (on eclipse) to generate the compiled files on that dir, which in turn would need to be a linked resource in my project. Granted, the resource would be an absolute path, but that's ok, as my goal (that did the deploy) could infer that path from the jboss/cactus properties. What do you think? – Felipe Felipe that is exactly my case. I have multiple projects in workspace that should be built into single war and target directory should be same for all projects so I can point tomcat to it. Currently I do that manualy by adding following in .project file: <linkedResources> |
||||||||||||||||||||||||||||||||||||||||||||||||||
Improvement
Open
Minor
Make it possible to add linked resources
I really don't think that this is a good idea to implement. You should really share the source as either a Maven artifact or make a Eclipse project out of the common source and link them in Eclipse (using Maven).
It just feels like too much of a hack.