In worklight V6.1.0 and i see a new Project template as Shared Temlplates and i cant differentiate the use of the this provided by IBM and the normal import Existing Project into Workspace which is provided my the eclipse.
The final result is same and only the vendor and internal process are different
In eclipse we export it as the Generel->archive file and here we are just making it a template by (IBM Worklight->Worklight Project Template).
In eclipse we are importing it as General->Existing Project into Workspace and here we are just using Worklight Project->etc steps.
if there is any other difference please let me know?
IBM Worklight Project Template (Shared Template) enable you to accelerate the development of applications by not having to start from scratch. You can use Worklight project templates to provide value added services and you can add elements that are consistent with the look and feel of your brand.
And When we talk about exporting existing project into workspace then we don't have a choice of customization for e.g. certain elements like Company logo, company name etc. but in shared templates we have these capabilities, its totally customizable feature introduced in worklight 6.1
for more information please visit below link
http://pic.dhe.ibm.com/infocenter/wrklight/v6r1m0/index.jsp?topic=%2Fcom.ibm.worklight.dev.doc%2Fstudio_ext_assets%2Fc_wl_project_templates.html
Application Component:
Application components are reusable libraries that you can add to the applications you develop. An application component can be a client-side library or a server runtime block. Typical libraries might handle basic functions such as login or payments. They can also contain various elements such as non-visual runtime objects, visual components, integration adapters, and user interface screen packages.
For more information please visit below two links
http://pic.dhe.ibm.com/infocenter/wrklight/v6r1m0/index.jsp?topic=%2Fcom.ibm.worklight.dev.doc%2Fstudio_ext_assets%2Fc_application_components.html
Related
I have a solution that consists of 5 projects (ASP.net Core Webservice and dlls). For this solution I want to create a setup using WiX. I'm working with Visual Studio 2019.
The solution is located in a Git repository in Azure DevOps.
There is already an automated build process that is executed after each pull request.
I want to extend this process (or create an additional one) so that the setup is also created automatically after the build.
Should I add the setup as another project to the existing solution or should I create a separate solution?
I don't have any experience with creating build pipelines in AzureDevOps yet, so I'm afraid that I might run into problems there later if I choose the "wrong" variant now.
What are the advantages and disadvantages of the two variants?
Are there best practices for when to use which?
This is a matter of personal choice but after 20+ years of installation development I prefer two solutions. The reasons are:
Pros:
It helps organize the repos to have Application code and Installer code.
Application developers don't have to have WiX installed. Projects won't fail to load in the application solution.
The application sln can be updated to a newer version of Visual Studio without waiting for the installation toolset to support the new version. This has historically been an issue.
Project dependency / project build order issues are moot because all application projects will build before any installer projects will.
Application developers don't have to worry about installer developers messing up their projects.
Because the projects are in different solutions you can't use project references which can be tricky and brittle.
Building application first and using postbuild file copy commands to create a model helps define what the installer should look like.
Installation projects frequently have to consume files from projects that may not even use visual studio at all or a combination of both.
Cons:
Separating the code can lead to an "us vs them" situation between application developers and installation developers. However this can be mitigated by creating a clear understanding of roles and responsibilities. Nothing stops developers from being aware of and contributing to either solution.
A solution is a container that's used to organize one or more related code projects, for example a class library project and a corresponding test project. We'll look at the properties of a project and some of the files it can contain. We'll also create a reference from one project to another.
So if the WIX project relates to other projects in this solution, then add this setup as another project to the your existing solution.
I am new to java, osgi, bundles, cq5 console etc..
Can someone please point me to a tutorial or a starting point from where I can learn how to do what I am trying to achieve.
Basically we have common search functionality in 3-4 CQ5 websites, all of which reside on a single cq instance. This same functionality is implemented in all websites as a servlet and is called from client side using javascript. Redundant code....
We would like to:
a) take this servlet's code out from all the websiteName-core bundles where it resides repeatedly as of now.
b) create a single separate standalone installable OSGI bundle which only contains a servlet.
Then we would like to call this single separated out bundle from all our CQ5 websites's client side.
Aprt from code redundancy, we wish to make this common search bundle shippable so that other development teams can use it in their projects by just installing it in their console and calling the servlet.
Long story short. I want to create an OSGI bundle that has a servlet.
I wish to have an understanding of the whole game here and would prefer to get a tutorial link that explains it from start to end.
You can start by turning the search code into a separate maven multi module project.The archetype and instructions for creating one can be found on adobe's documentation site (link)
The maven multimodule project will have two module's Bundle and content. Bundle will hold all the servlets, OSGI services and back-end stuff. The content module will have all the UI and authoring related stuff like templates and components. It maps to the repository on the CQ server. The UI nodes are serialized and stored on flat file systems as XML documents.
Since it is a maven project on it's own, it's dependencies will be self contained. In the bundle module add the search servlet and all the required classes. The compiled package of this project will be shippable.
As long as the package is installed in the server, any other website will be able to make calls to it.
Servlets in sling are implemented as OSGI services of javax.servlet.Servlet class. Any exported service of the Servlet class will be recognized by the sling servlet resolver, You can get more details of it at this link
Sharath Madappa's answer is correct if you want to create a set of related bundles and distribute them as a CQ content package.
If you just want to create a single bundle to package some OSGi services (including servlets) you just need to build the bundle jar with the required metadata. The Apache Sling GET servlets bundle is a good example of that.
Eclipse has projects, what's the purpose of the Workspace that appears to group projects? Projects could live in the directory tree isn't that a more natural way of organizing different projects?
When you first start up Eclipse not knowing much about it, it feels like an unnecessary layer of bloat that new users have to get accustomed to first. You're forced to set up some organizing structure that, although specific to Eclipse, wants to live in the rather general-sounding place ~/Workspace.
The workspace is a collection of projects and the metadata that cannot be included in a project because it's not portable (references paths and resources on a specific system) or because it pertains to Eclipse as a whole.
Without the workspace concept, opening a project in Eclipse would be followed by multiple steps of getting things configured. This information would be lost when Eclipse is closed or all projects you ever work on would have to share the same configuration.
Examples of metadata stored in workspace:
Locations of available JDK's and JRE's. The project references a JRE by name, the workspace metadata is needed to resolve that reference.
Locations of application servers.
Path variables.
Open perspectives, layout of views, etc. Consider one application where you need Git and app server vs another application where you need SVN and Android development tools. The views you'd want to keep open and how you'd arrange these views would be very different for two applications.
I'm working on an Eclipse rcp application which is using a middle layer to request data. I want to run my application in offline mode i.e. if data service is not available I should be able to work on some dummy data. For this purpose I want to exclude/ include extensions (not extension points but extension point providers). Is that possible?
Thanks
If you put the live and test versions of the extension point implementation in different plugins you can then choose which plugins to include in the product build - so you would have two product configurations, one for testing and one for production. When you are testing in Eclipse you can configure the plugins to include in the Run Configuration, so again you would have a test and production configuration.
It might also be possible to use a plugin fragment to contain just the part which varies. Use New / Project / Plug-in Development / Fragment Project to create.
I have created a Netbeans Platform Application and deployed it (created installer / zip bundle etc.). I have also made provision for extension points by creating Interface modules in the application (is this the correct way?).
Now my question is, how do I write modules to extend this application, without having to depend on the source of the application. For example, I want to write a module that implements one of the interfaces. How do I create a new module project that does this, and how do I get the Platform Application to include / find this new module.
I am trying to write an RCP application using the Netbeans Platform Application architecture. I want to be able to make it extendible (via interfaces) WITHOUT having to expose the source to 3rd party developers. I do intend to publish the source, but from a design perspective I want it to be functional enough that people don't need to have the source to write plugins for the application.
Found out how to do it. You can do it with the normal Java service discovery methods. Add a file under META-INF/services/ with the same name as the interface you are implementing, and in the file put the name of the class. Both have to be the FULLY QUALIFIED name of the class.