I need to create an application that will be deployed on Desktop and Android.
I'll use the MVC pattern; the Desktop and Android versions will share the Controller and the Model.
I thus want to create my two projects in a way that allows me to share the code related to the controller and the model, each project having its own version of the view.
What is the best way to do that in Eclipse? I don't want to use the code as a library because it must be possible to modify it directly from any of the two projects, with the modifications visible immediately in both.
Moreover, when the applications will be done, I must be able to generate an "ant build file", so I want a file structure that allows to build the two versions separately with no redundancy.
Thanks in advance!
You can share class files and jar files between projects as a library, so what you would need would be three projects: two with the interface code and one with the common files. The common files would be your library.
I think u should use maven or gradle build https://spring.io/guides/gs/maven-android/
Related
I am trying to make a new file var.java in project A such that it includes some variables . Now I need to use the same variable while passing to an intent from project B .
Till now what I am doing is that we are defining the variables once in project A and then in B and I need to reduce the code redundancy.
I had an idea to configure the whole project B in A settings.gradle file but since I am just needing the particular file var.java in A there is no point of doing that.
Can anyone please suggest some way to fix this.
Basically, what you're trying to achieve is reusable code to be used among several projects. So the logical approach would be to create a shared library to use in all projects that need it. Extract all general purpose code needed for multiple projects into its own project and add it as a dependency with maven or Gradle or add the library in the old fashioned way manually to your projects.
Of course I am assuming you are talking about information that is already existent at compile time, constant values that do not change during runtime. But as you've written it, it doesn't sound as if you were sharing information during runtime, so a small, simple library would do the trick.
I am working on a project using the Java Spring framework, but I am (even after googling or looking through tutorials) unable to understand how it should be used.
Situation:
The project is(or, will be) made up of 3 separate web applications(for three different uses/target audiences) that uses the same database and to some extent functions and/or classes.
Database/cryptography-related classes and such are in a common folder under the project root, which seems appropriate.
Then there is a folder for gradle, used for starting the program("./gradlew app-one:bootRun"), which I suppose makes sense.
Then, there is a folder for one of the web applications("app-one") with related source code(Controllers, Services, etc.) and whatnot.
Problem:
I am tasked with adding the second application. Is it suppose to be a separate folder in the root directory?(Logically/By framework standards)
If it is not, how do I know what belongs to which application?
Do I need to use separate gradle commands to start each of the three applications? Is that even possible, and is it recommended/efficient/the best way to structure everything?
If you want to use maven,you can create a multi-module maven project with parent pom having all dependency management.A core project(jar) having all core functionality and three web projects(war) for your web modules which depend on this core project.You can start build and run these projects with a bat script from one place only.
I'd like to have 2 different projects: one connecting to a webservice, and another project handling imports.
Both projects will be running for the same final application, but should run on a different server each. Also each project should be able to be released independently (eg if I fix a bug on the importer, I have to release it without reference to the webservice project).
The projects should share some code, eg domain classes. Which maven structure should I use for this purpose?
3 independent projects whereas the commons is installed to the local maven repo and used as dependency by the others?
Or is it somehow possible to directly resolve the commons project from eclipse workspace without having to install it?
svn/Webservice/pom.xml
svn/Cache-Importer/pom.xml
svn/Commons/pom.xml //used by both projects and contains eg shared domain code
I would recommend, as you guessed, the three independent projects model. The Webservice and Cache-Importer projects will depend on the Commons. Having them as separate projects allows you to have different lifecycles for these projects and you can release one, but not the other.
If you want to put them in the same aggregator, this would tie you to having them all released under the same version and some of the modules might not need a version bump at the time. Therefore, in my opinion, this would be a better approach.
If you would like to build them together, but would also like to have them as independent modules, you could create a fourth project which has them defined as <modules/> in the pom.xml. You will need to setup svn:externals (as explained here) and basically link the paths of the modules to this project. This way you'll be able to check them out altogether and build them, while you'll also be able to release them independently as well.
I have two java projects that are fairly independent beside the fact that they share a common mysql database.
I wanted to refactor these project and extract everything regarding the common data layer. I am using jOOQ, so most of this layer gets autogenerated in my build. Beside that i then have a few common entity classes that are used in both projects.
what would be the best practice to separate this, so that any change can be done one place and still propagate to both projects? create a third java simple project with the common code? what would you do
I work on a distributed system, and multiple daemons need access to the same Postgres database via jOOQ. Since each daemon is its own Java project, I am in the same boat as you basically.
The solution I've been using is to create a third Java project as a Java Library. If you're using Netbeans you can just include it as a subproject dependency and any changes to the library project can be recompiled into the individual application projects.
One thing of note, you'll need to specify the jOOQ library jars in all 3 projects. In Netbeans its easy to specify a project's library directory, and have multiple projects share these dependencies. Netbeans will copy the dependencies at deployment time.
Edit:
The steps are basically:
create a master layout for system, IE:
/master-project/
/master-project/library
/master-project/software
/master-project/software/daemon1
/master-project/software/daemon2
/master-project/common
/master-project/common/utility1
/master-project/common/utility2
create third-party "library" bundles of {jar,src,docs} under /master-project/library.
create "application" projects under /master-project/software, making sure to tell Netbeans to only use third-party libraries under /master-project/library.
create "library" projects under /master-project/common, making sure to tell NB only to use third-party libraries under /master-project/library.
create a "library" for jOOQ code to be shared, as in step 4.
Each project is responsible for its own compile script (including generating jOOQ code, if desirable), and correctly specifying its dependencies out of /master-project/library, and /master-project/common.
I have an app written with GWT and GAE where every supported city has its own app. Clearly this is not the best way to manage the map so I want to merge them all into one app. Currently my app is at the urls sub1.myapp.com, sub2.myapp.com, sub3.myapp.com, etc, and I want them to be at myapp.com/sub1 ,myapp.com/sub2, etc. All the supported cities share common code, so I'm going to put all the that code in one module, and have a different module for each piece of unique code block. Is this going about it the right way? How will the different modules interact?
Also, I currently have JSPs at sub1.myapp.com/listofsomesort and I would like to move these to myapp.com/sub1/listofsomesort. Is there a simple way to accomplish this?
By making a module with EntryPoint for each old application, in one and the same application. Each module has one 'welcome page' which you can put in different directories. All the shared code can go into another module. The shared code can be used by the inherit setting in other modules.
The only thing I bumped into was that when you deploy to GAE, ALL modules should have an entry point, also the library modules. I solved it by adding a dummy EntryPoint to them, that does nothing, but still searching for a better solution. See my question at How to deploy GWT Project containing GWT modules without entry points with Eclipse GAE plugin?.
This seems like the job for Code Splitting :) It might require some changes in the structure of your code, though - depends how tightly coupled your classes are. A compile report should tell you if your code splits up nicely, or if not, where the connections are.