Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Should I create an eclipse plugin with target platform OSGi or without it ?
from Eclipse help
"If you do not intend to use the Eclipse extension registry, then you should use the OSGi framework option. If you select the OSGi framework option, you will not end up with dependencies on the runtime layer. Moreover, PDE will restrict the available templates and the code generated for you to the OSGi layer."
What I can't do when I choose OSGi? Why would I choose OSGi when its less powerful for plugins ?
This setting just adjusts the dependencies of the soon-to-be-created plugin. You can create a simple bundle and add dependencies to the eclipse infrastructure bundles - will you manage the versioned dependencies by hand?
Also, depending on this setting the wizard will offer to create project scaffolding based on a template for the selected eclipse version; f.e. help, preferences, UI contributions, and whatever else you have installed that has a registered template that applies.
In essence, if your plugin will only be used within eclipse, you don't need to think about it, just set the desired Eclipse version. If your plugin should be also usable in other OSGi frameworks, only then is any decision necessary.
Our simple rule of thumb that handles almost all cases is, if it does not provide any UI functionality, then it is an OSGI bundle. In this case, none of the SWT specific libraries and frameworks are being used.
You asked "What I can't do when I choose OSGi? Why would I choose OSGi when its less powerful for plugins ?", so I will ask "are you writing a plugin, or an OSGi bundle"?
They are not the same thing. A plugin is a bundle, with the UI extensions added on. This is not a matter of it (OSGi project) being less powerful, it simply doesn't provide the extra functionality required to code a UI, as this is NOT part of OSGi. So if you are writing a pure OSGi bundle, then create an OSGi project, without the extra dependencies and artifacts that are simply not required. If you are writing a UI, then it should be a plugin project.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Problem statement: Every service has a separate repository. what is the best way to use a common framework across several service repositories?
We are trying to create an API test automation framework using "Karate".
Here we want to create a framework(Which can be distributed(example:jar)) such that it can be used across all of the microservice project repositories.
As the creator of Karate, I strongly recommend you don't do this. In the long term this makes all your projects depend on one common framework - and you should try to reduce the creation of "home grown" frameworks. Especially for a testing framework, you should try not to force teams to depend on an additional library which you need to maintain and version-control. Re-use can cause more harm than good especially in the context of testing, see this article at the Google Testing Blog.
That said, since Karate can read files from the classpath: you can "ship" a JAR file with common Java classes and even feature or JS files that all your projects can inherit from or "re use". In fact the karate-base.js has been designed to solve for common bootstrap logic or variables / parameters being supplied from a JAR file.
Short Answer: use normal Java techniques (Maven / Gradle) to create a re-usable JAR file. There are multiple ways to use resources (Java, *.feature, JS) from a JAR file. It is up to you how to structure your Maven (or Gradle) projects to make this happen.
EDIT: for those looking for how to create a "runnable" JAR, please see https://stackoverflow.com/a/56553194/143475
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Problem statement: Every service has a separate repository. what is the best way to use a common framework across several service repositories?
We are trying to create an API test automation framework using "Karate".
Here we want to create a framework(Which can be distributed(example:jar)) such that it can be used across all of the microservice project repositories.
As the creator of Karate, I strongly recommend you don't do this. In the long term this makes all your projects depend on one common framework - and you should try to reduce the creation of "home grown" frameworks. Especially for a testing framework, you should try not to force teams to depend on an additional library which you need to maintain and version-control. Re-use can cause more harm than good especially in the context of testing, see this article at the Google Testing Blog.
That said, since Karate can read files from the classpath: you can "ship" a JAR file with common Java classes and even feature or JS files that all your projects can inherit from or "re use". In fact the karate-base.js has been designed to solve for common bootstrap logic or variables / parameters being supplied from a JAR file.
Short Answer: use normal Java techniques (Maven / Gradle) to create a re-usable JAR file. There are multiple ways to use resources (Java, *.feature, JS) from a JAR file. It is up to you how to structure your Maven (or Gradle) projects to make this happen.
EDIT: for those looking for how to create a "runnable" JAR, please see https://stackoverflow.com/a/56553194/143475
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Eclipse is designed base on OSGi model. And the OSGi model declaim it supports hot install and uninstall bundles. So I am confused why the Eclipse always need to restart to take a new install plug-in work. Is the OSGi model not that good or Eclipse not implemented the whole model?
The OSGi model works very well, but dynamics doesn't come for free. Bundle code needs to be written in such a way as to cope with services coming and going.
Eclipse has two problems. First there are an awful lot of legacy plugins that are not dynamic-aware and are written by frankly mediocre developers. Second, Eclipse has always shunned the services part of OSGi, instead favouring the "extension registry" with its a more static and clunky lifecycle (actually it's possible to handle dynamic updates with the extension registry, but much harder than when using OSGi services).
Actually in many cases Eclipse can dynamically cope with the addition of plugins, which is why the install dialog gives you the option to do this. But because of the variable quality of third party plugins, it plays safe and recommends a restart.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I started a job in a company where they use Maven in combination with Git. I haven't worked with Maven before and I hope my question isn't too stupid. Why should one use Maven in combination with Git? From what I read Maven has a local, a central and can have a remote repository where it can find it's dependencies. This should enable a team of programmers to work together on the same code. What is the purpose of Git here? Would it be possible to program in a Team just with Maven and without the help of Git?
Well maven and git are for different purposes:
GIT holds the sourcecode of your application
MAVEN is used for dependency management. It holds the binary dependecies of your application. It also creates a abstraction of the used IDE. One developer can use eclipse and another intellij. The project can also be built with the commandline.
I guess it would be possible to work with just Maven. It might even not be totally horrible. However, Maven is system for distributing releases (even if they are snapshots or whatever). It is a totally different tool, than what a version control software is. I guess you could say Maven is the just the "distributed" part without the "version control" part of DVCS systems such as git.
A real version control can do a lot of stuff Maven does not support directly, such as merging, diffs, commit logs. I'm sure it would be possible to build an actual, fully featured version control system on top of Maven, with suitable plugins, but it would be very klunky and awkward to use. The likes of git already do all this, and they have been designed to do it from the start, so they do it better than some hack on top of Maven could ever do, so I doubt nobody has actually tried.
I mean, you could do version control with just shared folder, naming conventions, manual log files, an IM group chat (irc channel) for synchronizing between developers, stock diff tools etc for comparing stuff, etc. It would just be horrible to use and very easy to "break" (in this case, easy to corrupt entire project and all its history). There has been a long evolution of version control systems, you can start reading about it for example here, and starting do it on top of Maven would be like jumping 30 years back in time.
When using Maven, your project's dependencies are well defined in pom.xml which is good for collaborative development as addition of dependencies doesn't require other developers to be informed as Maven automatically handles dependencies itself by downloading dependencies.
Git is used for distributed version control which is very good to keep track code changes in your project.
Basically, these two tools make collaborative development easy. However, this is just a crash course description, there are many of advantages.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have a dozen Java projects that depend on each other, and I frequently make changes that cross-cut all of them. However, many of the projects are libraries that could be used independently of each other as well.
Right now I use mercurial subrepos, which works well except that very few third-party tools support it - it's hard to set up code review tools, continuous integration, etc.
What's the best way to address this situation? Split everything into separate projects and build separate JARs? Migrate to git and use git subrepositories? Check everything in to a single repo and accept that I have to check out everything to use anything? Something else?
I would say the best way to do it would be to cut your dependencies so that they can reference as external jars. This way when you make potentially breaking changes you don't necessarily have to fix the affected areas straight away. Since they depend on a previously built jar it allows you to properly isolate your coding. If you use something like Maven to manage your dependencies you will also benefit from the ability to more easily keep track of the different versions of your jars.
If the subprojects are sufficiently autonomous, I would advise setting them up as separate maven projects with separate VCS repos.
This will give you the modularity you need paired with a working dependency management.