Re: Commons-vfs for Archiva?
Hi Carlos! that topic was already brought before and didn't succeed Do you remember what the problem was? Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RANT] This Maven thing is killing us....
Hi! If project A says it depends on B 1.0 and C says it depends on B 1.1, there's a conflict in Maven, Ant and anything you want to use, the difference is that Maven tries to do it for you, but you still can override that behaviour. We also ended up putting our jars in svn again and using only system jars with a path to the jar in our pom. We have 50 direct dependencies, maintaining exclusion lists is a pain in the a** as you have really spent a couple of hours to get everything right again when you add a new dependency. And the problem is not only a version number difference. Also a project might decide to change its artifactId - or split into different smaller pieces. THAT was the real bummer for us. Whats missing in pom.xml is something like: replaces and conflicts So a artifact might say, ok, I replace any other artifact or I cant work together conflict with one. Say if xmlrpc decide to split into xmlrpc-common, xmlrpc-server, xmlrpc-client, xmlrcp-all then it can say that it conflict with xmlrpc - and for xmlrpc-all it can say that it replace xmlrpc. Still, user intervention is required, but thats better than having the same library on the path multiple times, just due to the fact that the name differs. Maybe also a contains would be nice, so xmlrpc-all can say it already contains the server,client and common part. But I have to admit, I dont want the one programming the dependency solver ;-) Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] eclipse-plugin: arguments for buildcmd and other enhancements
Hi! Given I might find some time I would like to implement the possibility to a) add arguments to the buildcommands. b) to define dependencies should be exported a) I would like to archive this by allowing to add a CDATA section to every buildcommand in pom.xml. So in the end it should look like this: buildcommands buildcommand classNameorg.eclipse.ui.externaltools.ExternalToolBuilder/className triggersfull,incremental,/triggers arguments ![CDATA[ dictionary keyLaunchConfigHandle/key valuelt;projectgt;/.externalToolBuilders/Explode.launch/value /dictionary ]] /arguments /buildcommand /buildcommands b) a simple boolean which states if the classpath entries should be marked as export for now this should be a global flag for all dependencies of kind var What do you think? Can this be done that way? Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] eclipse-plugin: arguments for buildcmd and other enhancements
Hi! No one interested? Hi! Given I might find some time I would like to implement the possibility to a) add arguments to the buildcommands. b) to define dependencies should be exported a) I would like to archive this by allowing to add a CDATA section to every buildcommand in pom.xml. So in the end it should look like this: buildcommands buildcommand classNameorg.eclipse.ui.externaltools.ExternalToolBuilder/className triggersfull,incremental,/triggers arguments ![CDATA[ dictionary keyLaunchConfigHandle/key valuelt;projectgt;/.externalToolBuilders/Explode.launch/value /dictionary ]] /arguments /buildcommand /buildcommands b) a simple boolean which states if the classpath entries should be marked as export for now this should be a global flag for all dependencies of kind var What do you think? Can this be done that way? Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
