The plan going forward is for Maven 2.0 to support reading POMs for these, but not distributing the JARs, so the error messages can be more helpful. A plugin will be provided to make it easy to add to your local/internal repository from a filesystem location.
HTH, BRett On 5/5/05, Matthias Burbach <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
