I need an advice on the code organisation and the tests sharing.
Let me start with describing the situation: we have an architecture where every separate team develops its own unique business component and their codebases don't really interfere with each other with each other. These are Node.js projects though, but the technologies behind them don't really matter.
One of the teams decided to create the gatling for load testing of its application and created a small, but very useful though project. And it worked just fine, so many other teams decided to adopt this project for their own purposes, slightly changing scenarios, but leaving the same simulation code setup etc. Not familiar with java/scala/maven etc... they just copied the whole project into the subfolder of the npm project.
Of course this makes it impossible for the centralised “core” changes and any other maintenance.
So my question is... what would be the best practice, the ideal way to organise the code in such manner, that our javascript developers ideally would only have to create couple of scenario Scala (or maybe even something else) files in some folder in their project and then just use one or two commands so that it would automatically pull common code from private repository and run the tests.
What I'm thinking about so far:
Creating an archetype with the testing codebase and then running “archetype:generate clean install gatling:execute” etc...
But this will do the same thing again. Creating the whole copy of the project in a subdirectory of another...
Thanks everyone!
I started to work with a group of five new programmers on a large project. I'm looking for the best way to share the source code between all the members. Each person is modifying different parts but all parts are related. I'm looking for a platform or way that when I change any parts of code they can see it on-line or as soon as possible.
Currently we conflicted with each other. For instance I worked on the parts of the source code and when I finish my job and I went back to our subversion repository which is google code to upload the new version. Then I realize someone else has been edited the code! What can I do in this situation?
We are using netbeans and everyone is working far away from each other so we can not have a face to face meeting.
You write about your subversion repository: well, that's good, because version control software is exactly what you need.
Conflicts can appear when people work on same parts of the code, but usually this doesn't happen too often. If it does, you should talk with your team members and set up a policy to update their local working copies more often. Another idea would be to set up subversion to send out e-mail notifications whenever someone commits changes.
When a conflict appears, the one who updates his local working copy has to resolve the conflict. Resolving doesn't mean to overwrite other people's work but to adjust local changes so that they work well together with the code which has already been committed to the repository by someone else.
If a lot of people are working on the same classes Subversion does a poor job of merging and as a result conflicts occur all too frequently. When conflicts do occur, the only solution is to resolve them - most IDEs have tools for this, as does Tortoise.
There's a few things you can do as a team to minimize conflicts:
change the minimum amount of code (avoiding formatting changes)
check in small changes
check in often
sync often
This does mean you have to be careful with your changes, so like everything in development there's trade-offs.
An alternative is switch to a distributed version control such at Git. DVCS is based on the need to merge and so do a far better job of it.
I am working on my bachelor thesis (this is my first research project) and trying to evaluate different possibilites to monitor a developers work during a day, aggregate it and illustrate it later. For this purpose, I defined some metrics, I want to measure (they might change over time and there might come more).
My questions are related to the monitors. To start, I have decided to monitor the developers work (only) within Eclipse (and add a TFS implementation later):
Work Items: I want to know how many work items the developer solved, edited and created. If possible, I want to access the data from MyLin, because multiple different task/bug-trackers can be used (Bugzilla, Mantis, etc.). Unfortunately, I am not sure, if this is possible somehow?
IDE-stuff: (To start), I want to count the number of selects and edits in the code and probably also the number of clicks a developer made within the IDE. I read, that I can create listeners on Eclipse and get the data. Is this right and does anyone know a nice tutorial on that topic?
Source Code Management: To track a developers work, I need to get the developers source code changes (commits). For SVN, GIT and CVS, there are multiple APIs, which I may access with Java or also via webrequests. But before I start that, I wanted to ask you, if someone knows a plug-in or something where I can access the commits from different version control systems? What is the easiest way to do something like that?
I also have a couple of other things, I am going to measure... My aim is to aggregate the data within an Eclipse plugin and then send it the server for the visualisation.
I am not necessarily looking for fully implemented solutions, but more for hints, tutorials, tips, your opinions and probably also questions and propositions!
thank you!
You can try out with rabbit plugins for eclipse to track the time spent on it. It has different trackers to record the statistics about different commands executed, duration of the perspective or views used, time spent on editors etc.. And this plugins has a view to see all the statistics collected. have a look at the following link:
http://code.google.com/p/rabbit-eclipse/
Some of the metrics you want are produced by Hudson/Jenkins plugins as a starting point you could look at how those plugins produce those metrics. Same applies for the Eclipse metrics find existing plugins which manipulate or consume some of the metrics you want and use that as a starting point - since most of them are OpenSource.
I am using Eclipse + Subversion for Android development. I used to create a free version of my apps with ads, and another one payed without them, so I kept them in two separate branches on subversion.
The problem I have found is that as these are two different app for Google Play and other markets, they must have different package names. So I have, for example:
com.package.game
com.package.gamefree
When I do some changes on the free version of the game and want to merge them with subversion into the payed branch, I found myself in a trouble because source files for the free game are below com/package/gamefree and for payed under com/package/game
I ended up doing a "manual" merge, making a diff of source file by source file, but I also have to check those files that have been added into another directories and those that has been deleted. A waste of time.
So, is there any manner to make subversion know that com/package/game in one branch is the "same" directory than com/package/gamefree in the other?
Thanks a lot in advance,
I'm guessing here, but maybe you could have the free app on the trunk in the com.package.gamefree package.
On the branch you could have the other importing the one developed on the trunk as a dependency lib, and wrap it around with launcher class which is packaged under com.package.game, adding the license stuff...
This way you'll only have to modify the code once, and build 2 apps.
After googling a bit in deep, I found that my better chances was just two:
Using ANT in anny manner that automatizes the switch between free and payment versions at building time.
Using an Android Library project shared between two versions.
I have seen that most of the people using ANT were doing it some time ago by the lack of another option, but since there is Android Library projects on Eclipse/ADT this is the preferred way for this kind of things. Even in the development docs of Android, says:
http://developer.android.com/tools/projects/projects-eclipse.html#SettingUpLibraryProject
If you are creating an application that exists in both free and paid versions. You move the part of the application that is common to both versions into a library project. The two dependent projects, with their different package names, will reference the library project and provide only the difference between the two application versions.
This seems to be the best way for me also because I have never used ANT and given the library option there is no reason for learning it.
So I have done that way: my project is splited now into MyGameCore that is the library project with all common files to both MyGameFree and MyGamePay projects, that now just have the minimal classes needed to have a different main package name so Google Play knows they are different applications, plus the raw assets folder that according to Google Docs cannot be moved to the library. Anyway these are binary files that I simply copy from one version to another when they are changed, that is not very often.
So from now on, most of the time I just need to work on the MyGameCore project and the changes done have inmediate effect on both MyGameFree and MyGamePay projects without needing to merge branches.
This will save me A LOT of time and I will use it on my further projects from the very first code line.
I am simply wondering whether it is best to put all of my Eclipse projects into one workspace, or do a 1 workspace per 1 project. I am just a solo developer, for hobby more or less, but the apps I create do actually have production versions that are running on rather frequent cron jobs, so its almost like an amateur production environment.
The only problems I have noticed so far is for exporting JARs, I have the potential to include source files from other projects which seems like it could get messy.
I used to keep separate workspaces, but got tired of the difficulty in keeping settings consistent between them. Now what I do is create working sets for different projects and change the current window working set to filter out everything except what I want to work on. So far this has worked fine for me.
Since each project can have multiple working sets, and the window working set can be any combination of working sets, it's quite easy to only see what you want at any given time this way.
I create Eclipse workspaces around products, because for me, a product can have multiple projects within them, for example like having core libraries compiled into one jar in a project, this is used by other projects.
In terms of production environment, you would want products running in different directory structures, much cleaner that way. And in eclipse the workspace creates a directory with workspace name. So, create workspaces based on product/app rather than one or more projects within them.
Not only do I keep separate workspaces for each project but I keep separate copies of Eclipse also. This is because I typically have to put projects on ice for long periods and return to them (with little notice) and they absolutely must build. I can't take the chance that some plugin I've installed for my latest project (maven based) will interfere with the build process of one of the legacy systems (ant based). For the record I do document the eclipse environment for those legacy systems but I don't have time to mess with eclipse when patching a production bug.
If the projects are interrelated (i.e. have dependencies on each other) then it quite often makes sense to have them in the same workspace. Also, if you are working on several projects to solve a related problem, the same applies.
You will waste a lot of time changing workspaces unnecessarily otherwise, especially when the IDE will immediately show you the impact the changes in one project has on another.
I would use separate workspaces for different "groups" of projects. For example you might want to combine your main app project AND the unit testing project together in the same workspace.
Maybe I'm unlucky, but Eclipse often (once a month, say) dies on startup, typically in the "Initializing Java Tooling" stage. The recommended solution seems to be to create a new workspace. If you have all your projects in one workspace, this can be a pain. I think smaller workspaces may mean the crash is less likely to occur.
As the Preferences are workspace-specific, I tend to have a enormous workspace open - I'm too lazy to sync some settings between workspaces (e.g. repositories...).
On the other having too much projects open in a single workspace can slow down Eclipse - so the least I have to do is to close projects I'm not working with. I manage a lot of relative short-term projects (at most one month) in Eclipse, that reside in the same workspace (and in most cases the same repository), so this setup gives me a bigger flexibility.
If you have several, interrelated projects, then keep them in the same workspace. If you can identify group of projects, that are always used together, but the groups are used independently, then put such project sets into different workspaces. In that case that should be the logical structure.
We have a situation where we have several projects, some on branches, which frankly is too impractical to keep in the same workspace - and working sets are a joke. Unfortunately. Also having projects open you do not use, may accidentially be chosen from completion menues, etc. Error prone.
The really nifty feature for us, was when Team -> Project Sets were added (in Eclipse 3.3 I believe) as this allowed us to have a single file describing the many projects making up the whole application, which can be imported in Eclipse with Team->Import. Need a given project? Check it out of CVS, locate the projectSet.psf file inside of it, and import THAT.
This has proven to work well for us.
I have one workspace per Type of project.
Ex: Plain Java, Web Application, Python etc.
The reason being I can share libraries that are similar without copying or pointing to them.
Also, I close the unrelated projects from eclipse to avoid clutter.
I have all my projects in single workspace and use working sets to manage them.
Up to you! I've always found keeping the related versions of different projects, which belong to the same release in a given workspace a cleaner approach. That way, I could switch between workspaces whenever I need to refer to something in a separate release, and switch back to the current release workspace.
It also saves me from the hassle of checking-out, or browsing the repository.
You may also want to keep in mind that you can open multiple instances of eclipse as long as they are looking at different workspaces. Not sure if that is important to you, but I like doing that from time to time.
I like to use several decoupled workspaces (which differ depending on the type of project), which import projects from various locations. Easy to move things around, without creating a ton of similar workspaces. Plays nice with my SCM too.
Depends on how many projects do you work?If you work on many projects, I'd use same workspace, because if you use several you can easily forget what is where and that can be frustrating to say at least. However I always use different workspace for different programming languages that way its less confusing, when you're in JAVA workspace you think JAVA :D