Doug, You're right that Deputy recursively discovers dependencies of dependencies and adds them to a project's POM. The prerequisite to make this work is that each dependency project has a POM in a repository which defines its dependencies. And this is where the problem is: if 3rd-party jars occur somewhere in my dependency graph which are not (yet) represented by a proper POM in a public repository I have to reconstruct/fake it in my local repository. But this is not in line with the Maven idea as I understand it (though it works in an isolated environment).
Cheers, Matthias -----Urspr�ngliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Doug Douglass Gesendet: Donnerstag, 5. Mai 2005 00:06 An: Maven Users List Betreff: Re: AW: expressing dependencies of third-party jars in internal repository Matthias, This issue was the initial reason I setup an internal repo -- I couldn't determine the EXACT versions of the dependencies required by/bundled with a third party jar, so I did just I as you describe below. The general problem, as you know, is discovering the dependencies of a dependency and having them all added to a projects POM (or at least it's classpath). I presume this is where Deputy helps (I haven't had time yet to check it out). Perhaps a new "bundle" dependency type could be used (i.e., <groupdId>/bundles/<artifactId>-<version>...) where the bundle is just a zip of jars. Or better yet a jar with a Class-Path entry in its manifest. Hmmmm... Since I haven't written any plugins (yet), I'm not sure of the feasibility/effort of adding a new dependency type, but I'm willing to help ;) Cheers, Doug Matthias Burbach wrote: > Hi, > > The other day I posted a similar question. > > It was in reply to Brett's hint that the Deputy sources don't build > because I defined dependencies to 3rd party jars which are only > available in my local repository under exactly those names. > > The question went like this: > >>... >>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? > >>... > > > It would be great to find a better solution to this. > > 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]
