(my apologies for the non-specific wording of the question title, and for liberal use of öpen source" when I actually mean "project setup at SourceForge")
We have recently open sourced a 3D modeler we'd been selling for a couple of years, with the main goal of keeping the application alive. We setup shop at SourceForge.net, and are now working towards a process resulting in a steady flow of binary releases. So far, everything is swell.
However, besides the main application, we had also developed a couple of plugins (mainly for different import/export formats). Currently, these are still closed source, but we would like to open those up as well (3rd party plugin developers can take care of their own or donate and open the source). The question really is, should our plugins be hosted as a project on their own or not?
The options I see are:
Add the plugin sources into a subfolder of the SVN sources
Create a separate project for the set of plugins
Create a seperate project for each individual plugin
Which setup is the most practical and/or common, and how should I deal with the binaries?
When the application was still closed and commercial, it was kinda important that the plugin binaries could be updated seperately fom the main application, but now that everything is open and updated frequently, that's not so much of a big deal anymore. Also I'm not sure I want to bother contributing developers with a whole bunch of plugin sources they care nothing about as part of the main project.
Add the plugin sources into a subfolder of the SVN sources
I think that is a good idea if you don't have too many plugins. You could create a folder structure as shown at the end of my answer in order to manage plugins independently. But in this case you won't have fine control over SVN access.
The advantage is that you only have to maintain one project website (if you create one at all).
Create a separate project for the set of plugins
That's what Notepad++ does, for example. Their plugins are hosted on a separate SourceForge project. Having one download page full of plugins and another download page full of binary releases of your software improves readability. But don't forget to mention on the project web page that there's a separate plugin project.
It also has the advantage that you can manage the project web sites independently. For instance, you could put other users in charge of caring about the plugin site (if you find somebody who wants to maintain them).
Create a seperate project for each individual plugin
Not a good idea, maintenance will be harder this way, as you'll have multiple projects, repositories and project websites.
But it has an advantage though: You can be more fine-grained in granting people access to developing the plugins. For example, users A and B are allowed to work on plugin X, but not on plugin Y. With separate SF projects, this is easy to achieve. Same applies to the project web sites, of course.
So, as a conclusion, I would say that the more you care about SVN access rights and the more plugins you have, the more it makes sense to create one or more separate projects for your plugins.
Example SVN structure from #1:
/modeler
/trunk
/branches
/tags
/modeler-plugins
/plugin-x
/trunk
/branches
/tags
/plugin-y
/trunk
/branches
/tags
Related
Web Developers!
How do you go about organizing your Github projects for your front-end and back-end?
For example, I have a python script that generates a JSON file that the front end JavaScript consumes to generate data on the pages.
Would you create one repository with two directories labeled front-end and back-end?
Or would you make two different repositories?
I'm interested in what developers do in the wild. Because up until now I found myself having a complete clone of my website in a directory on my desktop PC, and just pushing individual files via SFTP from there.
I'm getting to the point where I have enough *.old files that I want to implement version control so I can view much older states of code with Metadata like date and user that edited it.
The answer is yes. Make two different github projects.
Just Like Michael W has stated, "[...] this is highly opinionated". What I find to be the most common approach is to implement a single github project when still in development and especially when you're developing on your own. This is useful because you don't have to switch up between repositories and/or branches, which saves time.
Another common approach is to split them up. However this approach is only possible when both projects can run independent from one and other. In your case it's important to split the project logically. If the python project only generates JSON files and places them on a server location, then I would place that into it's own github project, because the main purpose is to generate files, so the python application can run on a server seperate from the frontend. If the webapp only consumes the JSON files through maybe a rest call or through a connection to a FTP, then also that can be placed within it's own project.
I work for a company that develops many websites to be used internally but many have parts that are public facing. It is important that all our sites look the same. In moving to dotnet core we found that we are no longer able to use a virtual directory to host the Layout page for our site.
We were storing our Layout page on a file share and referencing it in our projects with a virtual directory. This way if we needed to change the information in the footer, header, or some style/js we could upload a single change to the Layout page and that change would take place on all our sites.
I've tried researching any possible ways and the only thing I can come up with is a custom middleware that downloads the layout page from the file share and updates the current layout page if it is out of date.
.NET Core gives you the capability of creating Razor libraries. This would be a separate project where you can have shared views and reference it to the rest of your projects. You can find a simple implementation here.
You can choose one of these two options to do this.
Reference this project in each solution. Since your solutions directly reference the razor library, any change that is made in the common library will be reflected in every solution without the need of repacking and publish.
use dotnet pack to create a nuget in a shared location. While this option will require you to repack and publish each time, in some cases it would be a more organized solution. You can have a version setup. This means that when you update the shared razor project you will define a new version number. You can update this on each one of your solutions. This reduces the risk of a project breaking. Let's say you have 5 projects and 2 of them are not compatible with the latest update. In this case, you can update the 3 right away. The remaining 2 can be updated when you can spend time updating these projects to match the new requirements.
I have a project that uses both PHP and Python, and I would like to use JetBrains IDEs (in this case PhpStorm and PyCharm) to work with both languages.
However when I open the project using both IDEs concurrently I get a pop up whenever I switch from one to the other, as the newly focused IDE detects metadata that has been written to the project directory by the other IDE. I imagine this would be a problem between other combinations of JetBrains IDEs as well (hence the use of the generic jetbrains tag).
I have a work around (I will post in an answer for others to view), but it is somewhat awkward to set up, and I may well be working with other projects that use the same combination of languages.
Is there an easier solution?
My current workaround:
Create a new directory separate to the main project directory - using the language specific IDE for the second-most used language in the project, open the new directory as a project, and using the options in Settings > Project > Project Structure, add the main project directory as a separate content root.
Whenever needing to work on the parts of the project written in the secondary language, you can now open the new directory instead; this keeps metadata for both IDEs separate.
A workaround which allows for two IDE's to share the same directory without IDE settings conflicts.
JetBrains software allows you to store project settings as either a file based project (*.iml), or a directory based project (.idea).
To choose file or directory based projects, change the file storage type when opening a project.
Note: Directory based projects are preferred to file based projects, as they allow for versioning of shared settings. Support for file based projects is deprecated and may be removed.
We have some JSP code to run in our pages.
There is a UI designer who will constantly update the UI but does not have Tomcat server. We prefer he doesn't because he isn't a programmer.
However, it is getting annoying to have to cut and paste the JSP related code each time he updates the UI.
Is there anyway to handle this issue? We prefer to keep the same files, but still have it so he can see his UI work without worrying about the JSP and when he checks in the new files, we don't have to cut and paste our JSP related code.
One example of such code, is that there are certain navigation menu items which are displayed depending on the user.
We are using Tomcat authentication. We could I suppose use AJAX to obtain the user information, but is that less secure? Everything else in the application is AJAX.
The problem here is that this person is not working with the team. Rather, he's creating work for them... and it goes both ways. Read on.
I both do and manage front end development. If this UI person was on my team, I would force him to set up a Tomcat server. He just needs to learn some things.
In effect, when implemented properly, JSP is not much different from any other server-side markup language for views, such as Rails + ERB, PHP, .NET etc... even Javascript templating engines (mustache, handlebars, etc.). The same condition checks, for-loops, auth checks - all basic view-layer logic that is needed is available and usable.
If he's on a Java project / team, he needs to learn the Java front-end. It's that simple.
His main tasks should be basic, and frankly, he shouldn't even need to install a Java IDE to do them. They are:
Get/push source code + analyze diffs (any source control client)
Build / deploy latest to his local environment (scripts or .bat files)
Work on the running app*
(*) The last part is where things get tricky. If you work directly on the running server and then accidentally run a fresh deploy before copying over your updates, you're screwed. If you use symlinks (which are also available in Windows), there may be files that only appear post-compilation, or locks, or sync issues when getting latest code - all creating problems.
The way I have found that works best is to work on the code repo location (pre-build), and create two scripts:
Build+deploy - stops running server, blows out directories and caches, builds latest, and redploys
Update - Synchronizes the View files and any other necessary directories with the deployment target. You must be sure to disable hot-deploy in the Tomcat config, or you'll get memory leak errors.
That said, and it should be obvious by now: Java is one of the most difficult ecosystems to develop UI's for. The compiled nature and complex environment requirements make development slow and tedious, with significant dependencies on different people or systems to make a decent product.
JSP itself, while capable as described above, is almost always organized badly, with various ways of includes, tagfiles, partials, frameworks - it becomes a UI person's worst nightmare. GSP (from Grails) solves a lot of the organizational issues, but will require flexibility from the dev team. Even then it is not an "ideal" solution.
JSP syntax - JSTL, C:tags, etc. creates even greater headaches. Front-end people who do not program, don't use IDE's and therefore don't have a way of looking up methods, objects, parameters etc. when writing or customizing conditional logic or loops. The dev team can help by pre-writing these out on the page, but any time there are changes or enhancements needed, it requires meetings, conversations, and compromise.
In the long run, you should abstract the Java app from a separate, more flexible, more capable front-end technology stack, using REST / JSON-based services to talk between the two. (Side note: For performance / apps with scale, ensure you are using either a custom protocol or Web Sockets).
My preference is node.js, because front-end developers can stick with the language they will know best: Javascript / JSON. But it could be anything that your particular front-enders are comfortable with and can do design with.
The key is to eliminate bottlenecks on both front-end and back end. Both tracks should be able to develop and iterate quickly, with the RESTFUL API being the key point of collaboration.
Lastly, for those of you who are aspiring front-end developers / designers but only know Java (or some other server-side technology), I CHALLENGE YOU to learn something new. User-facing technologies are in a constant state of change, and more recently that change has accelerated. If you want to have UI-competitive products, you need to invest in technologies that will make them competitive.
I am trying to find the best solution for versioning files on a large scale of websites, network drives, etc... shared among 40+ developers. We have roughly about 22 servers that each contain about 75 DNN websites hosted by PowerDNN. Common software shared among all developers are Adobe CS5 suite so I am not sure if there is something that even integrates into this software that would allow us to version. I am aware of a couple of the ones out there now (visual safe source, CVS, GIT) but not sure if these are the best solution for such a large amount of data. Network drives would contain PSD's, Text documents of site content, etc...
any help is appreciated, thanks
also something i forgot to mention, something that also allows to check in/out files for example a style.css for website 1 on server 1 is checked out then back in and a week later checked out and you are able to compare changes from last checkout and who made those changes
thanks again
Consider git at least if your files are mostly text and not binary (like psds and stuffs). Then you can create separate repositories for separate projects and by doing this you should have no problem with the amount of data that you have.
Visual Sourcesafe and CVS are old (read: bad) and not as flexible and powerful as git.
Check out Team Foundation Server. There are plugins actively being made to integrate TFS with other programs. Some plugins are free and some are paid.
http://www.codeplex.com/
Warning: TFS is massive and the learning curve could get steep.