Our plan with bad metadata is to identify the most popular libraries and clean them up before 2.0. This includes things like Spring, Hibernate, Dom4J, and commons-*.
On 9/21/05, Stephen Duncan <[EMAIL PROTECTED]> wrote: >Possible solutions: > >1) Manually specify exclusions on everything but optional jar that I want. > > This is what we chose as the "get out" plan so users had control when the repository is bad. It isn't needed in a validated repository, but it is the least verbose when a POM is correct for >50% of the deps. >2) Allow me to use an option to "turn off" transitive dependencies on >that jar, and explicitly depend on the optional jars I need (such as >hibernate2 in example above). > > The issue we see with this is that it degenerates to m1 functionality, and will very quickly become a crutch for people, further degrading the quality of the metadata. In the world where all the metadata in the repository is -correct-, this should not be needed (ie for your own projects), which is why we have avoided adding it. If we were to do this, would you use it, or would you ask that the project be fixed? Would you take the time to do both? (You may, but most won't). >3) Create "optional" scope. Rely on repository POM to set this >properly. Then explicitly depend on the optional jar. > > This still seems the most reasonable to me. You still *might* need it yourself (though discouraged). >4) Create "optional" scope. Rely on repository POM to set this >proeprly. Add "inclusions" for optionally-scoped jars that mirrors >exclusions for currently passed along jars. > > Inclusions is really just a less agressive version of (2). It is more verbose than (1) in the case where the dependencies are correct > 50% of the time. So if we fix the biggest offenders, (1) remains the best solution. As above, if the repository were correct you wouldn't need this yourself. >Hope this was helpful. At the moment my preference would be to have >option 2 working today (well, not literally...) > It's a last resort. We'll see how we go with repairing the repository with the 80% of the commonly used dependencies and then repairing the rest on demand. >(since it will take >some time for the repository POM's to be accurate), > I think in 2 weeks we will have 80% done. (of those used, not 80% of all artifacts :) >But what I really missed was a technical issue: if you are specifying >that you want to include a "optional" scope dependency, at what scope >does it get used in your project? > > I was anticipating "compile", but I guess that's not necessarily true. So instead, it will be a separate flag. >Not sure on etiquette/proper tracking here: should I put a suggestion >of using <inclusions> (Including scope) as a commont on the MNG-947 >issue, or just wait and see on discussion on the mailing list and a) >do it later, b) let a developer who likes the idea put it on there... > > > Yep, you are welcome to comment on JIRA issues, though if you are unsure if it is the right direction the list is easier to maintain a discussion on. JIRA is better for the implementation/verifying/fixing cycle. Thanks for the feedback. Cheers, Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
