It seems like a free, artifact storage application with a nice GUI for jars, wars, rpms, etc. is really needed given that SVN is a bit old and Artifactory and Nexus (can be) are quite expensive. So I am confused as to why Apache Archiva never really went anywhere? I know the main engineer just released a new version just before the time of this writing and I am grateful for his time and effort. Nonetheless, it seems like this product never really caught on for build and devops teams even though it should have...
Well it's hard without more contributors :-(
Please note the project is now using git https://github.com/apache/archiva
I'm who you call the main engineer. I was paid few years ago to work on this project but now I do it during my spare time (and I have limited spare time :-( ).
Why not contributing/helping? :-)
Related
It's over a year that we have had a commit for QueryDSL.
https://github.com/querydsl/querydsl
Shall we consider this project Dead or is it moving to a new group? I guess the old team have no plan to maintain it anymore. New JDKs arrive every 6 months and I guess this project will be out of date sooner than we expect. Any news or compatible alternative?
I joined the querydsl team several years ago but lost interest due to the time constraints of having a full time dev job. I am however still a member of their Slack workspace and as of today, no-one has posted in the #general channel since July 2018. When I was active, the channel was busy most, if not every day.
I'm led to believe that Timo Westkämper (owner) is too busy / has lost interest, as with most (all?) other devs excluding Ruben Dijkstra who has contributed a great deal towards the project but is busy with University. He intends to come back. I heard that Atlassian started contributing but there was no-one to up-skill them and deal with their prs, so they ducked out.
In summary, AFAIK, no-one is working on the project and it would appear the owner has lost interest. I'm considering JOOQ but worry it's somewhat of a one-man-band too. If Lukas moves on, we could be in a similar situation.
I think querydsl is a great tool and it's free for all RDBMS, compared with better maintained JOOQ. In my personal opinion, I'd like to see, minimally, querydsl-sql forked by the open source community, its dependencies reduced (it brings in a lot for what it is) and its Java version brought up to date. Perhaps querydsl-jpa could follow. These, IMO, are by far the most used jars and the more specialised functionality could be dropped, E.G.
querydsl-collections
querydsl-hibernate-search
querydsl-jdo
querydsl-lucene*
querydsl-mongodb
querydsl-scala
querydsl-spatial
querydsl-sql-spatial
querydsl-sql-spring
UPDATE
Timo has approved the handover of the project.
UPDATE
The querydsl team is back in action with querydsl 4.2.2 in Maven central as of 22-Nov-2019 and querydsl 5 in the pipeline. Thank you to the new team members for breathing life into this excellent project.
our small team of 2 people recently got upgraded to 5, which means we should introduce a bit more infrastructure around our project in order to work efficiently together. Its a university research project.
How much administrative effort is it to run
Gitlab
Jenkins
A Release Server
on a rented machine, in comparison to a SaaS solution e.g github with Travis ?
Unfortunately nobody in our (quite academic) team has practical experience with that. I know the setup can be done fast, but how time consuming is it to keep the stuff running. Are there other concerns we might be missing?
Of course we would like to mainly work on the project itself, but since the toolstack keeps growing by time we are not sure if a SaaS solution is what we need.
With these inputs be ready to spend from one to several weeks of one from the five.
Instead you might want to check which leading hosting companies provide free services for open source or educational projects.
I am managing the development of currently two different web applications of which one will roll out in beta testing before sunday.
I have some previous experience from SVN usage, after playing around a few hours with TortoiseSVN locally on a XP machine, but I never really got the hang out of it to be honest.
However, it feels like it's about time to rethinking SVN and really try to give it an honest chance. I would at least sleep alot better if I know that versioned backups of each file were available and it was easy to roll back changes to an web applications whenever something hits the fan. Especially as the app grows bigger.
I currently work exclusively with PHP in Eclipse and deploy all files for the beta environment through FTP.
I have read most posts here about using Eclipse with SVN plugins, but I really doesn't understand how the workflow practically would look when SVN is used.
Do I check in every morning to my repository, do what i do best, and at the days end commit all changes?
How would sync be kept between local file structure, SVN repository, and multiple environments (live env., testing env., etc)?
Tell me about how your workflow looks when using SVN!
You may want to start by going through the free online book:
Version Control with Subversion published by O'Reilly Media
Chapters 1 and 2 go through the fundamental concepts and the basic usage of Subversion. Then the remaining chapters explore more advanced topics.
Here's my steps with SVN for what I do:
Branch to work on bug/feature -> When starting to work on a bug or feature, I create a new branch taking the head revision of the code so that I'm in my own sandbox of sorts.
When I've fixed the bug or finished the feature, then comes the switch back to the main branch and merging in the fix so that it becomes part of the next code push into either dev clean or test. While this isn't exactly simple, it isn't as painful as one may fear.
Periodically, there are other things to do:
Clean up old branches -> As features and bugs get done, sometimes it is worth going back and pruning the work done so that the folder doesn't become huge in the Repo-browser.
Update code on my box -> Sometimes I'll go a little time between features and bugs, though I'd still like to keep the code on my machine up to date as much as possible.
Hmm,
If I may mention the little app I'm working on currently, dashy: http://www.mirios.com.au/dashy, it handles what you're concerned about from the deployment/configuration side (rolling back changes, handling configuration of multiple environments: dev/staging/live, etc) and is suitable for Windows + SVN only, at the moment. (Getting started with it, however, will be slightly involved, and the documentation isn't particularly complete, though it gives an idea).
As to how to use SVN in general, well, you have a build server, and you use a CI system to to automated builds, then you commit to your CI server (We use CruiseControl.NET, Hudson could do it as well). Further to this, you generally update in the morning, to check if anyone in the team made relevant changes, and use branches and tags where appropriate.
It's kind of complicated, (but not really) and once you get started and get everything installed, life should be quite good (whether or not you use dashy).
There are about 200 projects in cvs and at least 100 projects in vss. Some are inactive code in maintenance mode. Some are legacy apps. Some are old apps no longer in use. About 10% are in active development. The plan is to move everything to perforce my end of year 2009.
Has anyone done a large migration like this?
Has anyone come across best practices for moving from cvs to perforce? Or a similar migration. Any gotchas to look out for?
On the VSS side, there are conversion tools that are available to help with migration. They can mostly maintain version history (there are caveats that are explained in the readme and docs). I have migrated well over 50 VSS projcts into perforce using the VSS to perforce tool. Getting the data out of VSS can be a bit finicky and not terribly speedy, but it works. If you have direct access to the disks (i.e. not over a network share) to the VSS repository, the conversion can go much quicker. You can find information about the scripts here.
There is a simlar page for CVS to perforce conversion here, although I don't have direct experience with that. These links are good places to start. You can also search through the Perforce mailing lists at the Perforce Knowledge Base located here. I'm pretty sure that you might find some conversion information in the mailing list archives.
Migrate your old projects first. You can make sure that your process works. When we migrated active code to Perforce, I took one weekend and basically took down access to the servers and moved the code over to Perforce. Honestly, it was a pretty easy migration and when people came back on Monday they were ready to go. You might think about preparing your employees with Perforce cheat sheets after you start doing the migration.
The biggest gotchas might actually be preparing your people to use Perforce. Had I done it over again, I would have migrated our smaller active projects first and prepared smaller numbers of people to use Perforce at once. As it was, I had to train 120+ people on day 1 after the migration and that was a bit much. Also, make sure that you don't have 100+ people hitting your server for a fresh sync on day 1 either. We wound up taking our server down multiple times during the first few days. We used a windows 32 bit server which I would not recommend. We have a windows 64bit server now and it's much more robust. If you can, I would actually use Linux as your OS for your perforce server. Again, there should be good info on the Perforce site about performance.
I haven't had to do something of this scale, but I have a few ideas. First off, start by taking a small, unimportant project, and migrate that. That will give you an idea of how much trouble it is going to take to migrate the rest of the projects. Immediately after that you should choose a medium size project as there may be issues with migrating a larger project (say with branches) that might not be apparent on a small project.
Make sure you spend a bit of time seeing how easy it is to convert cvs projects to vss, or the other way around. If converting from vss to perforce is a real pain, you can convert vss to cvs, and then to perforce. Don't sink days into it, but it could back you out of a sticky situation. I think the key here is go incremental.
Backups are good. Period.
Consider a cutoff date, and any projects that are inactive, and older then that, should be mothballed. Check out the final revision and store that in Perforce. Do you really need 15 yearold visual basic code?
What ever you do, keep the old repositories in read-only mode some where.
Forgive my answering a question with a question, but doesn't Perforce provide tools for this? Or, at the very least, documentation? I'd be beating up my Perforce salesperson...
Consider not migrating dead and inactive projects. Simply put their repositories in read-only mode. The data will still be available if needed and you save the time effort of migrating them. Just migrate the 10% that are in use. Document the process thoroughly.
If one of the un-migrated projects gets resurrected some time in the future you can easily migrate it using your documentation as a reference.
We migrated our svn repository with a tool that we wrote, and just took the head revision of our starteam projects.
Watch out for differences between single-file checkins (CVS) and multi-file changesets (Perforce).
Watch out for branches is separate space (CVS) vs. branches in filepath-space (Perforce).
Questions #1 through #4 on the Joel Test in my opinion are all about the development tools being used and the support system in place for developers:
Do you use source control?
Can you make a build in one step?
Do you make daily builds?
Do you have a bug database?
I'm just curious what free/cheap (but good) tools exist for the small development shops that don't have large bank accounts to use to achieve a positive answer on these questions.
For source control I know Subversion is a great solution, and if you are a one man shop you could even use SourceGear's Vault.
I use NAnt for my larger projects, but have yet to set up a script to build my installers as well as running the obfusication tools all as a single step. Any other suggestions?
If you can answer yes to the building in a single step, I think creating daily builds would be easy, but what tools would you recommend for automating those daily builds?
For a one or two man team, it's already been discussed on SO that you can use FogBugz On Demand, but what other bug tracking solutions exist for small teams?
source control: Subversion or Mercurial or Git
build automation: NAnt, MSBuild, Rake, Maven
continuous integration: CruiseControl.NET or Continuum or Jenkins
issue tracking: Trac, Bugzilla, Gemini (if it must be .NET and free-ish)
Don't forget automated testing with NUnit, Fit, and WatiN.
1) Subversion
2) Ant / Maven
3) Continuum
4) Bugzilla / Trac
My preferred stack:
1) Subversion. I'm intrigued about distributed source control but haven't had chance to try any in anger yet. For a centralized solution svn is rock solid.
2) Ant. Maven is a joy to use when it's working but as an old ant hacker I find maven to be hard to follow once things go wrong.
3) Hudson. Not been mentioned so far but definitely worth investigating. Incredibly usable and actively maintained tool. PreviousLy we paid for Anthill Pro which seemed flakey and was painful to fix each time it screwed up.
4) We pay for jira. Not cheap but much more usable than the open source options we looked at and very flexible too.
My engineering stack:
Git (I love GitHub, but Git doesn't require a hosted solution)
Rake
CruiseControl.rb
FogBugz
No doubt these choices are influenced by my development stack, which most often includes Ruby, Rails, SQLite, Firefox, and OSX.
You may want to look at an existing question of mine for finding an alternative to Team System. There are plenty of recommendations in there also.
Git
Make
Cron
Trac
I'm a man of few syllables ;-)
Be sure to use some kind of version control where developers can easily create private branches willy-nilly, then take their private branch and squeeze it into a single commit on the main branch. That way, individual developers---as opposed to the organization---can get the benefits of version control without polluting anyone else's code (and slowing down their work) with broken commits.
This feature is what I like about git. I think it's only really present in distributed version control systems; using a DVCS doesn't mean you actually have to do distributed development, though.
Regarding one-step building, make is the default build tool and it works quite well for most tasks. I'd go with that unless you have a good reason not to.
You want daily builds, put the build command in your cron.daily. Set up a procmail hook to handle the mail from cron if need be.
For bug tracking, use $(apt-cache search bug tracking). Basically, as long as it says "bug tracker" on the box and you know other people are using it, it's probably going to work fine. Among the regulars are bugzilla, mantis and trac.
I don't have any tools to suggest, but I do have a suggestion about the daily builds. I always answer yes to that question, even though we don't have daily builds. Instead, we do a build every time someone does a commit. We thereby catch any problems almost immediately. If any of our projects ever has enough LOC that building takes more than trivial time, doing this will also gracefully degrade in the direction of a daily build.
A good issue tracker that was relatively inexpensive was axoSoft OnTime. I used it for years before getting MS TFS.
Nant and CruiseControl are staples of my environment.
I don't think you really need obfuscation on .Net any more (see another response)
I wouldn't consider Vault, SVN is really the market leader at the moment (and free). Git is looking pretty promising but currently is command line only with a steep learning curve.
MSBuild beats NAnt for .Net 2 or 3.5
CC.Net is excellent.
*4) Redmine
I recommend Bitnami for testing out different stacks. It's got Trac, Redmine, and Subversion, as well as several other unrelated ones.
Check out these articles on Continuous Integration using MSBuild, CruiseControl.NET, FxCop, NUnit, NCover and Subversion...
From the software development trenches
I'm currently using SVN but I've generally had a lot or problem with checkouts to a network drive on a dev server. There tend to be locking issues that require a lot of fishing around to fix. It may be that using the WebDav access method, would ease some of these problems, but I haven't experimented yet.
Any of Bugzilla, Trac or Fogbugz will help you with your bug tracking, and each offer an export feature, so you can always change your mind later on. Also, if you can get your team to fully buy in, time management software can also be handy for post-mortems, etc (if everyone is motivated to fully participate.
For build automation and continuous integration take a look at TeamCity from Jetbrains.
It has a lot of features and is really a breeze to set up and use.
If you use Visual Studio 2005/2008 it will build your solution directly without the need for extra scripts (if a build is all you want.)
It will also execute your unit tests and gather stats on build success, unit test execution times, etc, etc.
Best of all: The Pro edition is free for teams with up to 20 users and 3 build agents.
source control: cvs
build gnu make
cron job that calls bash scripts
bugzilla