[jboss-jira] [JBoss JIRA] (DROOLS-709) fuse-bxms-integ list of build/release issues

[Geoffrey De Smet (JIRA)]

Geoffrey De Smet created DROOLS-709:
---------------------------------------

             Summary: fuse-bxms-integ list of build/release issues
                 Key: DROOLS-709
                 URL: https://issues.jboss.org/browse/DROOLS-709
             Project: Drools
          Issue Type: Bug
            Reporter: Geoffrey De Smet
            Assignee: Edson Tirelli
            Priority: Blocker


Here's a summary of the issues discussed in e-mail so we can track them.

1) fuse-bxms-integ violates Red Hat naming:
We can't use a product name ("Fuse", "bxms") for community code.
The repository contains community glue code between camel and kie,
so for example "camel-kie-integ" would be better.
Is drools-camel open source?
If yes, then we want the community to be able to use it and report issues before we release the product version.

2) The artifacts of fuse-bxms-integ all still use the groupId "org.kie",
but supposedly have their a different version numbering than org.kie's artifacts.
2 artifacts in the same groupId must use the exact same version numbering and release lifecycle!
So the groupId must be changed before its released.

3) fuse-bxms-integ will use it's own version numbering, so it should not use kie's "6.2.0.Final"
Either it uses a neutral number, such as "1.0.0.Final"
or it defines a pattern based on it's kie and it's camel dependency. For example "6.2.0.Final-2.14.1.Final" (bad example, violates OSGi guidelines).
Calling it "6.2.0.Final" is just asking for confusion and trouble,
because productization scripts will presume it's 100% equal to the kie version.

4) Now one seems to have the faintest idea how we'll handle branching: think camel 2.14.x, camel 2.13.x, kie 6.2.x, camel 2.12.x, kie 6.1.x, ...

5) // Not valid

6) Renaming the java packages according to the new groupId/artifactId we will choose (as we did in the past with all other projects) and also fix the OSGi manifest and features.xml files accordingly.

7) migrating the optaplanner-camel module in the new integration project.
Note: ge0ffrey will migrate optaplanner-camel after the other issues in this list are solved to avoid breaking users now.

8) It's artifacts are currently:
- no longer extending droolsjbpm-parent(-with-dependencies)
- no longer in the kie-bom
and that the repo is no longer in our github organization or git-clone-others script, but it is part of our release.
So it's already quite different than in 6.1.




--
This message was sent by Atlassian JIRA
(v6.3.11#6341)