Currently we have a single monolithic WSO2 project containing all the sequences corresponding to all the pipelines that we have built. We want to break this into multiple different independent modules. For this purpose we want to create a common library project which will contain all the common sequences and other components which are shared across all these modules.
Any suggestions/ideas on how to achieve this project structure?
My WSO2 Integration Studio version is 7.1.0
You can create a Maven Multi-Module Project in the integration studio and within this, you can create multiple projects. Within this project, you can create multiple Integration Projects to contain common artifacts and unique artifacts.
You can refer to the resources available in [1] and [2] to further clarify this. Further please refer to the article [3]. Here the Multi-Module Project is used to maintain artifacts for multiple environments by separating the artifacts into common components. You can use the same concept to separate the artifacts in your environment.
[1]-https://www.youtube.com/watch?v=058QBFbVSB8&feature=youtu.be
[2]-https://ei.docs.wso2.com/en/7.0.0/micro-integrator/develop/create-multi-maven-project/
[3]-https://wso2.com/library/articles/2015/10/article-wso2-developer-studio-development-and-deployment-best-practices/
Related
When I try to launch my SeedStack application, I get the following error:
org.seedstack.seed.SeedException: [CORE] Multiple seedstack launchers
Description
-----------
There are multiple SeedStack entry points in the classpath.
Fix
---
Exactly one class implementing 'org.seedstack.seed.spi.SeedLauncher' should be present in the classpath and registered in
META-INF/services. Remove all but one launcher.
What is the cause of this and how can I fix it ?
A SeedLauncher is used to launch a particular kind of application (Web app, CLI app, ...). A SeedStack module can only be of one kind at a time.
The error above occurs when you have multiple active implementation of the SeedLauncher interface in your classpath. By active I mean present and registered as a service in META-INF/service.
The most common cause is when you have the seed-web-undertow and the seed-cli dependencies in the classpath at the same time, as both provide their own implementation of SeedLauncher.
You have to choose if your module should be a CLI application or a Web application and remove the useless dependency. If you want to build both kinds, you'll have to separate them in different modules.
Some add-ons can also provide launcher which can interfere in the same way. If the quick solution above doesn't resolve your problem, use your IDE to find all implementations of the SeedLauncher interface and re-organize your modules to have only one launcher per module.
I have a pythonic serverless project on AWS, in which several services are contained in a single repository (a monorepo) which looks like:
/
serverless.yml
/service1
lambda_handler.py
/service2
lambda_handler.py
/general
__init__.py
utils.py
'general' is a package that is shared between different services, and therefore we must use a single 'serverless.yml' file at root directory (otherwise it won't be deployed).
We have two difficulties:
A single 'serverless.yml' may be too messy and hard to maintain, and it prevents us from using global configuration (which may be quite useful).
Deplyoing a single service is complicated. I guess that 'package' feature may help but I'm not quite sure how to use it right.
Any advise or best practices to use for this case?
Its better to use individual serverless.yml files per each service. To use the shared code,
You can convert the code into a library and use it as a dependency and installed via a package manager for each individual service similar to a library. (This is useful since updating a version of common code won't affect the other services)
Keep the shared code in a different repository and use git submodule for individual service.
For more information, refer the article Can we share code between microservices which I have originally written considering serverless.
I am trying to improve our general automation process. We use VS2012 and TFS2012.
Here is what I want to happen upon checkin to our CI branch:
BUILD
Build the selected projects / solutions as configured in the build definition settings.
Generate a deployment package that can be used to deploy the websites (without having to rebuild the entire project again)
Generate a nuget package that can later be published (without having to rebuild the entire project again, i need the dlls to match the symbols created from indexing so we can debug them)
TEST - IF AND ONLY IF BUILD WAS SUCCESSFUL
Run all configured unit tests.
DEPLOY - IF AND ONLY IF ALL UNIT TESTS PASS This is to prevent breaking changes entering our development environment
Take deployment package from (1.2) and publish it to it's intended environment (hopefully configured using Publishing Profiles and transforms)
PUBLISH - IF AND ONLY IF ALL UNIT TESTS PASS
Take nuget package from (1.3) and publish it to our private nuget gallery
I don't need a full tutorial (although that would be awesome) for the entire process, but more how to go about integrating it.
For instance:
Should I use msbuild on a wrapper project?
How do I deal with creating the packages upon build on the TFS build server?
How can I enforce the "IF AND ONLY IF ALL UNIT TESTS PASS" constraints?
What is the best / easiest way to perform the deployment /publishing after as part of the build.
This is the process we want to use and any help is realising this is very much appreciated.
And I'm sure many other people are interested in how to set about integrating this style of process.
Also if it's relevant most solutions have a mix of shared dll projects, websites / apis, and unit tests. One of the reasons I want this process is to be able to split them up and modularise our large dlls into smaller isolated units, which would be to unmanageable ATM without this auto publish mechanism.
Thanks,
Gary.
BUILD Build the selected projects / solutions as configured in the build definition settings. Generate a deployment package that can be
used to deploy the websites (without having to rebuild the entire
project again)
This is out of the box, add deployment profile to your projects, call them 'Release'
Add the following to your MSBuild Arguments
/p:DeployOnBuild=true;PublishProfile=Release
you don't have to use Release, as long as your Publish Profiles match what you put in the MSBuild arguments
This will generate the deployment files as part of your build (MSDEPLOY)
Generate a nuget package that can later be published (without having to rebuild the entire project again, i need the dlls to match the symbols created from indexing so we can debug them)
See Nugetter on code plex http://nugetter.codeplex.com/
TEST - IF AND ONLY IF BUILD WAS SUCCESSFUL Run all configured unit
tests.
Should be out of the box, but you can change the build template to fail the build should compilation be unsucessful, if this suits your needs better.
DEPLOY - IF AND ONLY IF ALL UNIT TESTS PASS This is to prevent
breaking changes entering our development environment Take deployment
package from (1.2) and publish it to it's intended environment
(hopefully configured using Publishing Profiles and transforms)
PUBLISH - IF AND ONLY IF ALL UNIT TESTS PASS Take nuget package from
(1.3) and publish it to our private nuget gallery
See Nugetter on codeplex as listed above
A little over a year ago I posted a question about splitting a build into multiple outputs and followed the recommended solution. Now I need to build on this a little. This solution contains three projects that produce deployable bits and then some other projects that contain code common to the deployable projects (business logic and data access type stuff). Of the three deployable projects, two of them are windows services and one is a wcf webservice. I can build all of these locally fine, but when I build this on our build server things get a little strange.
When I build my webservice project locally I get a folder structure like this:
-Published Websites
Service file
Config file
-Bin
Service DLL’s
This is the desired output for the webservice, however I don't want to build locally. When I originally built on the build server everything was getting jumbled together like this:
-Published Websites
Service file
Config file
-Bin
Service DLL’s
All windows service exe's
All DLL's needed by the service exe's
I followed the suggestions in the article linked at the beginning of this post. In a nutshell I made a change to the build template and also tweaked the output path in the project files. This resulted in my build output looking like this:
Build Folder
-WIN SERVICE 1
EXE’s
DLL’s
-WIN SERVICE 2
EXE’s
DLL’s
-WEBSERVICE
DLL’s
The problem here is that the folder structure for the webservice is not intact (the svc and config files and the bin folder are all missing). I need this structure as I don't deploy directly to the webserver, we use a staging location. I'd rather not split the webservice into its own solution as it is logically related to the windows services and all the common code in the solution.
So, the big question is how do I set up a build that can output multiple directories, but one of those directories is a webservice and it contains the appropriate files and directory structure?
The only Solution I've been able to come up with is to have two different builds for this solution. One builds the webservice and the other builds the windows services. This allows me to keep the the solution together. We'll just have to remember to run both builds when common code changes.
Any suggestions/refinements to this solution are welcome.
I have a list of Jenkins jobs that are independent, but it would be convenient if I could group them together to have them all run with the click of one button. Each of the projects is concerned with deployment, not compilation.
I've found the bulk-builder plugin, but to use bulk-builder it's necessary to specify a pattern each time you wish to invoke it.
I'm looking for a Jenkins plugin that will allow me to group projects together, and the Maven system seems to suggest this is possible: I'd make a top level build job that sets up dependencies on each of the jobs I wish to run, then I'd just need to run my top level job.
If possible, has anyone found Maven to be useful in managing dependencies of anything but Java? Would I be able to use it in the way I'm expecting?
EDIT: These are all .net projects
In jenkins, you can explicitly define other projects to build upon a successful build (search for downstream). This way, you can have one project trigger bunch of others effectively grouping them.
Maven is a great tool but I wouldn't use it for this purpose.