Bintray seems quite interesting. I signed up directly! I see that it is still a beta and there are some bugs, and a bit of confusion signing up. It refused to work signing up with my google account, but after signing upp directly I can stil login with my google account.
That you can synchronize with GitHub is really nice! That you are looking wider than just maven is also really nice. I hope it comes out of beta soon! I apparently did not think far enough in my repository "wish" :-). /Tommy 6 jan 2014 kl. 22:48 skrev JBaruch <[email protected]>: > Hi Tommy et al, > > here's another option for you: > > You can leverage bintray.com to sync to Maven Central from there. For > starter, you'll just get your artifacts to Maven Central in more sane way - > no parent poms, no maven-release-plugin, no 20 pages guides. Just get your > artifacts to Bintray, include them in the JCenter repo (which is a superset > of central, btw), and voila, once your pom is good (all the needed tags > like description, developers, etc), your artifacts are in Central. But > that's just a start. You'll probably discover some nice features of Bintray > by its own merit - near real-time stats, packages watching and inclusion, > organizations support, fast CDN downloads, etc. > > Anyway, give it a try, your opinion on a painful Maven Central onboading > might change. > > Baruch. > > P.S. I am very much affiliated with Bintray and proud of it :) > -- > JFrog Developer Advocate > www.jfrog.com > +972544954353F > @jbaruch <https://twitter.com/jbaruch/> > http://linkd.in/jbaruch > <http://jax.de/node/901> > > > > >> >> I am assuming that you are putting this in Central so I can easily use it >> without having to worry about the effect on my build process or without >> having to get into your sources and dependencies to build my app and I have >> appropriate license agreements included so I know what I am incorporating >> into my app. >> >> In that case, I would like you to follow the Maven "Best Practices" for >> deploying to Central. >> >> Using the Release plug-in may save you some steps if you do not already >> have a private repo for releasing software internally. >> It seems to me that if you are already "releasing" to your own repo prior >> to trying to upload it to Central, you are probably going to find that the >> Release plug-in is not the "best practice". >> We would be in the same situation if we ever decided to put some of our >> utilities into Maven Central. We have already done the release and our SCM >> is in the state in which we want it. >> We would probably have to look at our parent POM/child POM structure to be >> sure that it met Maven Central requirements. >> >> I think that you did the right thing by raising your concerns here and I >> think that you got some very good advice and concrete suggestions. >> >> This is a very good group that is usually well-mannered when approached in >> the way that you did. >> You were very clear about what you wanted to do and you raised very >> specified issues that you wanted to discuss. >> You also reacted to the advice in a positive way that encouraged a factual >> discussion rather than a personal attack. >> >> Ron >> >> >> On 06/01/2014 7:49 AM, Tommy Svensson wrote: >> >>> Hello again, >>> >>> OK, I suspected that I get a lot of replies on this :-). >>> >>> From experience in other forums I also expected to have people tell me >>> to go screw myself, but that has not happened. There are apparently only >>> professionals here! That said, there some very good replies and >>> explanations but also some I do react to. >>> >>> I'll start with the latter. The arguments about quality I just don't buy. >>> We are only talking poms here. Whatever is in the poms says nothing about >>> the quality of the software itself. What is really bothering me however is >>> the argument that if you don't have your things in the way we think they >>> should be, you are not serious enough. It hasn't been said straight out but >>> implied. The word that pops into my head here is "Moralizing"! I take my >>> work very seriously and I take my open source work even more seriously >>> (since in that case I'm allowed the time for it :-)). That if I have one >>> file that is not up to someones liking I'm not taking releasing of my >>> software seriously is just absurd. >>> _______ >>> >>> From one of the replies: >>> >>>> As I said in a previous message, deploying to the remote repo is just a >>>> matter of "mvn deploy", using either the maven-deploy-plugin (by default) >>>> or the nexus-staging-maven-plugin. >>>> >>> That is good, that is how easy it should be! >>> >>> You'll have to configure the GPG plugin to sign your artifacts though, as >>>> it's a requirement to deploy to Central. >>>> >>> No problem! >>> >>> I'm going to go though the documentation again and solve the "easy" way >>> to do it :-). And If I can't find a page that explains this clearly I will >>> create such! I have gotten very much information here to go on. >>> >>> Someone also pointed out that local webserver repositories are good >>> enough for "small" projects. I basically agree with that. I only considered >>> maven central since someone asked me. But it is easier to have things in >>> central and not have to add multiple repository specifications in your >>> pom/settings. OK, you can use nexus to merge several repositories into one >>> and then use that. But if submission to central can be made easy then it is >>> worth to do it. Software does not have to be large apache projects to be >>> useful. There are some truly useful software out there that comes from >>> single individuals. >>> ________ >>> >>> Here is my view of how I would want a maven repository to be: >>> >>> - No requirements of javadoc or sources. If you want to include those, no >>> problem, but if you don't it is up to you. Personally I like to have >>> sources available in the repository for the third party software I'm using >>> so I would also submit sources to my software, but that is entirely up to >>> me. >>> >>> - Tags on submitted software (not required - can be empty). >>> >>> - Searchable data in addition to group and artifact: >>> - Tags >>> - Descriptions >>> >>> - A browsable (navigable) web gui, not just searches. >>> >>> - A standardized documentation zip containing PDFs and/or markdown. >>> >>> - Quality indication: >>> - The possibility to star artifacts just like you can star repos in >>> github. Also for group level. >>> - Download statistics (filtered on ip-address, multiple downloads from >>> the same ip-address only count as one). >>> - A quality value based on these two as sorting order for search >>> results. >>> >>> - When an artifact or group is selected in the web gui the following >>> should be displayed: >>> - Dependency tags for the artifact (obviously :-)) >>> - Pom information like description, web url, developers, scm url, etc. >>> - Stars and download stats. >>> - Any submitted docs. >>> >>> With so much software available in one place it would be very nice to >>> have it more searchable and on more useful criteria, and also to have the >>> ability to get more details on the software at the same place. >>> >>> Tommy >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >> >> -- >> Ron Wheeler >> President >> Artifact Software Inc >> email: [email protected] >> skype: ronaldmwheeler >> phone: 866-970-2435, ext 102 >> >> >> >> --------------------------------------------------------------------- >> 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]
