I'd like to do some versioning of some Android code.
I pushed the code (only the res and src directories) and now I want to pull it in some other package.
How can I manage that, given that the code in my git repository has it's source in src/com/some/package/ and I want to clone it and get the source in src/some/other/package/?
I'm aware of this question, but I can't see any answer that helps.
What you can do as an alternative to directly managing it with git, is to separate the common code into its own Android Library Project. Then you would be able to add that library to the other two projects, giving you access to the same code base.
This would have you end up with three projects, and three repositories. Two of each for the separate projects, and one of each for the library project.
One thing to be aware of, however, is that if there is specific code for one project inside of the library, it will also affect the other project. Some of this could be handled by subclassing and overriding methods/properties as needed. Another way around this, as suggested by jul, would be to have branches for each project.
A nice benefit of doing it this way is that if you make a bug fix in the library that you found while working on one project, you'll be able to get that in the other for practically free.
Related
I dislike the build tools that exist for Java. So I wrote my own. But there is one feature that it doesn't have yet; auto-import of changes into the IntelliJ project.
I'm having trouble finding information on how to do this. Tutorials on how to write IntelliJ plugins throw tons of useless stuff at me (creating UI for example).
I know this isn't your typical stackoverflow I-have-a-bug question but I'm quite lost and could use a pointer in the right direction.
If you need to know when a certian file was changed and auto-import information from this file you can use VirtualFileManager.addVirtualFileListener().
Or even use fileDocumentManagerListener extension point. Whatever suits your needs more.
So far I've managed to create a simple IntelliJ plugin. The start is fairly simple. IntelliJ has the plugin project skeleton built in. File->new Project is enough there.
From there I've created a class that implements ModuleComponent. The documentation here (https://www.jetbrains.org/intellij/sdk/docs/basics/plugin_structure/plugin_components.html) says it will be loaded whenever a module is opened.
To get it to work I had to add this stuff in the plugin.xml:
<module-components>
<component>
<interface-class>packagename.ClassName</interface-class>
<implementation-class>packagename.ClassName</implementation-class>
</component>
</module-components>
The documentation manages to hide this next step but its possible to give the ModuleComponent a constructor like so:
public ClassName(final Module module) {}
This should give me an instance of the Module class to read values from and to modify the way I need.
As it turns out IntelliJ makes it difficult to figure out how to do things. There is no Javadoc for example. People seem to suggest reading the source code. Weird..
A quick look through the methods of Module didn't really help me much. Google let me know that in order to make changes to the Module I could do the following:
ModuleRootManager.getInstance(module).getModifiableModel()
I can call several methods on this model and finally call .commit() when I'm done to persist the changes. The ModifiableRootModel has two methods that look very promissing:
ModifiableRootModel.addModuleOrderEntry()
ModifiableRootModel.addLibraryEntry()
The first takes a Module instance. I'm hoping that if I add the correct Module this will allow me to well, add modules :). I can think of two situations here. First, the module is already loaded in the project, in which case I will need to find it and add it. And second, the module is not loaded yet so I will need to tell IntelliJ to load it and add it to the project.
The second method takes a Library instance. Just new Library() doesn't work, and google isn't very helpful here. From my buildfile I can extract the groupId:artifactId:version:scope value. So I'll need a way to turn those strings into a Library that works.
This is how far I've gotten so far. Current problems are:
I need to find the already loaded modules so I can find the one I'm linking to
I need a way to add a module to the project if it hasn't been loaded yet
I need a way to turn a maven style dependency into a Library object so I can add it to the module
I need a way to list all the existing modules and libraries so I don't end up adding duplicates
I have built a free version of a game app which is now on the market with a name like com.mycompany.myfreegame. Now I want to make a paid version. There will no doubt be tweaks and bug-fixes to both versions required for years to come so I want to encapsulate the encoding of the free vs paid information in as compact a way possible so that I can essentially fix bugs in both versions simultaneously.
If the entirety of the differences between the two versions was handled at runtime then I could set a single flag in the source code and that would be the end of the problem. Unfortunately there are two other things to consider,
The name of the package needs to be different between the two versions.
Some xml needs to be different. For example the free version needs linear Layouts for holding ads, the paid version does not.
What is the simplest way to achieve this goal?
I think the first approach I'd try is using 3 projects in Eclipse: one for either version of the game, and a library project with all of the shared code. The library project would be where all the code for your core gameplay goes, and the version specific projects manage loading different layouts, putting ads in the free version, and adding levels/features/hats to the paid version.
You might be able to accomplish your goal of a single code base with a compiler flag using an ant task, but that's beyond me.
I think what you're looking for is a Library Project http://developer.android.com/guide/developing/projects/index.html#LibraryProjects
From that web page:
If you are creating an application that exists in both free and paid versions. You move the part of the application that is common to both versions into a library project. The two dependent projects, with their different package names, will reference the library project and provide only the difference between the two application versions.
Another question, very similar to this one, seems to have a decent discussion and answer: Multiple Apps with a shared code base
Edit: Here is a link on how to implement a library project. http://developer.android.com/guide/developing/projects/projects-eclipse.html
In regards to different versions being slightly different, a library project can accomodate. The library project is built first, then the parent (the project that uses the library) is built last and they are merged together. Both projects can define the same resource identifiers and the project built last (parent project), gets priority (overwrites). So essentially, you can override strings/layouts (possibly more, not sure?) in the parent/calling application.
For example: Say you have two projects, free and paid.You could create a string with a default implementation (free version) and override it in your paid version (parent app).
Code in shared libraries Strings.xml file:
<string name="AppName">My Application (Free)</string>
Code in parent app Strings.xml file:
<string name="AppName">My Application Premium</string>
I would go with Maven. You can define a parent project with three sub-projects, say:
Common
Paid
Free
Maven allows to have different configuration files, while having the same code base.
For example, I currently have a project where two databases are used, so all the app config files remain on a common project, where the database configuration files and classes remain on each project folder. When I do a build in the parent, every child project is built, unit tests passed, etc...
Moreover, this is only one of the thousand advantages of maven!
EDIT: I just found out, you have an android-plugin for maven, with cool features also
May be the best way now is to use Android Studio + gradle.
This case allows to build both paid and free versions with one command in console.
More details are in this post: https://stackoverflow.com/a/17286142/1705370
I think you are looking for something similar to this:
Multiple Android Application Package .apk files from single source code
Basically, the easiest approach here is to have two different manifest files and two different main activities and switch the compilation using Ant, though the latter is optional.
Hope it helps.
I am a C# developer and I am messing around with Java. In C# I would normally have my front end project and then when I need to add another layer to the project (i.e service layer etc) I would add a class library in the solution and add a reference to it.
What is the convention in Java? Do you add another Java project to the workspace and then reference the project? Or do you add a package to the project which contains your front end?
UPDATE
Sorry, I am using eclipse...hence the reference to 'workspace'
There's no real convention. When you say "workspace" you're not referring to Java, but rather a development environment (sounds like Eclipse). There are a number of ways to do it; you could do it the way you're suggesting, you could include the dependency via Maven, you could combine them all together in one project, etc.
Which to choose depends on your needs, who else will be consuming either the individual libraries or the completed project, and so on.
How to divide your source code depends a lot on the structure of your project. It is important to pay attention to a good code organization. You should keep classes for a common task or for a distinct application layer in own packages. You should watch for inter-package dependencies.
Using different "projects" (be it Maven or Eclipse projects) helps ensuring that you (your developers) do not violate structural boundaries because the compiler checks the dependencies (one project references the other project, like in C#/VS). Maven generates a build artifact (e.g. a JAR file) for every project.
To summarize, I think it is a good idea to create new individual projects for each program module in order to be able to manage the dependencies between the projects explicitly.
You are assuming everyone works with eclipse, it seems (your references to "workspace").
You can do anything you want, but keep in mind others might not be able to include 'separate' projects for various components of the application.
You can easily address that issue by using some build tool (ant, maven) to build appropriate jars for the various app components, like data-model, persistence, API, etc.
If you front-end is an RIA, might make more sense to develop it as a separate project, although not necessary. If your app is some sort of Java driven UI, you can still do whatever you want, in both cases make sure the UI components have their own package hierarchy.
Yes, I guess I would create a separate package. So your UI code might be in com.mycompany.app.ui, your service code in com.mycompany.app.service, etc. However you want to organize your classes is up to you. Java itself doesn't care what packages the classes are in. The packages just help to make the code more manageable for the developers.
Unlike most things in Java, there's no real convention defined for how to split up project.
In my experience, it makes sense to include code that serves a particular business purpose in a single project, and to separate out code that you intend to share between multiple projects, or code that is not specific to a particular business purpose (e.g. database access, JMS libraries, etc.), into a separate project.
If the UI and the server layer are being developed in a single project, which means packaged and deployed in the same WAR file, I'd create a new package for the service and add classes and interfaces as needed.
If the service layer is deployed separately, I'd add dependencies as a JAR to the web project. All I should need are clients for the service.
If you're working in Eclipse follow these steps:
1) Right-click the project and choose "Build Path"-"Configure Build Path..."
2) Switch to Libraries tab and click Add External JARs (or just Add JARs if they're already in the workspace).
3) Now you can either manually add import of the corresponding class, or just hit Ctrl+Shift+O (Source-Organize Imports) and Eclipse will do the job for you.
I suggest you can use netbeans then you can create a java class library,when you deploy your project,netbeans will generate jar files for you,and place them at the right location.I'm also a ms developer,hope it helps
I have recently joined a project that is using multiple different projects. A lot of these projects are depending on each other, using JAR files of the other project included in a library, so anytime you change one project, you have to then know which other projest use it and update them too. I would like to make this much easier, and was thinking about merging all this java code into one project in seperate packages. Is it possible to do this and then deploy only some of the packages in a jar. I would like to not deploy only part of it but have been sassked if this is possible.
Is there a better way to handle this?
Approach 1: Using Hudson
If you use a continuous integration server like Hudson, then you can configure upstream/downstream projects (see Terminology).
A project can have one or several downstream projcets. The downstream projects are added to the build queue if the current project is built successfully. It is possible to setup that it should add the downstream project to the call queue even if the current project is unstable (default is off).
What this means is, if someone checks in some code into one project, at least you would get early warning if it broke other builds.
Approach 2: Using Maven
If the projects are not too complex, then perhaps you could create a main project, and make these sub-projects child modules of this project. However, mangling a project into a form that Maven likes can be quite tricky.
If you use Eclipse (or any decent IDE) you can just make one project depend on another, and supply that configuration aspect in your SVN, and assume checkouts in your build scripts.
Note that if one project depends on a certain version of another project, the Jar file is a far simpler way to manage this. A major refactoring could immediately means lots of work in all the other projects to fix things, whereas you could just drop the new jar in to each project as required and do the migration work then.
I guess it probably all depends on the specific project, but I think I would keep all the projects separate. This help keep the whole system loosely coupled. You can use a tool such as maven to help manage all the dependencies between the projects. Managing dependencies like this is one of maven's main strengths.
Using Ant as your build tool, you can package your project any way that you want. However, leaving parts of your code out of the distribution seems like it would be error prone; you might accidentally leave out necessary classes (presumably, all of your classes are necessary).
In relation to keeping your code in different projects, I have a loose guideline. Keep the code that changes together in the same project and package it in its own jar file. This works best when some of your code can be broken out into utility libraries that change less frequently than your main application.
For example, you might have an application where you've generated web service client classes from a web service WSDL (using something like the Axis library). The web service interface will likely change infrequently, so you don't want to have the regeneration step reoccurring all the time in your main application build. Create a separate project for this piece so that you only have to recreate the web service client classes when the WSDL changes. Create a separate jar and use it in your main application. This style also allows other projects to reuse these utility modules.
When following this style, you should place a version number in the jar manifest so that you can keep track of which applications are using which versions of your module. Depending on how far you want to take this, you could also keep a text file in the jar that details the changes that have occurred for each revision (much like an open source library).
It's all possible (we had the same situation some years ago). How hard or easy it'll be depends on your IDE (refactoring, merging, organizing new project) and you build tool (deploying). We used IDEA as IDE and Ant as build tool and it wasn't too hard. One sunday (nobody working+committing), 2 people on one computer.
I'm not sure what you mean by
"deploy only some of the packages in a jar"
I think you will need all of them at runtime, won't you? As I understood they depend on each other.
I'm currently working on a project that contains many different Eclipse projects referencing each other to make up one large project. Is there a point where a developer should ask themselves if they should rethink the way their development project is structured?
NOTE: My project currently contains 25+ different Eclipse projects.
My general rule of thumb is I would create a new project for every reusable component. So for example if I have some isolated functionality that can be packaged say as a jar, I would create a new project so I can build,package and distribute the component independently.
Also, if there are certain projects that you do not need to make frequent changes to, you can build them only when required and keep them "closed" in eclipse to save time on indexing, etc. Even if you think that a certain component is not reusable, as long as it is separated from the rest of the code base in terms of logic/concerns you may be well served by just separating it out. Sometimes seemingly specific code might be reusable in another project or in a future version of the same project.
When compiled, a project would typically result in a jar. So if your application consists of potentially reusable components, it is ok to use a project for each.
I'm a big fan of using a lot of projects, I feel that this "breaks down" large things beyond what I can do with packages, and helps me orient and navigate.
Of course, if you're developing Eclipse plug-ins, everything would be a project anyway.
The only thing I would watch out for has to do with your source-control and it's ability to handle moves of files between projects. Subclipse had been giving me trouble with it, or maybe it's my SVN server that did.
If your project has that many sub-projects, or modules, needed to actually compose your final artifact then it is time to look at having something like Maven and setting up a multi-module project. It will a) allow you to work on each module independently without ide worries and allow easy setup in your ide (and others' IDEs) through the mvn eclipse:eclipse goal. In addition, when building your entire top level project, maven will be able to derive from list of dependencies you have described what modules need to be built in what order.
Here's a quick link via google and a link to the book Maven: The Definitive Guide, which will explain things in much better detail in chapter 6 (once you have the basics).
This will also force your project to not be explicitly tied to Eclipse. Being able to build independent from an ide means that any Joe Schmoe can come along and easily work with your code base using whatever tools he/she needs.
Create jars for the projects you don't work in often. That should greatly reduce the clutter. If you work on all the projects often, then you can add targets to your build that will jar up the respective projects for you, which condenses everything down to one file that you can then include on the class path.
An additional method is to create many different workspaces. The benefit of separate workspaces is that you can remove some of the visual clutter/ performance overhead of having lots of projects. You can use targets to jar up all of you projects and put them in a repository so you can reference them in each workspace.
At a former job the entire application was more then +170 projects. While it was rarely necessary to have all projects checked out locally, even the 30-40 projects constantly in our scope made reindexing, etc. very slow.
Yeesh. One Project for each Project. If you are using reusable projects, make them into a library for heavens sake. Break the none re-usable projects into packages, that's what they are there for.
That's a hard question and answers span from having one eclipse project at all to having one eclipse project for every single class.
My bottomline:
You can have too few projects,
and never too many (of course use
automation e.g. mvn eclipse:eclipse)
Use
-Declipse.useProjectReferences=true/false
when using maven to switch workspace
mode btw jar and project
dependencies
Use mvn release plugin to generate
consecutive releases (automatic
version increase)
Multiple projects gives you
independent versioning which is
extremely important. E.g. one dev may work on a new version of a
module while you still depends on
the previous one and you at some
point decide to upgrade to the newer
version(possibly by increasing its version in pom.xml dependency section). Or in other scenario if one
project contains a bug you downgrade
to its previous version.
Multiple projects makes you think
about the architecture more than if
you have just packages.
Multiple projects generally make
architectural problems evident more
than if you have just one project.
Anyone would like to comment on
this?
You never know if you project
evolves into OSGI/SOA/EDA where you
need separation.
Even if you're 100% sure that you
projects will be deployed as one jar
in an old way in a single jvm, it
still does not hurt(mvn assembly
plugin) to have multiple eclipse
projects for logically independent
pieces of code
BTW, the project I work on is divided into 24 eclipse projects.
Hell, we have more than 100. Projects don't cost anything.