I currently have a java library in subversion under package:
com.company.product.foo.*
Unfortunately, I have to refactor this into:
com.othercompany.bar.*
That'd be fine as a one-shot. But this has to be performed only on a specific branch. The problem is then to merge changes from trunk to the branch with totally different names.
The only solution I see would be to create a patch file, run some search & replace and then apply it on the branch.
Is there any better option ?
The first most obvious solution is to not use either company name as the package, but rather a trademarked name, or a neutral domain name that would be used going forward.
If that isn't possible (as in the customer doesn't want the two code bases to be seen as connected) the next most obvious solution is to use a source control system that is more friendly to the concept. Git might have better options, or perforce.
If you have to stick with subversion, then I would have it in source control under a neutral package name and then have the build process that checks out the code, moves it, renames the packages, and compiles, once for each company. Or If your IDE can understand it use a Java pre-processor.
Of course, that last one only works if both customers stay on the same base, but if not then the customer would have its own branch, and the build process could copy the code only as appropriate for the correct branch.
I can't see any really good solutions, but would it be an option to just create subclasses under the new package name?
Then the patches could be applied to the super classes, and the sub classes would never actually contain anything.
A good IDE with refactoring capability will be able to handle this in an instant. Once you make the change, commit it to Subversion. One of its strengths is that it treats directories and files the same way, so you can keep the history as you rename packages.
Sounds like you'd want to create a tag for the original; check out and refactor the trunk; commit the changes. Voila - old and new, with the refactored packages on the trunk where they belong.
Perhaps I'm misunderstanding your question, but I don't think you should make the change directly inside Subversion. Change the code and let Subversion do its job.
Related
I am writing here because of desperation caused by refactoring a GWT project.
My first try:
After I read all the praises of the refactoring tool from Eclipse ( I am using it as IDE) I simply right clicked on a module ( what a fool i was ) and use the refactoring option. My project became unusable.
First Conclusion:
Found out that I need to start with the classes and then go up and refactor a module at a time.
Second try:
Refactored some classes, worked fine until I messed something related to a ui.xml file. Project unusable!
Second Conclusion:
Be careful at the ui.xml files!
Third try:
Went pretty well, but I got ahead of myself and tried to remove some comments or replace class names in comments. Predictable result : project unusable!
Third Conclusion:
Try again!
Forth try:
Fail!
Fifth try:
Fail!
You get the picture.
Can someone experienced with GWT please offer some guidelines about the mystical realm of refactoring?
GWT has some rules based on naming conventions (e.g. the two interfaces for GWT-RPC, the *.ui.xml files and the class that uses them through UiBinder, the files related to ClientBundle or ImageBundle methods, the *.properties files for I18N), so failing to respect them when renaming/moving one class/file will break it.
GWT also sometimes references classes by name in non-Java files (#eval in the *.css of a CssResource, or in *.ui.xml files), non-Java portions of classes (JSNI) or string literals (e.g. in #ProxyForName and #ServiceName). Failing to update them all will break the build.
Because a tool makes it easy to refactor does not mean you should let it do it blindly: it's just a tool, you have to understand what it does and double-check it (hint: check the box in Eclipse that forces a preview before applying the refactoring) so it doesn't do too much or too few.
I was asked to do a name change and to maintain consistency, I refactored several classes to change their names. Now, the boss has decided he's a bit nervous about all this and just wants me to forget the name change altogether. But, I've already refactored my code, although I haven't committed it to CVS. Is there any way to get Eclipse to reverse the refactoring so I don't have to just grab the last committed code? I can't find a way to get Eclipse and CVS to work together to pull back the original code with the original names.
Thanks.
Option 1:
Refactor to previous name.
Perform CVS update to get CVS to see files as not changed.
This may not be 100% perfect due to formatting differences, but it should be close.
Option 2:
Use this if you don't have other outstanding changes besides refactoring.
Right-click on the project and select Replace With -> Latest From [whatever]...
I know that there is the option to have links to source code under your src directory instead of having the source code files directly in your Eclipse project.
When is this case i.e. links for source code is best used?
I always found it more convenient to have the source code inside the Eclipse project
I can think of two possible use cases for this.
The first would be if you want to keep your source and IDE meta-data separate. For example it may be that some developers use Eclipse and some IntelliJ. In this case you would probably only want the source of the project to be stored in SCM, as otherwise, one set of developers are going to have to remove meta-data before importing the project. If they just link to the source, they can maintain there own meta-data for there IDE. Obviously this isn't an issue if everyone uses the same IDE.
The second use case would be dependencies. Say for example your working on two different projects A and B where A depends on B. If your not using a dependency management tool or willing to build and import the Jar from B to A each time you modify it, you could link to the source in B instead.
I'm sure there are plenty of other use cases floating around.
In addition to what Kingamajick mentions, you could have a structure that causes overly long path names.
Windows can only handle so much (256 characters? in older versions), and a deep package structure easily breaks that limit.
So, having your classes in a shallow directory near the top allows you to have your workspaces deeper down, and still leaves some room to wiggle.
Other scenarios; You have source code which is common for several OS:es, but the Eclipse projects are specific for each OS.
You can also create a form of linked resources that are relative to an environment variable. I've used that for situations where the version control system (ClearCase) adds user-specific catalognames.
I have two Android apps that are identical except for the package name. This question has been asked before, and the recommendation was to refactor the package name as required, but I do not regard this as satisfactory. To my mind putting all the code in a source library would be preferable, but is there a better solution?
Putting the shared code in a Library Project is the recommended approach. See http://developer.android.com/guide/developing/projects/projects-eclipse.html#SettingUpLibraryProject
I take it the question is "How to I build both apps without duplication?" An easy answer: have your build system perform the duplication and package alteration for you. And one way to accomplish this even if you're used to letting Eclipse or ant handle everything in ways opaque to you:
make a temporary copy of your entire repository, with the original building only one of your apps.
make all the changes to the copy that will cause it to build your second app.
create a single .patch that expresses these changes.
have your build system perform step #1, apply the patch from step #3, and then reinvoke itself in the copy. "have your build system" means, write a script, add a target to a makefile (even if you normally avoid makefiles), add a target to ant, extend Eclipse, whatever.
I've read the syntax conventions for naming Java packages, and I know the general rule of thumb, but what if you've just started building your application, you haven't chosen a license, and it is a personal project? It doesn't make sense to throw in "com.mycompany" or "org.myorganization" if that is not the case. Does anyone have suggestions for this?
Many Java books and online examples just use the name of the book or project, i.e., ejb3inaction.* or tutorial.*.
I usually just go with something like lastname.firstname.<other packages>. The package name should just be unique, and the combination of your last name and first name is probably unique enough (if you have a common name, throw in a middle initial or a middle name or something like that).
Perhaps org.{myname} ?
I don't think it particularly matters for personal projects. In fact I've seen commercial (in-house) projects flout this rule and simply call their packages {servicename} or similar (which I don't particularly like). The packaging rules are designed to prevent name clahes when sharing code cross-enterprise (or organisation) and consequently for personal projects you can use most anything.
Java packages are just for namespacing. Call it whatever you want! Think of something that will be useful to you later on when you want to remember what this code was supposed to do.
how about org.{projectname}? Think about some open-source projects (e.g. org.hibernate, org.springframework and org.junit) ... did they start this way because it was the name of the website, or the name of the project itself?
Besides, re-factoring is so trivial these days, just name it whatever you want.
What about name.yourname.myproject or net.sf.myproject or com.googlecode.myproject or simply myproject.
As long as you don't make your code public, it's not that important actually (and you can easily refactor it later before releasing your code if you need to). Once people start using your code, it's another story...
In the case you might also think about sharing the project (making it an open-source project), to open an project entry, in that case you can use something like 'net.sf.{project-name}.*', be careful here, that the project-name, must be the unix name, of the project (at least then you follow the rules correctly :)
SourceForge
Java Net
Google Code
Launchpad
JavaForge
Tigris.org
I generally use nl.myname.myapp for all personal projects. There is no rule against open sourcing something that uses your personal name. If you decide to make the project bigger and create a web site for it you can always rename the packages if you really want to.