My current situation is that I have about 20 different Eclipse product configurations for an RCP-Application, which contain different features. But all configurations share, for example, the same JVM-Args.
The obvious problem here is, that if the JVM-Args change, I have to change them in every single product file.
Now my question: is there a functionality to centralize or generalize identical configurations across multiple product configurations?
Related
I have three solutions. One is a schema solution that only has a schema File in it, lets call it the SchemaSolution.
The SchemaSolution is referenced in my other two solutions because the Solution1 creates xml instances of the schema in the SchemaSolution and drops it as self-correlating in the message box.
This works magically but if I want to update one of the solutions where the SchemaSolution is referenced (deploy to BizTalk) I always have to delete the other solutions. This is horrible and I was not able to find a solution until now.
Is there a (no hacky) way? I thought about merging all Projects into one solution, but this is the worst case scenario I can imagine to achieve my goal.
How can I deploy a project that is referenced in different solutions without deleting and redeploying everything?
BizTalk 2013R2 in use
No this is not supported and not recommended to try and hack your way into this idea (definitely need to alter the BizTalk database, and this is not even allowed by Microsoft i think).
I can give you 3 options:
Make the SchemaSolution as small as possible, like break it down into multiple schema solutions per process for instance, so the chances of you needing to change the solution will be smaller. Ideally, in this solution you would have 1 assembly/project per schema, so new schema's can be added without redeploy.
Another option would be to duplicate your schema's into your projects, this is a design choice you could make, but would require some more work as you need to specify schema's in your pipelines (or else it doesn't know which one you mean), and you have double work with changing the same schema's in multiple projects. The downside is, the schema's are not the same to BizTalk so you can't use it in another project without reference.
Your final option would be to get rid of the dependency of that schema completely, you can do this by creating your own internal/generic/cdm schema, which ideally would be more robust and less prone to changes. This schema would still be referenced by multiple projects, but since you're the one in charge of it, you can predict and mold it into your likings. Again, ideally, in this solution you would have 1 assembly/project per schema, so new schema's can be added without redeploy.
I have a very similar (if not the same) issue within a solution.
I have a set of integration projects dependent on a simple schema project. If I deploy one integration project, I must deploy the schema project, which means I must deploy all integration projects!
In order to deploy them independently, I simply turned the redeploy flag from true to false within properties (in VS) of the schema project..
This allows me to redeploy as many other dependent projects as I like without having to delete or mess around. I can deploy a single integration project with no effect on the others.
The only caveat, is when you redeploy, for some reason, VS flags the fact you have set redeploy to False on the schema project as an error and says that one of the projects was not deployed.
Not a true error, more of a warning imo.
I have been doing this in BT2016, I would assume you can do the same in 2013
I have an application I am trying to experiment with. The business rules I am trying to create are all related but it makes sense for me to group the logic by drl file. For example, I want to put information about customers in the customer.drl file. I want to put logic about the categories of product in the productCategory.drl file and purchases.drl. Finally, I'd like to have a fourth file summarizing my findings for a report.drl
I don't want to create entirely separate modules. I just want to split out the logic so that I can easily maintain the logic in the code. In effect, I'd like something like this:
src/main/resources/rules
customers.drl
purchases.drl
productCategory.drl
reports.drl
I want to be able to share the logic between the facts in a single KieSession, utilizing all the drl files. First, I want to insert customer facts, group them by demographics, then insert their purchase information and products purchased and categorize them. Finally, I want to aggegrate that data in a report by inserting the previously gathered facts to generate data from the reports.drl
Is the configuration, I'm showing a feasible way of doing it. I'm of course assuming that the KiesSession will pick all the drl files in the rules package if I use a classpath container.
Is this the right way?
Looking at the documentation, I can group related rules under the same package. It is one of the options available. So for my use case this works. According to the documentation, I can create a kmodule.xml, and indicate the package, use a classpath container and load the KieSession. If I use a default kmodule definition with no KieBase defined, it will use a default KieBase and load all the resources in the src/main/resources and its other subfolders and this works!
We have a small group < 4 but work on several different applications that we support. Each application gets its own Git repo, but as for managing the effort I really don't want to setup a separate team as well for each product.
Questions:
- For a small group working on several different products (eg. websites, services, utilities etc), can a single "team" within one project allow us to work on 2 sprints at the same time that are within different area paths?
- If I have already defined multiple teams, can I migrate all the content into the backlog of a single team?
- Assuming one team and multiple area paths, the project "hierarchy" would look something like this, correct?
Project
|__Team
Area-1
|__Sprint 1-n
Area-2
|__Sprint 1-n
Area-3
|__Sprint 1-n
[ update ]
On further inspection looking at the docs, the iterations can have their own paths. It seems that if we want to manage 2 or more simultaneous sprints or overlapping sprints that involve different products, it makes sense to go ahead and configure a team per product or possibly one team per "business area" (eg. Sales, Operations, Warehouse etc). Within a business area, our group would only have 1 active sprint at a time, which seems straightforward, compared to trying to manage multiple sprints within the same team.
https://learn.microsoft.com/en-us/azure/devops/organizations/settings/set-iteration-paths-sprints?view=azure-devops
So the better approach might be multiple teams, with one (default) area per team and a iteration list for each team.
The Team's areas and the Team's iterations are disjointed. I would think you could assign the different product areas (websites, services, utilities) to the team but then have just a single iteration list instead without trying to segregate the iterations by area. This won't work if the sprint dates for the different areas are different, but if they are different I don't think any approach you try to leverage in app will work.
Areas:
Sandbox
|__Team
|___Websites
|___Services
|___Utilities
Iterations:
Sandbox
|__Sprint 1
|__Sprint 2
|__Sprint 3
I don't think you will get to a good solution if the different product areas have different start/end dates for the sprint even if you could make something workable using the tool.
An RTC source control component as I see it is a logical grouping of files & folders.
When should I use multiple components within a stream in RTC source control?
Method 1:
I have multiple java(Eclipse) projects but I am adding these projects to just one component within a single stream. These projects are packaged into one deployment file.
Method 2:
Each java project be added to its own component within the stream, so the stream will contain multiple components - one component for each java project.
Are there advantages/disadvantages to using one method over the other ?
An RTC component has really the same meaning than an ClearCase UCM component.
The goal, when using multiple component, is to divide your huge set of files into coherent and logical subsets, more identifiable and manageable.
Example of components:
an application (or a autonomous part of an application)
a technical library
a packaged set of file (for release)
Note: in RTC, you can reuse a component (defined in one project area) in another project area (provided both PA are on the same Jazz server).
A Java project can be represented as one component, but certain Java project could be seen as several components (one for the business logic, one for database logic, and so on)
The main criteria when you define a component is:
Will it evolve at its own pace? Can you modify it without having to modify another component?
(If not, that might mean the two set of files are tightly linked, and might be considered as one component).
From there, you must decide if you want to see all components on one Stream (system approach, with every component writable), or just one or two components per stream (depending on the deliveries - dll, jar, ... - produced by the other components): component approach.
For starter, stick with the system approach, simpler at first.
I work on two products, each residing in its own CVS module; call them B (Base) and D (Dependent). D is dependent on B; B can exist on its own. Typically I want to have them together in my IDE environment so that I can e.g. follow API calls from D to B in the editor and debugger. These products are on distinct release schedules; a given branch/tag of D is dependent on a specific branch/tag of B. At any given time, I may be working on several different B/D branch/tag combinations.
I'm an Eclipse noob, but I believe what we are talking about here is multiple workspaces, one for each B/D combination, and each with projects for B and D. I need to be able to create these workspaces relatively quickly, without starting completely over each time, and in such a way that the environment does not vary across the workspaces, except of course for the fact that the branch/tags are different.
So: What do I have to do in Eclipse to accomplish my goals here? Thanks in advance...
Mark
You can use separate workspaces, but creating a new workspace for each new B/D combination seems a bit impractical.
I am in a similar situation, although I probably have less combinations. I use a single workspace where I check out each branch when I need it. You can safely check out multiple branches in Eclipse, as long as each project name is unique. I add a branch tag after the project name when I check it out so I can easily identify the correct version.
When I'm working on one combination of projects, I close the all other projects that I checked out earlier so I don't edit the wrong version by mistake. The only thing that you have to adjust manually each time is which dependent project you will be working on in your project's classpath and run configuration.
Alternatively, if you still would like to use multiple workspaces you can try creating a new workspace folder and copying the .metadata folder of an existing workspace to it. This will copy your workspace settings. The only drawback is that you have to remove all project references after startup since they won't exist in your new workspace.