currently the maven devs are working on MRM (maven repo manager) which will also maintain an index on the repository, so your first suggestion is on their todo list ;-) maven will just have to use that (and if it can't find an index, try manually for each dependency...)
for the 2nd and 3rd ideas: +1 from me! :) about the 4th one - there's a <prerequisites> tag in the pom which should state such things. Currently it only supports (afaik) specifying the minimum mvn version, but I guess it could be extended... how about putting these things in JIRA issues? On 4/27/06, Joerg Hohwiller <[EMAIL PROTECTED]> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi there, > > first of all I have to say that the dependency-management of maven2 is > really > cool! The scope is covering all needs I can think of and the transitive > dependency thing is really nice... > > Anyways here are some ideas about the dependency management I would like > to share: > > 1. I got the idea that a repository could have an "index". I am thinking > of > an XML file that contains the complete structure of the repro. > Then maven could download this "index" whenever it gets updated. > (Maybe wagon needs to be updated to be able to determine if the file has > not > changed and no aditional download has to be performed - e.g. HEAD request > if HTTP). > Before it wants to download a new POM or artefact it could simply see from > the > "index", if the project/artefact exists in the repository at all. > This could save a lot of HTTP-Requests and therefore performance. > > Think of a business project that adds a dependency on "com.foo.bar" that > will > never be found at ibiblio. That project might set up a repository in the > intranet and to keep it simple they just put the jars but no POM in there. > This will cause that every build the POM will be tried to be downloaded > from > all repositories including the central at ibiblio. I guess this way > ibiblio gets > tons of requests per day that are just a stupid waste of performance. > I do not want to conceal that an update of the "index" would cause a lot > of > traffic anyways - but just groupIds,artefactIds and versions would not > make a > big thing... An alternative would also be to declare a mapping in the > local > config from groupIds to repositoryIds. > > Also consider that the "index" would also be usefull in offline mode > and especially helpful for tools such as the eclipse-plugin where you can > have > autocompletion of the latest stuff out there when adding dependencies. > > Of course this would be an optional feature of a repository and the > configuration could have an option in the repository definition to ignore > the > "index" and still try to download stuff even if not in the "index" (but > disabled > by default). > > Further the "index" could be auto-generated and auto-updated so it would > cause > hardly any maintainance (whenever the feature was implemented at all). > > 2. Next I think that it would be nice to have more optional attributes for > a > dependency: > > A comment where one can document why the project needs the dependency - > currently I add this as comment but the dependency-report > could include the comment if it was inside the XML. > > A flag that can opt out the transitivity of the dependency. Then > if project A depends on that project B, it would not inherit the > dependencies from B that have to flag set. > Why this? > Think of a project that provides a simple API and a variety of > implementations. > As example we can think of commons-logging. Now the project could follow > the maven ideal and create a sub-project for the API and one for each > implementation that depends on the API and the underlying logger that is > used. > But what if the project does not want to follow this evangelism? > Or what if that project does not even know about maven and sombody else > just wants to use it in a maven project and writes a POM for it. > > Further think of a project that depends on SWT. Should it depend on > the windows, gtk or motif version? > > 3. The dependency report could have more information about a dependency: > > The license (might need to resolve the ancestor POM where the licenese > setting is inherited from). This would be very helpful for those > "political" > tasks - e.g. the GPL stuff... > > The link of the project that maintains the dependency. Would be cool if > the link could point to the dependency site of that project, but maven > could not know where to find this info without doing really wired things. > > Maybe another report could be added that lists all inherited dependencies. > > 4. Is it possible to define virtual dependencies? I think of a dependency > such as Java5 that does not include an artefact but just declares that the > project will require a jvm version > 5.0. In this case a plugin used to > execute the project could know the dependency and check if the jvm version > is right. > I guess that one can just write a POM with packaging "pom" and no > dependencies > to make this work but I havent tried. > Would you consider to provide something like this at the central repro? > > BTW - did you get in trouble with sun and their **** license because the > javax.* > artefacts are not available at the central repo? Doesn't geronimo provide > rewritten javax.* api-jars, that could be provided at ibiblio? > I can unserstand why harmony came up, but anyways I doubt that they will > ever > come to a working result... > > So far for tonight - i'd better go to bed for now cause my alarm rings in > about > 5 hours :( > > Regards > Jörg > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFEUBKHmPuec2Dcv/8RAklWAJ42SgzPt/YTUXI1+BzGcAWUAWm9JACgkI0Y > 3bfAmELexhnArZ4/auzWmNs= > =zdA3 > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- ______________________________________ Cheers, Arik Kfir [EMAIL PROTECTED] Linux user, number 415067 - http://counter.li.org/ http://corleon.dnsalias.org
