Thread: changed packages, now it will not run:

I did have all my classes in one package and it just look ugly. So I made a package for each button using MVC design pattern and now it much easier to understand. However now it will not run. I simply changed the package name for each button and when the red line came under the package it gave me the option to add this class to the new package name. All errors were gone and now I am getting this error:

Error: Could not find or load main class org.Home.DataBase.StartUpMenuController

But there is a main method in this class but the package name is actually (package mainMenu.Home.DataBase the old name was org.Home.DataBase the class name is StartUpMenuController (this class has the main method)..

How can I fix this ?

--- Update ---

Never mind got it working, not sure what I did though.... HUmmmm

--- Update ---

How do you mark [SOLVED] on this thing?

The Solved option is in the "Thread Tools" menu item at the top of the topic.

Having each button of the same interface in a different package sounds unnecessarily complicated. They say beauty is in the eye of the beholder, and I don't think your eye is trained to determine beauty in Java, but you'll get there with exercises like this one.

Please do explain here. I have been taught modularity is a key concept of Java. I am making a different database for my house, so that I know where everything is, storing pictures, their location etc... I have a generate reports button which will make an excel sheet of everything or just the items asked for, a add item button and find item button.

Each button will open a whole new screen from the main menu. This is all done in swing and mySQL.

What kind of design would you have chosen? I am using MVC and each button is in a different package at the moment.

Start by reading this Oracle trail on packages and then let us know if you have questions.

I hope you get from the trail that packages are a tool to help the programmer organize their code. The programmer should gain some benefit from being organized. Having packages (being "organized") without a plan and purpose is likely to create more hardship for the programmer than benefit and convenience.