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 -----Urspr�ngliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Doug Douglass Gesendet: Mittwoch, 4. Mai 2005 21:27 An: Maven Users List Betreff: expressing dependencies of third-party jars in internal repository Specifically, I'm in the process of placing all the appropriate jars from Suns Web Services Dev Pack into our internal maven repo. But how should dependencies for these jars be expressed? For example, the JWSDP 1.5 contains jaxp-api.jar (1.2.6_01), which depends on SAX 2.0, which in turn is available via the ibiblio maven repo (sax-2.0.1.jar). Even if I chose to place sax-2.0.jar into our internal maven repo, is there a way to "know" that jaxp-api-1.2.6_01.jar is dependent upon sax-2.0.jar (or sax-2.0.1.jar)? Should I be creating a POM for JAXP, then perhaps use a tool like Deputy (search the archives) to discover the dependecies. Just looking for some advice on best practices... TIA, Doug --------------------------------------------------------------------- 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]
