Hi Brett, Thanks for reporting the bugs. I could fix the first one easily (window closes unexpectedly).
I am not so sure, however, what to do about the 'doesn't build' problem. The obvious thing would be, of course, not to use a private-only repository for the dependencies. The problem then is: The jars I use are mainly taken from the JDOM distribution and I don't know if I can find exactly those anywhere out there in a public repository. And even worse, they seldom have a proper version coded in the file name nor do they have a POM stating their dependencies. Same thing with the Java Help jar. So I renamed jars to include versions I figured from Mainfest files and I 'invented' a few POMs and put all of this into my private repository. How can I do better? Is there an accepted way to improve the contents of a public repository even if it concerns artifacts I'm just a user of? Regards, Matthias P.S.: Concerning the other two findings, is it true that you cannot expand the group level folders in the repository? This might be because Deputy didn't find any POMs in those folders (without those they are empty from Deputy's point of view). Can you confirm this? What do you mean by the last thing 'doesn't attempt to resolve poms when the jar is present locally'? Do you mean to say there are POMs in a remote repository but you additionally have a local one which only contains the jars but not the POMs? -----Urspr�ngliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Brett Porter Gesendet: Freitag, 29. April 2005 03:06 An: Maven Users List Betreff: Re: Deputy - A Dependency Manager Tool for Maven 1.x Projects Hi Matthias, This is interesting. These sorts of tools are defnitely of interest to Maven. It certainly would be a lot easier with Maven 2.x, though not all concepts are supported yet - I think most of these if not all are planned for the June release. Some bugs I found: - closing and saying "don't exit" closes the window, but not the JVM. It should keep the window open - folders don't expand in any repository pane for me. The + just disappears (JDK 5.0_02) - the source tarball doesn't build (missing dependencies, and a reference to your hard drive for a the remote repository :) - doesn't attempt to resolve poms when the jar is present locally. Since m1 doesn't do this itself, this is probably a necessity. If you'd like to discuss the concepts of dependency management and where we are headed with m2, and how a tool like this might fit in, you are welcome to join the [email protected] list. Thanks! Cheers, Brett On 4/29/05, Matthias Burbach <[EMAIL PROTECTED]> wrote: > Hi! > > Today I released a tool called Deputy as open source on > http://deputy.sourceforge.net. > > It supports the creation and maintainance of complex Maven 1.x projects > which are assembled from other Maven projects. > > To do so it tracks down the dependencies defined in a Maven project.xml > file and resolves them recursively. It comes up with the recursive hull > of all indirect dependencies that can be reached when parsing the > project object models of dependencies and dependencies thereof > recursively. Considering the fact that artifacts a project depends on > are usually available in several versions and that different dependees > likely use different versions it is unavoidable that version conflicts > arise in the computation of all indirect dependencies. Deputy uses a > configurable default strategy plus further optional user-definable rules > to decide which version to take in each conflict. The default strategies > available are suited to keep up with the latest versions of projects > easily. The latter makes Deputy also a good tool to update simple > project.xml files that don't hold the indirect dependencies explicitly. > > I created the tool because there was a desperate need for it in the > projects I'm involved in. At the time of writing Deputy, Maven 2 with > its built-in solution for transitive dependencies was not available yet. > Now that Deputy exists I decided to publish it for two reasons: > 1. I am happy to share it with other Maven users who possibly have > similar requirements > 2. I would like Maven developers to take a look at it to increase > chances they will cover our requirements in the Maven 2 solution for > dependency management. > > Regards, > Matthias > > --------------------------------------------------------------------- > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
