I am using bintray for Open Source Projects, and hitting the repo limit (Not 100% sure since publishing error message is not clear)
When I tried to delete older versions of published libraries I was unable to... because they were too old...
Eventually deleted a newer version, and was able to publish...
Since storage is limited to 10GB and cleanup is limited to stuff published in the last year, my questions are:
How can I get more storage?
How can I delete stuff older than 1 year?
You can purchase a pro account, but I would contact Bintray's support to address the storage issue as Bintray might support Open Source Projects.
An OSS user can't delete content that is older than 365 days, at least that is what the content API says. I guess this is to prevent users from deleting artifacts used by others who rely on your project.
However, you can delete a repository using the UI.
For more information see Deleting Content under Managing Uploaded Content page
Update:
You can delete version older than 365 days using Bintray Delete Version API.
Related
I've haven't looked at SonarQube for some time. The latest version looks quite interesting.
The last time I checked out this product, they had a site where they had pushed various popular open source libraries (like Tomcat, ActiveMQ etc) through the SonarQube process. It was a great way of seeing how the product works.
Is this facility still available for the latest versions?
Have a look at http://sonarcloud.io (and click on "browse").
It is not a demo site - it is a globally available SonarQube server, managed by SonarSource (the company behind SonarQube). Many huge open source projects are managed there for free, but you can also host your own, private projects for closed source.
It gets updated every couple of weeks and for public releases.
Besides that, there is http://next.sonarqube.com , the publicly visible SonarQube server for SonarQube itself and related projects (yes: SonarQube for SonarQube).
This instance gets updated every couple of days. If you want to have a look at what features SonarQube's next version will look like: have a look there.
We are building and deploying multiple releases for various services in a single day. Due to this we are wasting a lot of storage for storing older versions of artifacts which will never be used again.
Is there a way to automatically delete older versions and just keep few versions such as last 10 in OSS 3.0.0?
I searched there documentation but couldn't find anything that works automatically. Currently I have to manually select and delete them which is very error prone and time consuming.
Few details about my setup:
"File" type "blob" is used for storage.
Repository is self "hosted" with format "maven2"
There are a few options you can use in Nexus Repository 3.x for Snapshots, from https://books.sonatype.com/nexus-book/reference3/admin.html#admin-system-tasks:
Purge unused Maven snapshot versions
Remove snapshots from Maven repository
As for Releases, removing Releases can be an anti-pattern, you generally should keep your releases around if others rely on them, etc...
There is a JIRA ticket for Removing Releases which you can follow at: https://issues.sonatype.org/browse/NEXUS-10821
This is also answered here: Purge old release from Nexus 3
I'm not able to use Notepad++'s update or plugin manager. I suspected it was a proxy problem, so I added my proxy to the plugin-manager settings but it still doesn't work.
Then I contacted my network admin and he said that he needs the server's URL to add it in the exception list. How can I find to what server it's trying to connect to?
What IP/URL does Notepad++'s plugin manager connect to for updates?
According to the project's creator, Notepad++ Plugin Manager's update URL is hosted on nppxml.bruderste.in
Hosting was moved from *.sourceforge.net to nppxml.bruderste.in in October 2016 due to a controversy where Sourceforge began bundling adware with installers for abandoned projects.
New Plugin Manager URL: https://nppxml.bruderste.in/pm/xml/plugins.zip
From the sponsor page for NP++ Plugin Manager
Since 2010, Plugin Manager has been hosted on Sourceforge.net. They've
been a great host for us, and generously supported the large amount of
traffic that the plugin manager generates. To put some numbers on the
traffic, whilst the plugin list is only 50KB, and is normally only
download when it changes, each change generates around 500GB of
traffic, with a steady 200GB of traffic each month.
In 2015 there was some controversy surrounding SourceForge bundling
adware with abandoned projects. This has since been cleared up, and we
applaud SourceForge for taking the right path in this regard. However,
this sparked some discussion and thinking around what we could do to
transfer the hosting of the list off SourceForge and onto another
provider, and what benefits and disadvantages that would bring. There
are things we aren't able to do easily with the sourceforge hosting
system, and relying on the goodwill of a website is not good in the
long run for the project. Using a more traditional hosting platform
would allow us to address some of the current issues we have around
automating the list updates, and serving a dynamic "bleeding edge"
list.
So, I'm very grateful to Nexinto that they are sponsoring the hosting and bandwidth requirements for Notepad++ Plugin Manager, and hope you can forgive the small logo and link in the plugin which means we are reliably hosted on VMs that we control, and hence can extend what we do, bringing automatic fortnightly releases of new plugins to the plugin manager.
For reference, the old url was https://downloads.sourceforge.net/project/npppluginmgr/xml/plugins.zip
If you are not sure if problem is proxy but plugin list is no displayed, try the next.
From "Plugin Manager, Settings", select checkbox "Use development plugin list (may contain untested, unvalidated or uninstallable plugins)
At the moment for v7.5 and v7.6:
Proxy setting are no displayed from Plugins Manager interface
Plugins server is http://nppxml.bruderste.in
Downloaded files by Plugin Manager:
http://nppxml.bruderste.in/pm/xml/plugins.zip
http://nppxml.bruderste.in/pm/xml/plugins2.md5.txt
Note: I am not asking how to use Google Code's SVN repo as a Maven repo :-)
I'm looking for the simplest / most reliable way to automate uploading the built artifacts of a Maven project to a Google Code 'Downloads' tab.
I've found 4 different Google Code Maven plugins that claim to do this, but would appreciate any advice on evaluating them as fit-for-purpose, because they all seem to be in various states of inactivity.
maven-googlecode-plugin (Last commit: Sept 2009. Latest version: 0.0.1-SNAPSHOT)
gcupload-maven-plugin (Last commit: Jan 2009. Latest version: 0.9)
maven-gcu-plugin (Last commit: Oct 2010. Latest version: 1.1)
maven-googlecode (Last commit: Feb 2008. Latest version: 2.0, but labelled 'test')
In addition to these 'level of activity' clues, some of them offer their releases on the 'Downloads' tabs, which might be a good sign from an 'eat your own dogfood' viewpoint; but as these are supposed to be Maven plugins, having them available in Maven Central might inspire more confidence.
Anyone care to comment (perhaps even the owners / committers of these projects) ?
Thanks!
Update:
I have test-driven each one of these in turn and could not get any of them to work as advertised.
Two of them are still configured to upload to a Google Code URL ending in /files, whilst another claimed to work and reported success, but the artifacts did not appear in the 'Downloads' tab. With the last one there appeared to be no released code which could be referenced as a Maven plugin.
I have since emailed each of the project committers to see what can be done.
If you are not averse to looking beyond maven plugins, google code has a SciptedUploads documentation, which seems to provide a python script and an ant task for doing this.
You may want to start reading the comments bottoms-up to see challenges using them, if any.
I got to this page by clicking on the link to "Create a New Download" for my google code project and clicking on the "Tip".
I always wondered why google didn't offer a Maven repository for each project by default.
Digging further, I discovered the following deprecated project:
http://code.google.com/p/google-maven-repository/
It appears the recommendation is to publish releases to Maven Central. This makes a lot of sense, as it certainly simplifies the discovery and integration of your project with other open source.
This movement towards Maven Central is a welcome and increasing trend in Java projects. Large projects like Oracle, Spring and JBoss are now publishing their releases there.
I have a project repositiory on Start Team server.
I need to take regular back up the same.
How can I achieve this?
The Star team backup steps are given in the Appendix C of the “The StarTeam Administrator’s Guide.pdf”
It depends on what you mean by backing up the Project. If you mean backing up the entire repository then StarTeam makes this really easy. You just need a snapshot of the DB and a full copy of the repository files (full steps are documented.) However, if you mean backing up a specific Project in the repository, and ONLY that Project, with all history intace, then this is not currently possible--or at least it is a major challenge.
StarTeam used to have an ability to Import/Export projects but they discontinued support and development of that tool years ago. If you wish to back up a single Project independent of the rest of the server, then this is still possible, and useful in the case where you want to split the repository into a separately managed repository. Here is how to do that:
Create a duplicate repository including all of the repository files.
Delete everything from the clone except for the Project(s) that you want to split off -- note that in StarTeam 2011 the Project Delete was broken, so you may need to do this in a direct SQL query which marks the projects/views as deleted. Contact Support if you run into problems deleting manually, especially if you have a large repository.
Once your clone has been pruned of unnecessary projects, run the Online Purge tool until all projects and respective files have been removed from the DB and the Vault.
You can now change what you need to change on the new repository, such as the users, groups, security, etc. without affecting the first repository.
Once you have validated the new repository is working properly, you can then run a similar process on the first repository to get rid of the projects that were split off.
Another potential use for this is if you had reached end of life for a project and you wanted to keep it offline and backed up but wanted it to be restorable with full history on demand (for regulatory purposes, etc.) while being freed up to remove it from the active repository so you can make other projects run faster. Though this is probably best done in batches of projects as the process is currently quite labor intensive to perform.