In some projects, I have to deal with more than one programming language (for example a Delphi GUI application which communicates with an C# or Java app). The Subversion repository currently contains three top branches, one per language.
Should I change this and group all parts of the project in the trunk like in the following example to make branching and tagging on project level easier?
project1
branches
...
tags
...
trunk
csharp_app
delphi_app
java_app
...
project2
...
As these separate sub projects interact, then they need to move in lockstep, and you need to tag/branch/release the C#/Java/whatever components together. If they're unrelated then I would advocate (perhaps) separate repositories, or separate directories within the same repository. But not branches or tags.
Branches are used to manage different development streams on the same codebase. Tags are used to indicate a particular point in the project's evolution.
I think the programming language is irrelevant. Ask yourself what your releasable is, and how you need to manage this. I've done this successfully in the past with projects incorporating Java and C++, and the language is not the issue - it's keeping the components in sync that you need to manage.
I wouldn't necessarily create a new top-level directory per language. What happens if your Java component suddenly requires a JNI layer ? It strikes me that the implementation is reflected in the top-level directory structure, and that shouldn't really be a concern.
Programming language is irrelevant when you're managing a single project. A single module may be written in a variety of programming languages but still be too tightly coupled to worth separating. If each module of the application (whether or not it's written in the same language) is independent enough to be considered a separate project (and consequently, become independently versioned), you may want to separate it. Otherwise, don't do that.
I don't think it's a good idea, because theoretically the different components could break compatibility, and if they don't stay synced up it would be hard to go back to the last working good config.
Yes. The criterion is whether the apps require some form of synchronization of their features between each other, and that communication protocol (API, shared code, shared libs) may change over time. If the apps have nothing to do with each other, then separate repositories. Having apps written in multiple languages in the repository is irrelevant.
Related
I have a project in Android Studio and two different app module but both of them are using this same Android library (core code). I want change some resources and logic in application but this code is in core (Android library). How do I approach this? How to customize core code?
I've been asking the same question and after some research, I've found that you have different approach:
Gradle Flavors:
Why Product Flavors?
They address the issue of having separate project code for each version of the app while still having one project code.
Given a scenario where you have a free and a paid app you can limit features in the free and expose all the other features in the paid version of the app.
Given another scenario where you want to implement region-specific functions depending on the country, you can use product flavors for such a use case.
White labeling (these are apps that are developed by a certain company, and they are re-branded and resold by other companies).
Pros
They address the issue of having a separate project code base for each version of the app.
They keep the code tidy and makes it much easier and faster to navigate through the code base as everything related to the specific product flavor would be kept in their corresponding folders.
Cons
(Scaling Up) The more variants, the greater the complexity which thereby makes it harder to maintain the codebase.
-IDEs sometimes takes time to build the project after switching between variants.
Source: https://levelup.gitconnected.com/simple-guide-to-android-product-flavors-674106455038
Multi-Module
Why ?
Faster build times.
Fine-grained dependency control.
Improve reusability across other apps.
Improves the ownership & the quality of the codebase.
Stricter boundaries when compared to packages.
Pros
Scales well as the application grows with new features
Medium to large development teams are able to work on different modules without affecting each other (Merge Conflicts)
Encapsulates unit and ui tests to their specific features
Keeps Resources separated between modules. Which improves readability and organization
Keeps logic contained in their own modules, which can be hidden behind interfaces
Forces the developer to keep their code better organized and structured
Improved build speed, as changes in a module means only that module will need to be rebuilt
Cons
Adds additional boilerplate around the construction of the modules
More development time overall
Requires a maven/gradle file for each module
Navigation between module activities can be difficult to setup correctly
Requires a lot more pre-planning on how best to structure code, and determining where shared code bases are stored.
Limited amount of online resources showing best practices
Source:
https://medium.com/swlh/modularization-by-feature-and-layer-with-android-architecture-components-80bf317d737
https://codelift.dev/android-modular-app-architecture/
Also look at the gradle doc to start with modularizing.
You can build the library's aar and use it in your main projects by simply copying into lib folder in your project directory.
Or you can build it with services like Jitpack and add it to your project by the implementation method in Gradle.
I want to keep only java util, io, nioand math packages and want to remove all other packages like java.sql and others from my JDK.
How can I remove them?
So if I write some program which import removed packages it will give
error package doesn't exist.
Use a SecurityManager instead of hacking the JDK
I'm going to give you the best answer I can.
Why you really shouldn't be doing what you want to do
When you're writing code, it is commonly agreed to develop that code in a way that is extendable. That is, your code can be plugged into other applications, or it can be changed and added to, very easily. Now with that principle in mind, let's review what happens when you delete the possible functionality of your program. Say you delete the SQL package, and in the future, you want a backend database to provide some persistence in your program. You're screwed.
The idea of Java, in fact I'd go as far as to say the major advantage of Java, is it's commonality, consistency and standardization of patterns. A getter is always a getter. A variable (that isn't a constant) starts with a lower case letter. Classes have a standardized way of being structured. All these things make developing in Java quite intuitive.
The JDK is part of that consistency, and to edit it is to really impact one of the major points of Java. It sounds like you want to implement your program in a different, more compact language.
Finally, you have no idea how the client may want to extend your project in the future. IF you want to have some repeatable business from the client, and generate a good reputation at the same time, you want to design your code with good design practise in mind.
There is no such tool, AFAIK.
Removing stuff from the Java libraries can be technically tricky, 'cos it can be difficult to know if your code might directly or indirectly use some class or method.
There are potentially "licensing issues" if you add or remove classes from a JRE installer, and ship it to other people.
Concerning your proposed use case.
If you are building this as a web application, then you are going to have a lot of difficulty cutting out classes that are not needed. A typical webapp server-side framework uses a lot of Java SE interfaces.
If you accepted and ran code someone who wanted to try and bring down your service, they could do it without using only the Object class. (Hint: infinite loops and filling the heap.) Running untrusted code on your server is a bad idea. Period.
Think about the consequence for someone trying to run legitimate code on your server. Why shouldn't they be allowed to use library classes / methods? (I'd certainly be a bit miffed if I couldn't use "ordinary" library classes ...)
My advice would be reconsider if it was a good idea to implement such a service at all ... given the risks, and the difficulty you could have if your safeguards were ineffective. If you decide to proceed, I advise running the untrusted code within the JVM in a security box. As a second level of defence in case Java security is compromised, I'd recommend running the service "chrooted" or better still in an isolated virtual machine that can be turned off if you run into problems.
We're using JBoss Drools to externalise some particularly prone to change business logic in some services we are building.
Where these rules can be created and maintained by our developers this is working very well and we have a good level of integration and integrated workflow.
We are looking to expand its use to a new service that has a very high level of customisation required. Essentially an "expert user" needs to be able to setup rules of two different kinds:
"standard" rules - these are almost implicit rules that we know are common requirements and which we could build UI for to set e.g. only allowing certain operations to take place between two dates etc.
"custom" rules - completely off the wall requests that whilst we could try and anticipate we'd rather just let people write and test their own rules against :)
My question is, is it possible (and indeed is there anything out there as an example) of using Drools for both 1 & 2? Basically, to have a fixed UI application author Drools rules effectively AND have a "free text" rule editor embedded in our UI?
Any suggestions appreciated!
You have a few options.
For (2), you can simply embed the rules editor from Guvnor in your web application. All editors in Guvnor are embeddable components, so you can choose what you want to use and what you don't. The problem that I see in this approach is that you might be giving too much power to the users :). In other words, the ability to write any rules based on the model requires disciplines that are typically only known to technical users. For instance, writing tests to validate the rules. Some business users have enough technical knowledge for that, but I would say it is probably the exception, not the rule.
What I prefer and recommend most of the time is to develop your own domain specific GUI, that uses/exposes concepts and terminology that are familiar to the business users and a way to write rules that "makes sense" for their specific job. Sometimes, they will not even know they are writing "rules", but they will. Behind the scenes, your application takes the input from the Domain Specific GUI and generates the rules dynamically, either using the drools API or a string based template. This solves your (1) requirement, but might be powerful enough to solve (2) as well.
I'm wondering if there is some recommended reading, best practice or opinion on how to organize larger Java projects.
I made the observations that there are folks who split up everything into projects (i.e. modules) and create many many projects that share a web of dependencies. This has the advantage that compilation is often super fast, but when the project gets large nobody knows anymore what depends on what and why. Not talking about dependent libraries, version conflicts & co.
The alternative is to have just a couple of projects such as frontend, backend, ... . The namespacing does the job.
Any opinion, further reading anyone could recommend?
As soon as you start splitting a big project up into smaller projects, you encounter a lot of dependency tracking that you generally didn't have to consider. You could manage this yourself or you could use software which already handles a lot of the core issues.
I would recommend Apache's Ivy. It integrates well with Apache's Ant, and has a separate configuration file (which gets checked in) to track what is required for each kind of build.
Apache's Maven is another good choice; however, it does a lot more than Apache's Ivy. Sometimes that "a lot more" means you doing less of what you would have done anyway, sometimes that "a lot more" means you are doing (and configuring) things that you didn't do before. Depending on the fit of your practice to Maven's, migrating to Maven might be easy or very hard.
In addition, using Ivy, you can set up your own private repository of "permitted" jar files to pull from, and that will make code auditing much easier. Basically, reconfigure ivy to not pull from the web, but to pull from your local repository only, and then control access to the repository to only allow jar files which were reviewed to have acceptable licensing.
Once you have software in place, you can afford to split projects up into smaller pieces. This will permit you to do the right thing (if your project favors small decomposition) instead of the expedient thing (a few big chunks which might not really buy you much in decomposition maintainability). As far as where to make the cuts, that depends heavily on the specifics of your application.
Many small pieces tend to be easier for a new person to digest one-by-one. They also get people thinking about where functionality is to be added to a project; however, it does cost time and effort to untangle and separate all of the components. The plus side is that it is generally easier to test and validate something smaller, the downside is that it is a longer road to decompose one monolithic collection of responsibilities into many small, well integrated yet functionally disparate units.
Good luck
A very large project will need to have some way of tracking all of the libraries and other dependencies that it uses. The defacto standard for doing this is Maven. It's definitely the best way to start keeping track of what is going into your application.
Then you can decide how to split your application up. Basically, what you're trying to do here is to split up your application up into complete functional pieces. For instance, if you had a website that had a contact form, a photo gallery, a shopping cart, and a forum, you would split the project up into pieces that contained each of those different modules.
Actually, you will want to utilize both projects and namespacing.
Namespacing is an important tool for differentiating what purpose a code has at the code level. Regardless of what project a class comes from, the package should give me some idea of its purpose.
At a higher level, it is easier to manage builds and your development environment by having your code separated into projects. For instance, if you are developing a UI, why do you need to have the database code loaded into you IDE? It is just extra clutter in your workspace. It also makes it simpler to share common functionality between different projects. This will of course lead to needing some form of dependency management, of which either of the mentioned tools such as Maven or Ivy will suffice.
An important note though. Do not use split packages between projects. This causes nightmares if you or anyone who will ever use your code wants to do so in an OSGi environment. So, your namespaces should be unique within a project, although they should share a common root with other related projects.
I've been beginning a client-server application. At first I naturally created two projects in Eclipse, two source control repositories, etc. But I'm quickly seeing that there is a bit of shared code between the two that would probably benefit from sharing (in the same project or in a shared library) instead of copying.
In addition, I've been learning and trying test-driven development, and it seems to me that it would be easier to test based on real client components rather than having to set up a huge amount of code just to mock something, when the code is probably mostly in the client. In this case it seems having the client and server together, in one project, thinly separated by root packages (org.myapp.client.* and org.myapp.server., maybe org.myapp.shared. too).
My biggest concern in merging the client and server, however, is of security; how do I ensure that the server pieces of the code do not reach an user's computer? When Eclipse bundles a JAR, I'd have to pick out the server-specific bits and hope I don't miss any, right?
So especially if you are writing client-server applications yourself (and especially in Java, though this can turn into a language-agnostic question if you'd like to share your experience with this in other languages), what sort of separation do you keep between your client and server code? Are they just in different packages/namespaces or completely different binaries using shared libraries, or something else entirely? How do you test the code together and yet ship separately?
A lot of this is going to depend on your specific implementation but I typically find that you have at least three assemblies (binaries) that are created with a project like this.
A Common DLL that contains shared functionality that is used by both the client and the server
The DLL/Exe for the client
The Dll/exe for the server
Using this approach you have your shared items, but you make sure that items that are server specific are never in a distribution that is sent to the client workstations.
Neither. It should be 3. (common, client and server) However, it doesn't necessarily need to be three "projects". Using Maven I create three sub-modules under a master project. You can do something similar using Ant.
I have found that at least one project per finished entity (server deployment, client binary, etc) works well with e.g. Hudson. Then you can have shared code in a basic project available to all.