I have a large Flash Builder project that is part of a much larger (.net) solution. I typically have, for the entire project, a forward dev branch going, as well one or more bug fix branches. What is the best way to set this up in Flash Builder, given that Flash Builder does NOT want to import an new project (bug fix branch) that has the same name as an existing (forward dev branch) project?
The best way is understand the workspace limitations. Eclipse doesn't accept projects with the same name, is an old problem. I could say you, isn't only eclipse, but a lot IDEs have such problem and bugs about it.
We want a create a project, production, what is the current stable version, at least one bug test and the next project version. Then, in this Eclipse case, you should name it to something like ProjectNameProd, ProjectNameBugFix and ProjectNameNextVersion. It's also good for browser files by path, as you have the folder saying what is inside.
You can put all in one SVN or GIT repo, or create one repository for each one of these contents. Then, configure the Eclipse/Flash Builder to use SVN, follow this well explained.
Another, not well, approach is set one project and all your targets but it is really a mess to organize and keep things separated.
Hope help you.
Related
I am working with a big project on my IDEA with many modules. I would like to compare files and directories in the project view. Scrolling each time just to select the files for comparison is tedious. I am not using scroll from source so what I wanted to have is two views of the project, each one is scrolled to different files.
Is there a way to achieve that? Or any other alternative?
The closest you can get is the favourites view where you can drop individual files into a list and then compare them without having to scroll around the project view. Unfortunately that is only any use if you are comparing the same sets of files each time.
Unfortunately there is no out of the box way to do that, IDEA can run multiple instances, each with a different project, but switching is kind of painful.
One workaround is to import multiple maven projects as a modules of one project as described in this question.
There is an issue for that feature in the JetBrains issue tracker, it is interesting to read the conversation history there. Currently it seems JetBrains do not plan to implement this feature anywhere in the future.
...it makes no sense in IDEA. Unlike other platform-based IDEs, IDEA
supports multi-module projects, and all the contents displayed in a
single frame are modules of a single project. Introducing an extra
level of hierarchy above that would be unnecessary and extremely
confusing.
...
We don't have any plans to provide any other solution for this. The
1:1 correspondence between projects and frames is essential to the
internal design of IntelliJ IDEA: by definition, a project is the set
of code opened in a single frame. There is no way to change this
without rewriting the whole IDE, which we don't plan to do.
There was such view in intelliJ called Commander. Since last versions it's not shipped together with intelliJ, but you can install it as a plugin.
I think it will be helpful for your case.
Moving to intellij i'm trying to understand properly the logic behind the its project structure. I come from eclipse. After reading for a while i understood the relation between workspace and project, then between project and modules. However something that is puzzling me is the logic of the default project configuration in Intellij. Indeed, when you create a project there is an initial module which to a certain extend is equivalent to the Project itself. To be more precise, the initial module folder is the Project folder. This is kind of confusing to me. Then when you add more module they are sub-module of that module.
My first question is what is the rationale of making this first module equivalent to the project folder ?
Following this, i would further ask, what the point of having modules as sub-module of others.
In eclipse i use to have simply different project (i.e. module) independent from each other and adding the dependency as necessary. So how does the Idea solution makes it better, if not what is the rational here ?
I saw that one can start an empty project and then add modules to it. However in that case, the modules added are added as subfolder of the Project and therefore there is no initial module equivalent to the Project folder ? So why this difference and what is the rationale behind it ?
What would be the better approach, the first or second ?
Would it be ok to have this first initial module with no src or test folder but just with the proper facet so as to spread it to the sub-module?
I would appreciate if someone could explain a bit the rational of all of it ?
I will move to SBT soon (i.e. maven structure which I suppose inspired all modern IDE project Structure) if one want to explain within that context fine, nevertheless i want to understand the rationale in intelliJ first.
Many thanks,
-M-
PS: What i'm looking for is some advise for some multi-module project structure in Intellij as i'm moving my eclipse workspaces to it.
I think that it's not uncommon for projects to be relatively small, so they don't need fancy modules with dependency management etc. In that case, I find the default project created by IntelliJ to fit perfectly my needs: no need to add submodules, everything is directly in the parent project, it reduces the structure to its bare minimum.
On the other hand, big projects with submodules will likely resemble the structure of a Maven multimodule project (perhaps SBT too, but I don't know this tool at all). You have a parent root which acts as a container for submodules. The parent project may also store configuration (a default SDK, a language level etc. that will be inherited by the submodules). The actual code will be contained in the submodules.
Regarding your questions, it all depends on the kind of project you are developing. For a small codebase, you could keep a simple project with no submodule. For bigger codebases, you can either create modules manually, or import an existing Maven/SBT/whatever project, which will automatically create modules reflecting the imported structure.
I have case as follows and don't know if there is any conveninet solution:
I wrote some set of sources and put them in into a package.
Next, I refactored it deeply for performance reasons.
Now, I have new version which contains at least one bug, that I have to find.
I would like to have both version of my package in one project and easily switch between them
when I compile and run test application.
Of course I can compile both of them and choose in runtime because of names conflicts.
Is it any smart way to solve this?
You are looking for a version control system (which is supported through intellij IDEA).
Try git, they have good support in IDEA.
http://www.jetbrains.com/idea/webhelp/using-git-integration.html
http://www.jetbrains.com/idea/features/version_control.html
Here is a good link for git / vcs tutorials.
http://sixrevisions.com/resources/git-tutorials-beginners/
I'm working on Eclipse RCP, of which i explored few concepts required for my project, I knew how to export RCP product(which is portable).
My development approach was, for each Java File change I'm deleting
the previously exported product and exporting it again. I think my
approach is dumb, there might be better ways.
For a fix in java file, each time exporting is time consuming. As a
workaround I thought of replacing the class file generated in bin to
my plugin jar, but for my java file, there are multiple class files
generated with classname$1.class, etc. It was difficult to replace
all these class files into my plugin.jar.
What is the better practice in such situation. What do expert RCP developers do, for a java change to be reflected to a product exported version without deleting product or creating new. Isn't there any hot-deployment kinda thing, as an analogy Jsp change into Application server is a hot deployment.
Looking forward for suggestions.
Day to day I generally just run my product in the debugger - code changes are reflected immediately.
However you can use p2 to update a previously exported product - although this requires exporting a new version of the product first to generate a compatible p2 repository. An alternative is to push your changes to a build server and have it build the new product and p2 repository for you. I find Tycho is a good choice to help automate my builds.
There are often conflicts in the Xcode project file (Project.xcodeproj/project.pbxproj) when merging branches (I'm using git). Sometimes it's easy, but at times I end up with a corrupt project file and have to revert. In the worst case I have to fix up the project file manually in a second commit (which can be squashed with the previous) by dragging in files etc.
Does anyone have tips for how to handle merge conflicts in big and complex files like the Xcode project file?
EDIT-- Some related questions:
Git and pbxproj
Should I merge .pbxproj files with git using merge=union?
RESOURCES:
http://www.alphaworks.ibm.com/tech/xmldiffmerge
http://www2.informatik.hu-berlin.de/~obecker/XSLT/#merge
http://tdm.berlios.de/3dm/doc/thesis.pdf
http://www.cs.hut.fi/~ctl/3dm/
http://el4j.svn.sourceforge.net/viewvc/el4j/trunk/el4j/framework/modules/xml_merge/
Break your projects up into smaller, more logical libraries/packages. Massive projects are regularly the sign of a bad design, like the object that does way too much or is way too large.
Design for easy rebuilding -- this also helps if you're writing programs which must be built by multiple tools or IDEs. Many of my 'projects' can be reconstructed by adding one directory.
Remove extraneous build phases. Example: I've removed the "Copy Headers" build phase from all projects. Explicitly include the specific files via the include directive.
Use xcconfig files wherever possible. This also reduces the number of changes you must make when updating your builds. xcconfig files define a collection of build settings, and support #include. Of course, you then delete the (majority of) user defined settings from each project and target when you define the xcconfig to use.
For target dependencies: create targets which perform logical operations, rather than physical operations. This is usually a shell script target or aggregate target. For example: "build dependencies", "run all unit tests", "build all", "clean all". then you do not have to maintain every dependency change every step of a way - it's like using references.
Define a common "Source Tree" for your code, and a second for 3rd party sources.
There are external build tools available. This may be an option for you (at least, for some of your targets).
At this point, a xcodeproj will be much simpler. It will require fewer changes, and be very easy to reconstruct. You can go much further with these concepts to further reduce the complexity of your projects and builds.
You might want to try https://github.com/simonwagner/mergepbx/
It is a script that will help you to merge Xcode project files correctly. Note that it is still alpha.
Disclaimer: I am the author of mergepbx.
The best way I have found is to instruct Git to treat the .pbxproj file as a binary. This prevents messy merges.
Add this to your .gitatributes file:
*.pbxproj -crlf -diff -merge
To compare two Xcode projects open open FileMerge (open xcode and select Xcode (from the manu pane) --> Open developer tools --> FileMerge).
now click "left" button and open xcode project main directory.
click "right" button and open xcode project main directory to compare.
Now click "merge" button!
Thats it!
Another option to consider which may help to reduce the number of times you experience the problem. To explain, I'll call the branch that team members' branches come from the "develop" branch.
Have a convention in your team that when the project file is modified, the changes (along with any other changes required to ensure the build integrity) are committed in a separate commit. That commit is then cherry picked onto the develop branch. Other team members who plan to modify the project file in their branch can then either cherry pick into their branch or rebase their branch on the latest develop. This approach requires communication across the team and some discipline. As I said, it won't always be possible; on some projects it might help a lot and on some projects it might not.