I wrote a package in eclipse (Java/Android package, that is). Now I want to make another package which is a slight variation on the original. My plan is to copy and paste each .java file into the new package and change the import package.somename to the name of the new package, and develop from there. Is there a better way to do this?
Select the package in the project explorer, press Ctrl+C and then Ctrl+V, Eclipse will prompt with a package name conflict warning and ask you to enter a new package name. Just enter it and Eclipse will repackage all copied classes accordingly.
Unrelated to the problem, there's a design smell in your approach :)
In a comment on an answer you've given the reason you want to do this: "Now I want to put up a free demo version, with some functionality removed."
Instead of copying all the code to another package I'd take the approach of having only one code base and using a build parameter to specify if you're building the free or commercial version. The classes and config (e.g. spring) that are included in the build could then depend on this parameter.
Duplicating the codebase may seem like the easier option now but will duplicate your work in the long run when maintaining it, and increase the risk of bugs.
How about just extend the classes you want to change? that way you can the two variations in the same package
Depending on how much "slight variation" really is you might want to keep it as one package and handle the differences. Reasons you might not want to do this is that by duplicating a whole package for only small changes is not really clean. Duplicated code is a code smell and can cause headaches in the future if a bug is found in one package and needs to be fixed as well in other sections of code.
To answer the question though, Eclipse should have the functionality to copy the whole package and to paste it back into the project. You will have to rename either one of the packages so that you have a unique package name though.
Related
I've been working on an Android app in Eclipse, and it's gradually grown in complexity to the point where I find it difficult to locate individual classes in the Package explorer.
Java isn't my strong point, I come from a Visual Studio/C Sharp background, so my first thought was to move logical groups of classes into new packages, a bit like creating a new code folder in Visual Studio.
I created a new package, com.mycompany.myapp.activities and dragged all the Activity.java files into here.
The whole thing went pretty badly, I got tons of import errors, resources failed to build, and so on. The auto refactor tool messed up my Manifest file pretty badly too. It just doesn't seem like it was designed to work that way - I ended up moving them all back, and wasted two hours fixing it.
So my question is, does Eclipse have some way to organise .java files into logical subfolders without having to create new packages for them? I'd like to make a folder for 'Data Model', one for 'Activities', one for 'Interfaces' and so on.
How would I go about doing this? Or am I thinking about this the wrong way?
So my question is, does Eclipse have some way to organise .java files into logical subfolders without having to create new packages for them?
AFAIK, no. You just need to fix up stuff related to moving your code into packages.
I got tons of import errors
Your app's R.java is generated into your application package (com.mycompany.myapp), and any classes in that same package get R via auto-import. Code residing in other packages needs to import that class (e.g., import com.mycompany.myapp.R). Hence, if you refactor a class from your app's package to a sub-package, you need to add the import.
resources failed to build
That seems unlikely, as resources know nothing about Java packages. However, without any details, it is difficult to provide you with concrete assistance.
The auto refactor tool messed up my Manifest file pretty badly too
You would need to adjust your <activity> elements to ensure they point to the newly-repackaged classes. Ditto for any other components that you repackage (e.g., services). Beyond that, without any details, it is difficult to provide you with concrete assistance.
It just doesn't seem like it was designed to work that way
Certainly, moving activities into other packages is supported. Whether the ADT plugin handles all aspects of it with aplomb is another issue. If you come up with concrete repeatable scenarios where the ADT plugin is not doing the right thing, file an issue at http://b.android.com.
I was wondering if there is a way to reuse my classes in Android projects where the only thing that changes is the R import?
So for example I have one file saved where the import is :
import com.myname.project.R
And in my second project the class is exactly the same as the one in the first project except it's import for the R file is different:
import com.myname.projecttwo.R
This means I have to maintain two files with just the import being different, son when I change something in one I have to remember to change it in the other.
Is there a standard way to avoid this and have only one file where I can change whatever I want and I will be able to use it in both projects?
If you want to use a lot of shared code, you probably should be using a library project to keep your codebase and then two different projects with your resources.
Android Developer explains it nicely, see: http://developer.android.com/guide/developing/projects/index.html#LibraryProjects.
I do not think you need that line at all. I do not have it in any of my modules, and if one ever does it is usually an error. As far as I know, that include should be generated automatically. I am no expert on this and I can feel a downvote coming here, but that is my experience as a jobbing programmer. I do have a package statement though, and I would need to change that if I wanted to reuse the code.
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 have two projects, Main and Core. I have a package called com.package.Sample (along with its contents) and a class called Sample in package com.package. If I were to include both in Main, I would run into an error with one being unable to resolve - in my actual case it was the Sample class that could not be resolved. We have ant scripts that builds and that has always worked.
However, carefully examining what was required of each project, I noticed that I could move the package com.package.Sample into Core along with its dependencies that were in Main. The Sample class technically belonged inside of Main so I did not move it. This allowed me to build successfully within Eclipse.
A couple of things I'm wondering about:
Is this common in large projects?
What is the best approach for this kind of situation? Prior to examining the conflict, I thought the best solution was to re-factor the Sample class.
If however, I could not move the package com.package.Sample out of Main. What should I do? Or is this a case of it will never build?
To answer your bullets, respectively:
I don't know if this is common in large projects, I would assume not. Large projects would probably never become large if the codebase was designed to cause name conflicts (especially in Java, which makes solving problems like this easy).
I wouldn't refactor the Sample class if the name is appropriately descriptive. I would however, name my packages (and subpackages) with all lowercase letters. You implied that this is a smallish project, so I'm guessing you have control over naming. I have never seen in my recollection production Java code (commercial or open source) that used any capitals in a package name. Since the convention in Java is to use Pascal case or camel case or whatever you want to call it, if you follow that convention you will never have a class/package name conflict.
Of course it will build. Pretty easy fix. Since you are using Eclipse, you should be able to right-click the package in the explorer, choose "refactor", change the name to lowercase, and be pretty much done.
Good luck!
Package names should be all lowercase, class names should start with a capital. Following this practice makes sure that problems like you describe never occur.
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.