We Keep Coding

How does Spring create the base URL for a Maven project

I'm using Eclipse and I'm learning Spring MVC/Rest/Security.
I created a Maven project from scratch but for some reason unknown to me, it refuses to connect to the database.
Then I used a sample project I have from somewhere, but replaced basically every file in it with the ones of the new project. For some miraculous reason this one DOES work even though it's comparably the same as the first one.
But I do have a problem with it: Whenever I try to run this project, under the "Run on server" window, Eclipse shows me the project as
Configured:
new-project-name(original-project-name)
When it manages to run (because it takes forever to load and it sometimes times out), the url given is:
localhost:8080/original-project-name/
instead of the new name I have given. I have replace the original project name in every file I could think of. In the folders that contain it, in "pom.xml" of course, "pom.properties", ".project", ".classpath" and even a eclipse config file called "org.eclipse.wst.common.component", to no avail.
I cannot find what file is it reading it from and I have checked every single one. I think.

Update properties file
/src/main/resources/application.properties
server.port=8080
server.contextPath=/original-project-name/
/src/main/resources/application.yml
server:
port: 8080
contextPath: /original-project-name/

How do I run a DropWizard / Jersey server locally without having to restart & repack to get asset file updates?

I'm working on the client side of a project that is using DropWizard. Unfortunately what I'm experiencing is that for me to make a change to assets I have to stop the server, package the assets with maven, and then rerun the server or the assets will not be updated.
I tried adding dropwizard-configurable-assets-bundle but I'm still seeing the same behavior. Here's the service after adding it:
Service.java
public void initialize(strap<ServiceConfiguration> strap) {
// Assets
strap.addBundle(new ConfiguredAssetsBundle(
"/dashboard/app/", "/dashboard/", "index.html"
));
// Redirect /dashboard to /dashboard/
strap.addBundle(new RedirectBundle(ImmutableMap.<String, String>builder()
.put("/dashboard", "/dashboard/").build()));
}
I'm currently running mvn package && java -jar target/pack.jar server config.yml. I tried using Eclipse but I was having to restart it manually and it wasn't repackaging for me so it was slowing things down even further.
This whole process is reaaaally slowing me down and I'm hoping it's just my ignorance to the world that is Java.

In my Intellij Idea, i am using JRebel plug-in for this purpose. JRebel also supports Eclipse.

If your assets are packaged under src/main/resources then they should just update automatically with Eclipse without a restart being required, so long as you're running the executable service main() from within the IDE.
You may need to check that your Maven plugin is set to "generate-resources" on changes but that is just the default setting so should be in place already.
What you're describing is definitely possible in Eclipse - I have personal experience of making resource changes (e.g. change and save an HTML asset) and then seeing an immediate update upon doing nothing more than a browser refresh.

Why do I keep getting 'SVN: Working Copy XXXX locked; try performing 'cleanup'?

If you have worked with SVN tools in Eclipse (Subversion, subversive) before, then you are likely familiar with the 'working copy 'XXX' locked..." error.
I found a very useful post with a workaround for this problem at: Working copy XXX locked and cleanup failed in SVN
As great as the workaround is, it is a pain to do it over and over again. Does anyone know why I keep getting this error and what steps I could take to prevent it?
Context: I am creating an Eclipse plugin that involves listening for SVN events, so in testing this plugin, I am constantly opening and closing the workspace. I usually do 1 or 2 commits each time I open the workspace. Every so often the commit will fail and I get the 'working copy locked' error. I would love for this error to not happen anymore, so any advice is appreciated.
Thanks!

Select the project
Right click on the selected Project
Team -> Cleanup
Problem Solved.
Note: The Above steps will work only Eclipse(Indigo package)

Generally a .lock file is created and it decides lock/unlock state checking the existince of this file. I think if you delete this .lock file only, then the problem will go away.

I've had a lot of issues with SVN before and one thing that has definitely caused me problems is modifying files outside of Eclipse or manually deleting folders (which contains the .svn folders), that has probably given me the most trouble.
edit
You should also be careful not to interrupt SVN operations, though sometimes a bug may occur and this could cause the .lock file to not be removed, and hence your error.

Make sure you exactly cleanup what the console says. For example if a subfolder (a package) is locked:
svn: E155004: Commit failed (details follow):
svn: E155004: Working copy 'C:\Users\laura\workspace\tparser\src\de\test\order' locked
svn: E155004: 'C:\Users\laura\workspace\tparser\src\de\test\order' is already locked.
cleanup C:/Users/liparulol/workspace/tparser/src/de/mc/etn/parsers/order
Then you need to cleanup the specified folder and not the whole project. If you are in eclipse right click on the package, not on the project folder and execute the clean up.

After more exploration and testing, it appears that this issue was being caused by debugging the plugin and using breakpoints. SVN/Subclipse apparently didn't like having breakpoints midway through their execution and as a result this lock files were being created. As soon as I started just running the plugin, this issue disappeared.

This will happen when something went wrong in one of your folders in you project.
You need to find out the exact folder that locked and execute svn cleanup under the specific folder.
You can solve this as follows:
run svn commit command to find out which folder went wrong.
change directory to that folder and run svn cleanup. Then it's done.

The following should unlock a locked working copy (tested on svn client version 1.6.11 and elipse version: Mars.2 Release (4.5.2))
step 1: (go to working copy directory) $cd working_copy_dir
step 2: (connect to svn sqlite database) $sqlite3 .svn/wc.db
step 3: (delete all records from table WC_LOCK) sqlite> delete from WC_LOCK;
step 4: (disconnect from sqlite 3 database) sqlite>ctrl + d
step 5: (from eclipse) right click on your working copy, then click Team -> Refresh/Cleanup

I had the same problem using the com.xxx.service.model package.
To fix it, I first made a backup of the code changes in the model package. Then deleted model package and synchronized with the repository. It will show incoming the entire folder/package. Then updated my code.
Finally, paste the old code commit to the SVN Repository. It works fine.

This happened to me when I copied a directory from another subversion project and tried to commit. The soluction was to delete the .svn director inside the directory I wanted to commit.

This type of problem can happen when you delete/move files around - in essence making changes to your directory structure. Subversion only checks for changes made in files already added to subversion, not changes made to the directory structure. Instead of using your OS's copy etc commands rather use svn copy etc. Please see http://svnbook.red-bean.com/en/1.7/svn.tour.cycle.html
Further, upon committing changes svn first stores a "summary" of changes in a todo list. Upon performing the svn operations in this todo list it locks the file to prevent other changes while these svn actions are performed. If the svn action is interrupted midway, say by a crash, the file will remain locked until svn could complete the actions in the todo list. This can be "reactivated" by using the svn cleanup command. Please see http://svnbook.red-bean.com/en/1.7/svn.tour.cleanup.html

Solution:
Step1: Have to remove “lock” file which present under “.svn” hidden file.
Step2: In case if there is no “lock” file then you would see “we.db” you have to open this database and need to delete content alone from the following tables
– lock
– wc_lock
Step3: Clean your project
Step4: Try to commit now.
Step5: Done.

How to rename Java packages without breaking Subversion history?

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!

Programmatically generate an Eclipse project

I use eclipse to work on an application which was originally created independently of eclipse. As such, the application's directory structure is decidedly not eclipse-friendly.
I want to programmatically generate a project for the application. The .project and .classpath files are easy enough to figure out, and I've learned that projects are stored in the workspace under <workspace>/.metadata/.plugins/org.eclipse.core.resources/.projects
Unfortunately, some of the files under here (particularly .location) seem to be encoded in some kind of binary format. On a hunch I tried to deserialize it using ObjectInputStream - no dice. So it doesn't appear to be a serialized java object.
My question is: is there a way to generate these files automatically?
For the curious, the error I get trying to deserialize the .location file is the following:
java.io.StreamCorruptedException: java.io.StreamCorruptedException: invalid stream header: 40B18B81
Update: My goal here is to be able to replace the New Java Project wizard with a command-line script or program. The reason is the application in question is actually a very large J2EE/weblogic application, which I like to break down into a largish (nearly 20) collection of subprojects. Complicating matters, we use clearcase for SCM and create a new branch for every release. This means I need to recreate these projects for every development view (branch) I create. This happens often enough to automate.

You should be able to accomplish this by writing a small Eclipse plugin. You could even extend it out to being a "headless" RCP app, and pass in the command line arguments you need.
The barebones code to create a project is:
IProgressMonitor progressMonitor = new NullProgressMonitor();
IWorkspaceRoot root = ResourcesPlugin.getWorkspace().getRoot();
IProject project = root.getProject("DesiredProjectName");
project.create(progressMonitor);
project.open(progressMonitor);
Just take a look at the eclipse code for the Import Project wizard to give you a better idea of where to go with it.

Use AntEclipse
It can create eclipse projects from ant.

To create java project you can use JavaCore from org.eclipse.jdt.core.JavaCore. As a sourceProject you can use generic project item, which has been suggested by #James Van Huis
IJavaProject javaSourceProject = JavaCore.create(sourceProject);