maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tommy Svensson <>
Subject Re: Maven Central Opinion
Date Thu, 09 Jan 2014 20:33:08 GMT
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" :-).


6 jan 2014 kl. 22:48 skrev JBaruch <>:

> Hi Tommy et al,
> here's another option for you:
> You can leverage 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
> +972544954353F
> @jbaruch <>
> <>
>> 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:
>>> For additional commands, e-mail:
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email:
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message