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.
Related
I have created a Selenium Java Framework with a proper folder structure. Basically my framework consists of few common utilities(page objects, reporting configurations and, driver initialization settings, etc.). This framework was developed to automate and validate web applications. We have a bunch of web applications in our organization that are common in nature and behavior. The Java framework that I have developed has some generic methods and page objects that can be utilized in all the web applications.
Now, I have pushed my framework to the Github. And, I want other teams in my organization also to use my framework. So, in my organization for each project, we create a new repo. Therefore, I wanted to know if by any chance my framework can be accessed by other teams of my organization in their projects.
I don't want anyone to clone my framework repo, add their tests, and push it back. As each project in my organization will have their own repo. Therefore, I simply want them to add my framework as a dependency in their project repo. And, when they clone their repo and do a maven build, they should be able to access the utilities of my framework. Please let me know if this is possible by any chance. Thanks! in advance.
You have multiple options.
Option 1:
Give read-only access to the outside your project users, so that they can extract and re-use the items from the framework without impact your code. Other teams can tailor the framework according to their needs (you can consider it as adv/ disadv)
Option 2:
Convert your framework into a jar and then share it with other teams. Ask them to use the jar. No Edits in framework possible.
We are exactly doing the same thing (we are using option-2 as below). Other teams need to use it as a dependency in their pom.xml. Two ways to use the dependency in maven:
If your company has maven artifactory management system, you can publish your framework jar into that and ask the other teams to use it as a dependency in their pom.xml directly
Else,
2. You need to prepare a jar file, and the other teams need to use it as a dependency using system scope level as below:
<!-- Framework -->
<dependency>
<groupId>com.test.group></groupId>
<artifactId>automation-framework</artifactId>
<version>0.0.1-SNAPSHOT</version>
<scope>system</scope>
<systemPath>${jar.location}</systemPath>
</dependency>
groupId, artifactId, and version are the details of your framework project.
Other teams can create a folder called "libs" in in their project, and store your framework's jar in there. That location will go here: ${jar.location}
Every time you make changes to your framework and build new jar, they need to update the jar file under "libs" folder.
In this way, they can use all your utilities, but can't modify or publish any tests into your project.
You need to keep utils package and create all utils classes into that package and use it
In every projects you need to keep package for separate keeping utils classes
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 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/
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.
All -
we have several web applications, all based on some version of Spring developed over time by different team across organizations. They each produce their own WAR, have a different context to work within, and often gets deployed on the same machine, as their functionalities are closely knit together. So we end up with:
tomcat/webapps/{A, B, C ... }
upon deployment, each use a very similar set of tool chains, replicate all Spring jars and dependencies all around.
I am wondering if there is a way to make the project structure better, deploy as a SINGLE war, while allowing each webapp live in their own source repo and have its own pace of development??
Any pointer or references are much appreciated.
Oliver
Deploying in a single WAR will couple all the projects together. Modifying one will mean redeploying all, with the accompanying QA effort to validate and do regression. I wouldn't recommend that.
Multiple copies of Spring JARs can be addressed by putting them in the Tomcat /lib; they're loaded by the Tomcat class loader instead of the WAR class loader. That will mean that every app has to be on the same version of Spring; upgrading one means upgrading all. You'll have to regression test all at once.
What harm is separate WAR files doing you? What do you care if the Tomcat /webapps directory has lots of deployments? One advantage is that they CAN be on separate release schedules. That's a big one to give away. Be sure you have a good reason before doing it.
you would have to probably move to an app server like jboss, but couldn't you use an ear file and have maven build the modules for you? That way you could probably put them in separate repos if you want each with it's own pom and then have another project with a pom for the ear file:
here is the maven ear plugin:
http://maven.apache.org/plugins/maven-ear-plugin/
here is an older blog post about multiple spring app ear file (single applicationContext fo all wars to share if you need):
http://blog.springsource.com/2007/06/11/using-a-shared-parent-application-context-in-a-multi-war-spring-application/
Based on one of your comments to another response, it sounds like you might be more interested in maven's multi-module project feature. This will allow you to define a parent POM with consistent dependencies and project layouts managed across multiple projects.
You might benefit from combining each project into a single WAR, but I do think this is really one of those 'the grass is always greener' problems. One key thing I would keep in mind is figuring out how much longer (or shorter!) is redeployment going to take if the projects were combined.
Think about OSGi. You can deploy all the dependencies just once, build your separate but interrelated modules as OSGi bundles, and deploy and upgrade them all independently. You can also choose whether to deploy them all as WARs (web bundles) or to deploy them as JARs with one or many WARs importing them to tie everything up. Virgo Web Server, formerly Spring DM Server, is really nice and comes ready to do this kind of stuff right out of the box.