The company I'm working for is starting up and they changed their name in the process. So we still use the package name com.oldname because we are afraid of breaking the file change history, or the ancestry links between versions, or whatever we could break (I don't think I use the right terms, but you get the concept).
We use: Eclipse, TortoiseSVN, Subversion
I found somewhere that I should do it in many steps to prevent incoherence between content of .svn folders and package names in java files:
First use TortoiseSVN to rename the directory, updating the .svn directories.
Then, manually rename the directory back to the original name.
To finally use Eclipse to rename the packages (refactor) back to the new name, updating the java files.
That seems good to me, but I need to know if the ancestry and history and everything else will still be coherent and working well.
I don't have the keys to that server, that's why I don't hastily backup things and try one or two things. I would like to come up with a good reason not to do it, or a way of doing it which works.
Thank you for your help,
M. Joanis
Package rename test
Procedure:
Create a new package com.oldname.test.renametest.subpackage.
Add a new class under renametest called RenameTest0.java and containing:
class RenameTest0 {
public RenameTest0() {
showMessage();
new RenameTest1();
}
public static void showMessage() {
System.out.println("RenameTest0!");
}
public static void main(String[] args) {
new RenameTest0();
}
}
Add a new class under renametest.subpackage containing:
class RenameTest1 {
public RenameTest1() {
showMessage();
RenameTest0.showMessage();
}
public static void showMessage() {
System.out.println("RenameTest1!");
}
}
Test that RenameTest0 runs fine.
Commit.
Change the messages of both of the classes.
Commit.
Again, change the message of one class and commit (just creating some history).
Apply procedure proposed above (the three steps in the original message) for renaming package renametest to testrename.
Commit.
Test run.
Modify the messages again and test.
Commit.
Try to roll back to the version when both messages have been changed simultaneously the first time.
If everything worked fine to this point, it looks good, no?
Result of test:
Note on step 9: Had to do it in reverse order (Eclipse rename THEN TortoiseSVN rename.), else it was getting complicated, as TSVN create a new folder/package and marks the old one for deletion... So you can't rename for Eclipse unless you put the old package somewhere else in the meantime to prevent losing .svn folders, etc. etc. Didn't look like a good idea to go further with this method. (Note to myself: don't forget to tick the checkbox for recursive package renaming!)
Note on step 14: Worked! We can see previous versions; all we have to do is tell not to break on copy/move and it's ok. Once reverted to a version before the rename, the package names are not back to the good name though, probably that refactoring it again would do it.
End note: I was surprised to have to do the critical steps in reverse order. To do that right in the middle of this first package rename try, I had to roll back some TSVN and manual modifications, casting a little doubt on the repeatable nature of the exact results of this procedure. I will have to do a second test to confirm it's validity. To sum up: it looks good, but needs further testing.
Perhaps it's not practical for your exact needs but TortoiseSVN has a handy feature regarding renames. You could do this:
Use your IDE's refactoring feature to rename stuff.
Launch the "Check for modifications" dialogue from TortoiseSVN.
For each renamed item, you'll see two entries: a missing "source.java" item and an unversioned "target.java" item. Highlight both and choose "Repair move" from the context menu.
Repair moves/renames
Have you considered using the Subclipse plugin? It may solve your problems, according to How do I use Eclipse Refactoring Tools and stay in sync with SVN through Subclipse?
Are you sure keeping history is NOT working if you are using the refactoring method included in eclipse?
With NetNeans I regularly change package names and the underlying 'svn plugin' will silently move the content (which saves history) into the new directory (after that the normal refactoring will happen).
so: Have you tried it from within eclipse if the history is kept with the subversion plugin? (e.g. in a fresh check-out copy to avoid failure)
At least you could use NetBeans to do this one-time task ...
Yes, it will work. You could install the command line version of svn and write a batch file that will do the svn stuff. Automating the eclipse stuff would be a bit more work, and probably not worth it unless you're already familiar with the eclipse API.
Test it with one package before you do everything just to make sure you're doing all the steps right.
You can do this, and it's not that hard - your best bet to get a clean SVN history is to do it in 2 steps (can become one commit) - though for good results I recommend using the CLI client.
Use svn mv to move the folders/packages
Go into Eclipse, or use grep from the CLI to fix the packages in the files to match the new name
Then you can commit as a change-set, and the history at the file level should match.
If you're using Maven or a packaging tool, recommend you run a release before doing something like this - also it's worth cutting a tag immediately before this in case you need to go back to the old structure
I discovered that the subclipse plugin gives the error message " is already under version control" when committing a class that has been moved to a new package (i.e. not under source control yet) and the parent of this package is also new.
When this happens, I can commit the changes using TortoiseSVN. After that I only need to refresh the project in Eclipse.
After moving a class to a new package whose parent is already under source control, subclipse can commit this change without problems.
Instead of renaming the packages you could do this:
create the new package structure in your project. Once done your project should look something like this:
com -
|- myOLDcompname -
| |- feature1 -
| |- classA.java
| |- classB.java
|- myNEWcompname -
|- feature1
add the new folders under version control so svn can track them
move your java classes from old packages to new ones. Eclipse should update all the classes imports and package declarations accordingly. Most importantly because old and new packages are under vcs this step should keep the history of the classes.
when done delete the old folders
commit!
Related
I have a HelloWorld Java app called FitnessTracker that I want to clone as another name, FDE3, leaving the original website in tact. I performed the following steps an attempt to do this. Please tell me where I went wrong and/or what else I need to do.
Change Context Root
Confirm Change Context Root
Still the original "FitnessTracker" name persists and I'm not sure how to get rid of it.
If I was able to successfully clone the FitnessTracker webapp as FDE3, I should be able to access the new site as
http://localhost:8080/FDE3
But I get an invalid resource error. Instead, the site is still accessible as
http://localhost:8080/FitnessTracker
..because of reminants of the old name.
What do I need to change within Spring Tool Suite to get the web app to use only the new name? To minimize chance of corruptying the project, I'd rather do it via the STS GUI over manual modification of any system file.
I see that the following file contains the text "FitnessTracker" but I would rather not modify it manully for fear of breaking. What GUI option controls this?
Search "fitnesstracker" (2 hits in 1 file)
C:\Dev\Workspace\FDE3\.settings\org.eclipse.wst.common.component (2 hits)
Line 2: <wb-module deploy-name="FitnessTracker">
Line 7: <property name="java-output-path" value="/FitnessTracker/target/classes"/>
Sorry for being a noob.
Update:
I'm not sure what I did, maybe just clean, refresh, open/close a million time, dunno, but now when I run the web server from with the Spring IDE the site is coming up using the FDE3 path, however, I am wondering why I see a reference to Fitness in Parens in the project node.
Earlier, it just displayed "FitnessTracker" in parens, now I see a full path to a Test folder...
Update 2:
When I copied the FitnessTracker project as FDE3, I didn't expect that the new FDE3 project would have any ties to FitnessTracker project and I didn't think that the new FD3 project would be in SVN until I added it to SVN, but based on the icons I see below, it looks like it is, (I'm new to SVN, too)
It looks like my issues are related to SVN.
Why is there a tie to the original FT project and why? How should I have clone the FitnessTracker project?
Yes, your issue is indeed related to SVN. Copying an SVN working copy will copy .svn folders inside that and will be pointing to the same URL in the SVN repository. What you have to do is an SVN Export of your FitnessTracker project to FitnessTracke-Ex first in either Tortoise or Subclipse SVN client and then import that project into your STS Eclipse environment. Finally you can copy and rename the FitnessTracke-Ex project FDE2 or FDE3
See this
post on how to Export a working copy
See this post on how to Import an existing project into Eclipse
Error: Could not find or load main class jewelleryerpapplication.GUI.ERPMainMenu
Java Result: 1
Actually i am using Net Beans 7.1 and in that i am continuosly getting the same error but un able to get the solution for that even after installing the latest update for that. The solution which i got from some body that create new project and copy the source and library foldes in that Project from the previous which generate the above error. this solution works for me but i need some simpler solution for this problem.Lot of thanks in advance.
Don't Forget To Give UpVote It If It Helps.
Right click on project node, go to Set configuration, select the main class for your application. Then clean and build.
Even if this doesn't solve your problem, then delete the Netbeans cache by deleting the (index) folder
User\.netbeans\6.9\var\cache\index\
I think that the following is happening:
If this is a third party application, you have not included some jar files on your class path;
Or, (which in my opinion is the most likely) you do not have a method which has this signature: public static void main(String[] args). This method defines the main entry point for your application, not having it might cause that error when you try and run the project. To my knowledge, Netbeans creates a main class with such a method automatically whenever you create a new project. This might be the reason why you are not having this exception when you create a new Project and throw everything in it.
You might be having an issue with Netbeans itself. You can start by either checkin gout this previous SO thread in which a similar (I think) issue is being discussed, or else, as a final resort, you might want to remove Netbeans and all its files, and install an earlier version. You can also try and see if you get the same issue if you use a different IDE such as Eclipse.
the solution is,right click your package in netbeans,go to properties,source now go to the jre option and choose your version,the programme will now run.
I may have a corruption problem in Eclipse run configurations. This happened after I dragged (or copy-pasted, I don't remember) a Java class called MyClass from project1 to project2. Then I deleted project1. When I create a new run configuration the name given is MyClass (1). In other words, it thinks there is already a run configuration called MyClass, so the new one will have to have a number appended. (Edit: There is no existing MyClass run configuration so there is no apparent reason for the appended number. In fact, I deleted all of my run configurations.)
How can I easily clean up meta-data and be able to build again with minimal manual effort?
If there is a meta-data deletion recommendation that gets rid of more than just run configurations, that probably would still be a good solution, if it does not create a lot of manual work to get set up to work again.
Edit: The problem might be caused by the fact that there is a launch configuration named MyClass - project1 visible in the export dialogue. project1 no longer exists, but this remnant lives on, tying up the class name MyClass. I am not sure if there is a difference between a run configuration and a launch configuration.
AFAIK launch configurations are stored on:
${WORKSPACE}/.metadata/.plugins/org.eclipse.debug.core/.launches
Take a look to the existent configurations and remove those that are not interesting to you.
And restart Eclipse
Open Eclipse. Follow Run => Run Configurations. You will see options on the left hand side. Under the Java Applications option, you will see the list of runnable classes (the ones have a main method). These class nodes on that list are right clickable. By right clicking on your running configuration, you will see New, Duplicate and Delete options. You can delete your old running configuration via delete option. To create a new running configuration, right click on Java Applications option and click on New and then configure it.
You could try starting eclipse with the -clean command line option.
On windows the easiest way to do that is to copy your shortcut to eclipse and add the option to the arguments list, then start using the new shortcut.
I am trying to refactor my package using Eclipse
org.sheehan.activity
to
org.sheehan.stocks.activity
For some reason my project just blows up when I do this and R doesn't get regenerated. How can I refactor properly?
UPDATE:
I updated my Android Manifest to reflect the change. R still doesn't get regenerated. Even after a clean. The compiler is complaining about org.sheehan.activity.R
I resolved by:
Android Tools > Rename Package Application
If you renamed properly, all your references across your project should have gotten updated. After doing this, clean your project by going to Project > Clean. This should fix it.
Fixing missing reference to R in eclipse:
Refactor -> Rename`
Build -> Clean
Android Tools -> Fix Project Properties
select the base package of your project in the eclipse package explorer, press F2 (Rename), in the rename dialog: SELECT ALL the checkboxes.:
That should do it
The package name doesn't update in the XML files. Specifically your manifest which needs to know the base package.
For more advanced imports and refactors, literally closing the Eclipse IDE can refresh a cache that causes random errors like "End position lies outside document range" or the "what once worked now doesn't hair puller outter errors."
Signs you should close Eclipse when trying to rename things are:
When you import a project, do some refactoring (like trying to change the package name), then delete the project and try again, you will see immediate R.java errors when you didn't before
When you are importing projects that have manually generated R.java files that have custom imports like "com.ns.proj.R" and don't see the name update in Preview
The box that asks if you want to "Rename subpackages" is checked unexpectedly
the code in the "Preview>>" looks as if it's been complied before instead of black and white code with the proper names replaced
you get XML errors in the manifest activity name like this
android:name="com.ns.proj.CustomCocom.ns.proj.CustomControlse="#android:style/Theme.Light.NoTitleBar"
when it should be
android:name="com.ns.proj.CustomControls"
android:style="Theme.Light.NoTitleBar"
There are too many to name obviously, however this is as important as "keep your eye on the ball" in sports. Something that is so easy to forget, yet things like these apply to other software programs like Dreamweaver (e.g. when you use the Dreamweaver "Put" option instead of FTP dragging with FileZilla and you notice your domain isn't updating your changes online). I called Adobe when I first started as a developer 8 years ago because I knew I wasn't doing anything wrong. They said sometimes the generated files to perform the action get corrupted...in other words, IDE's have bugs too!
In general, close the IDE before you off yourself...it could save your life!
Right click in your Project, go to
Android Tools > Rename Package Application
Sometimes if Project > Clean doesn´t work, so Delete /gen and /bin folders of your project.
Having just wrapped up a GWT-1.5 based project, I'm taking a look at what we'll have to do to migrate to 1.6. I'm very surprised to see that GWT seems to want to write its compiled output to the war directory, where you would normally have items under source control.
What's the reason behind this? Did Google really think this was a good idea? Is there a workaround to keep source code separate from compiler-generated artifacts? Is there some other reason for this that I'm missing?
EDIT:
It's been suggested that I use the -war option to specify an output directory. I wrote some ANT scripts, and have this mostly working. I've had to copy over my static resources such as HTML, JSPs, etc into this directory (I'm using target/war, maven-style). Is that what most people are doing? Or are you just letting GWT write its output into your source-code-controlled war dir, and telling your VCS to ignore the non-version-controlled files? It occurred to me that there might be some benefit to letting GWT write to this dir directly, since then Jetty could automatically notice changes to JSPs, HTML etc, and avoid having to do a copy to make these changes visible.
Use the "-war" option to control where the output goes.
FYI: The Wiki has the design doc which will, hopefully, give you a bit of insight as to what they were thinking.
See also the Release Notes which discuss the new project layout, as well as some things to watch out for with this change.
Salvador Diaz has provided an excellent solution to this.
Yep, look at the -war option which may help.
What I'm doing (which may not be as clean as maven, and I dont use the -war) is I'm putting my entire project dir on SVN, and then ignoring the subdir that holds the js and other compiled bs along with the classes dir. That way I have everything else on source control, including the libs which I wanted. So another team member can just check out the whole project from SVN, compile, and ready to go.