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
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
My client has asked me to come out with a POC on Spring cloud contract as we are going to use this framework across global projects. I have followed the examples available online and documentation as well. However, I am having few questions.
if application hosted in different environments like DEV,STAG,PROD ..do we need to generate the stubs for all these three environments?
Is there way to store stubs to a repository using gradle script? So that I can download the stub to my local test environment from repository and test?
Sorry, I am very new to this framework and very much thankful for your answers.
If possible, please provide some samples for the above.
Thanks in advance
if application hosted in different environments like DEV,STAG,PROD ..do we need to generate the stubs for all these three environments?
It depends on your deployment strategy but in general, I don't think so. You can check my rationale in Spring Cloud Pipelines project - http://cloud.spring.io/spring-cloud-pipelines/single/spring-cloud-pipelines.html#_opinionated_implementation . If you want to do continuous delivery you just should create stubs for the current built version. That version will go through a deployment pipeline that would go via stage and prod.
Is there way to store stubs to a repository using gradle script? So that I can download the stub to my local test environment from repository and test?
You can use the classpath scanning - http://cloud.spring.io/spring-cloud-static/Dalston.SR4/multi/multi__spring_cloud_contract_stub_runner.html#_classpath_scanning . That way you set your Gradle build in such a way that you have the stubs on classpath. If you're referring to downloading a stub to run it inside a seprate proces you can combine this with Stub Runner Boot. Example is available here - https://github.com/spring-cloud-samples/github-analytics-stub-runner-boot-classpath-stubs/blob/master/pom.xml#L77-L88 . It's a Maven build but I'm sure that you get the idea regardless (this example registers stubs in Eureka and sends messages to a real RabbitMQ instance, of course you can remove these features if you don't need them).
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 7 years ago.
Improve this question
I am creating a website using asp.net mvc5 and I need to add one particular css and js file to a single page. My question is, what would be the benefit of creating a new bundle for a single css or js file? Or is bundling a single file bad practice, and I shouldn't do it?
The code below is what I mean by not bundling vs bundling a single file:
Traditional Method:
<link href="/content/css/foo.css" rel="stylesheet"/>
<script src="~/content/js/bar.min.js"></script>
Bundle Method:
bundles.Add(new ScriptBundle("~/bundles/bar").Include(
"~/content/js/bar.min.js"));
bundles.Add(new StyleBundle("~/content/foobundle").Include(
"~/content/css/foo.css"));
This question is in reference to bundling single files only. Like in my case, I am using a date-picker plugin that is only being used on one page in my ASP.NET MVC application, so it does not make sense to add the css and js files to my entire website bundle.
First, bundling is a once-and-done thing, so I wouldn't focus much on the performance cost of bundling. In other words, the first time the bundle is requested, it must be created, but each subsequent request just statically serves up the previously created file (assuming you don't change the bundle).
Is there value in bundling a single file? Well, that depends on that single file. How large is it? Is it already minimized? If it's a large, unminimized file then yes, there's very much value in bundling it as the bundle version will be a smaller filesize. It's more obvious of course with multiple files, as there you're not only reducing file size but also requests. However, I would still recommend that you always just use bundles. Like I said above, the cost of bundling is occurred only on the first request, which if you're truly concerned about it, could always be requested by you after you publish the site. Then, each further request is statically served until you change the bundle.
Its a valuable feature and much more valuable on a production environment. That being said, on the projects I'm on - we use the feature regardless of the number of files.
This SO answer is really good:
What is the benefit of ASP.NET bundling and minification in runtime?
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 8 years ago.
Improve this question
I'm in the planning stages for a new project involving eLearning and content management/delivery.
I've dabbled in Symfony2 before and I quite like it's flexibility and extensibility. But I have recently discovered EZ Publish is now running on the Symfony2 stack with version 5.
My question is, what does EZ bring to the table? Will it save me time and money in realising the end product? Or will it ultimately prove to be a hindrance if it is designed to be 'easy' rather than flexible?
Thoughts and suggestions are welcome :) Thanks for your time
It depends on how much of platform you will use for your custom logic.
If you will write most of code using Symfony components than you can use your bundles interchangeably in Symfony CMF, Symfony Standard Edition or EZ Publish.
If you want working CMS and write only handful of specific features independent of CMS functions than you can go with EZ Publish. But you still should write your code separated in bundles, so your custom logic is again nicely portable.
If you want to extend existing CMS features. Than you might want to go with Symfony CMF.
I would suggest to use Symfony CMF, which is the CMS for developers. EZ Publish is not totally migrated to Symfony, so you as a developer will still have to deal with legacy code. Also starting with Symfony Standard Edition to build a CMS you will have to build a lot of tools that are already built into Symfony CMF.
eZ Publish 5 brings you all the features you need when it comes to build a CMS based website. I'd say that 90% of the most important features from eZ Publish 4 have been migrated on Symfony2. You'll also get a really good admin interface.
eZ Publish 5 uses the full stack which makes a big difference when compared to others CMS like Drupal, especially if you need to build business features aside your CMS.
Also, the code quality of eZ Publish 5 is really good and tends to respect the last standards so you'll benefit from this choice one day or another : http://blog.insight.sensiolabs.com/2014/11/04/technical-debt-relevant-projects.html
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I have a lot of experience developing rich WPF applications (for CRM scenarios). I am a single developer and use Visual Studio with a TFS for revision control.
I have build a Framework which automatically takes care of the most basic tasks for me. To start a new (WPF) Application project all i have to do is:
create a new project
include references to my function libraries
defining the data structure in an XML file
inherit the new application Class from my custom Application class
My libraries include functionality for
backend creation and connection
a Main Window with user login and administrative/configuration options
custom controls
custom scheduling system for background task
etc. etc.
Every development step from that point out is specific to the current task/costumer/product. I can concentrate 100% on modeling and creating custom ui Pages for special purposes - an average project can contain as little as 100 lines of unique code. If i stumble over any reusable functionality whatsoever, i add that to my libraries.
I can deploy and update all Projects with literally one click. This enables me to handle many projects as a single developer.
My question is: how much of that "developing experience" can (I) translate to ASP.NET development.
I am uncertain of this because of the mix of technologies Javascript(jQuery)/HTML/VB.NET(or C#)
I am familiar enough with each of the languages and feel able to be working effectively with Servicestack after a little learning by doing.
But my biggest concern is: will I have just as much reusability as with my WPF development setup.
My biggest, dealbreaking-if-not-met goals are:
not ever "physically" copy any functionality - everything has to be linked from libraries
have a reusable "Main Page Layout/Setup" with login functionality - this also has to be in a library!
never leave Visual Studio as a Development environment
All my models/function libraries that i need to rely on (backend functionality and utility functions) are developed in .NET 2.0
Thank you very much for your input!
Edit for clarification:
I am not looking for the "Template" functionality of Visual Studio. I am well aware of this and using it where appropriate. This is not enough for me as changes/improvements/expansion of my libraries have to be reflected in all Projects - this also holds for the "Main/Start Page" functionality.
The built-in ASP.NET Templates from Visual Studio are actually a great example for what i do not want. They produce a very specific setup for your "new" application with a lot of autogenerated code - i.e. "physically copying" this code from a template to adjust to your needs.
What I want to do is every time when i start a new Project:
start on an "empty" ASP.NET Project
Create neccessary Cloud services (hosting/database/buckets) etc. in Azure (which VS incorporates very nicely)
include my needed libraries (that for example in turn include the neccessary servicestack libraries)
start modeling/designing specific needs for the new project
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 8 years ago.
Improve this question
We're developing an e-commerce application with Symfony2. It will have different features like product, sales, customer, shipping management, etc..
And it will have 3 subsystems: Web Frontend, Admin and a RESTful API.
Should we organize our bundles by features or by subsystems?
Well, it's your choice! Traditionally, if you explore the vendor bundles that Symfony comes with and the 3rd-party bundles that are available, they are organized by feature.
For example, the Sonata Project starts with a core bundle and provides features in each of the other bundles.
What you should be more concerned about when splitting your system up into bundles is finding a way to de-couple them from the other bundles so that they can be re-used in other projects with minimal modification but more configuration instead! Your best approach (just an opinion of course) will be to make all of these features individually in the bundles and tie them all together with another bundle.
You may find that answers will become subjective depending on each developer's view on the matter.
We've developed an e-commerce solution with Sf2 and at the beginning we asked ourselves the very same questions. Should we organize our bundles around entities or sub-systems(admin, front …) ?
We decided to go for the features/entities solution and we embedded the sub-system in the bundle.
What made us take this decision is the possibility to attach functionalities to the core feature.
For instance, we created bundles like product, catalogs, order, customer … these are the basic bundles that you will find in any e-commerce solution. We also implemented a core bundle that ties them up.
But some of our client may want to use more functionnalities/plugins like tracking, assets/images, reporting.
These bundles are optional and if we give our client the code of the application, I don't want him to get the code of unwanted/unpaid plugins. So the features are split up in different bundles and they're linked by interfaces and config files.
The bundles also carry the sub-system applications like the administration panel. If the client does not have the tracking bundle, then the administration panel will not show the tracking interface because it is not activated in the kernel.
I hope this will help you make you mind.
Per symfony's documentation you can organize bundles in any way you see fit. So long you stick to the coding convention, and overall good coding practices. Especially if you plan to release this bundle to the public (which might not be the case in this scenario).
That said, I would advice against organizing your project by features because the number of features will always increase over time; whereas the number of subsystems in your project is more than likely to remain constant.
Take in consideration that a new bundle, is a new sub-project to manage, if you're using other bundles or libraries like Assetic, then you would need to enable every single bundle in the configuration, so the bigger the number of bundles, the more difficult it is to manage the overall project.
So, if I were in your position, I would break up the system in subsystems. Create a bundle that exposes a RESTful API, another for the Admin, and another for the Front-end.
Structure them in a way that every bundle can live on their own, just in case you need to deploy every sub-system of your project to different servers, so that is just as easy as striping them out of the main project, and integrate them into a new one.