On Mar 10, 2010, at 11:28 AM, Ron Wheeler wrote: > Jason van Zyl wrote: >> On Mar 10, 2010, at 8:47 AM, Ron Wheeler wrote: >> >> >>> Jason van Zyl wrote: >>> >>>> On Mar 10, 2010, at 8:32 AM, Ron Wheeler wrote: >>>> >>>> >>>>> Anders Hammar wrote: >>>>> >>>>>> Eh, not sure what you mean. Are you asking where in the Maven docs it is >>>>>> stated that the pom should be correct? I think that would go without >>>>>> saying, >>>>>> don't you? A default pom is most likely never correct, as think Jason >>>>>> said >>>>>> earlier in this thread. >>>>>> >>>>>> >>>>> Cute but not likely the issue. I think we can take correct POMs as a given >>>>> >>>>> >>>> If it is in Maven Central it will be correct from now on. But there are >>>> many POMs that are not correct and what Anders is referring to are the >>>> generated POMs when you install 3rd party dependencies into your own local >>>> repositories. Those are almost certainly incorrect. Unless the artifacts >>>> you are installing have no dependencies then they are wrong. It's a stop >>>> gap and we probably shouldn't even allow it anymore. >>>> >>>> >>>>> Where does the documentation describe how to make a POM for a 3rd party >>>>> module and why that is worth doing. >>>>> >>>> For anything going into Central the document is here: >>>> >>>> http://maven.apache.org/guides/mini/guide-central-repository-upload.html >>>> >>>> You should really follow the same procedure we follow there. >>> It does not really address the problem since I am not trying to put >>> something into Maven Central and I do not own the domain of the groupId or >>> really care about any of the other stuff. >>> >>> >> >> Feel free to ignore our advice. If you're never going to share the artifacts >> or work with anything else then it doesn't matter. If you plan to actually >> share the build with anyone else it will likely matter. >> >> > What advice? > I can not share them with anyone else since they are licensed in a way that > prevents them from being in Maven Central in the first place. That was the > original problem that we are trying to address.
The point is not distribution from Maven Central, the point is sharing of the artifacts if the sharing goes beyond yourself as an individual. You may very well put an artifact that cannot go in Maven Central into your own corporate repository. From there without a correct POM you won't get the right dependencies, without a javadoc JAR it's hard for developers to find out about code, without a source JAR it's hard for developers to debug, and without a signature you'll never be able to validate the origin of the person who submitted that artifact to your corporate repository. We ask for these measures as a general good practice of using binary components, regardless of where they are being distributed from. > >>> It probably would be a good idea to have a page that just discussed the >>> issue of how to create a POM for your own use that describes some third >>> party package. >>> >> >> There is no automatic way, you need to know the dependencies and list them >> in your POM. We'll take patches. Documentation from new users is often the >> most helpful to other users. >> >> > This relates to an earlier discussion about the difficulty of using Maven > documentation. > It is not written from the user's point of view. > There is probably no individual fact about Maven that is not documented > somewhere. > The complaint is that it is too difficult to get up to speed in Maven (not > started by me but I share the sentiment.) > This is just an example of where the documentation is in need of improvement. Sure, we generally get complaints like this and my response was to have 5 books written. We do what we can, but we have a lot of users take Maven and use it, complain, and never contribute anything back. It would be far more useful for you to sit down and take this information and write a document for other users. We have lots of people dish out advice, but not so much documentation. We know it's hard, that's why it takes a long time to produce. > > If I want to create a repository for my own company's use of 3rd party > software that I have downloaded under a license that prevents this package > from being distributed in Maven, your view is that I have to know that I will > find some of the information to do this by imagining that I am the developer > and I want to submit it to Maven Central. You using a piece of software in your own internal repositories and what you use in Maven Central are two entirely separate things. No one puts their own artifacts, or commercial components they purchased into Maven Central. You wouldn't put your own sources or sources you purchased into a public SCM, and Maven is no different with binaries. Maven Central is primarily for OSS components. > That is not the first thought that would come to my mind as a search criteria. > If you don't understand how Maven works, sure. > There are a lot more users of these packages than developers but the Maven > documentation makes the opposite assumption and writes the method in a way > that focuses on the developer rather than the user. Noted, but you can fix this by writing some documentation. We're developers so naturally we write the first documentation from that perspective. Writing documentation for release engineers and/or people who are not developers often comes second. A stark difference between a project and a product. Maven is an open source project. You get what we make and you can contribute to make additions you see as a benefit. There's only so much we can do in a day and most of the developers focus on ... developing. > > I would suggest that the need to create a minimal pom for a 3rd party package > is worth a page in the Definitive Guide and on the web site. Deal. You write it, we'll add it. > >>> It is probably a trivial page but try to find the page mentioned above by >>> Googling for "Maven 3rd party POM" or some other likely search string. >>> >>> >> >> We could just point back to the document I pointed you at. Those are really >> the minimum requirements for artifacts that instead to go beyond a >> personal/local scope. >> >> > That page is too much oriented in its description to a developer who wants to > submit it to Central. It has policy discussions and directions about proving > that you own the GroupId domain, that a user pretty quickly decides that the > page does not apply to the problem that he is trying to solve since he meets > none of the minimum requirements and does not want to (and legally can not) > submit someone else's work to Maven Central. > Another page that is smaller and more focused on the user's problem of > creating a pom for someone else's package should be added. It is a fairly > common problem and the maven solution is perfect, once you figure out what to > do. > > >>> Ron >>> >>> >>>>> What is the minimum info required? What are the optional things that you >>>>> should try to add for a module that is open source and for one that is >>>>> not? >>>>> >>>>> Ron >>>>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl ----------------------------------------------------------
