[rules-dev] The droolsjbpm repository split-up and directory structure changes - PLEASE READ

Michael Anstis michael.anstis at gmail.com
Wed Feb 9 11:34:42 EST 2011


Where will 5.2.0.M1.x live?

It won't be put back into SVN nor will it be migrated as part of the
split-up.

Does this mean 5.2.0.M1 will be lost forever and we'll effectively re-branch
after the split-up is complete to give a 5.2.0.Mx?

Given 5.2.0.M1 hasn't been officially announced I wonder whether it'll be
most pragmatic to re-branch 5.2.0.M1 after the split-up and announce that as
the M1 release? Or we skip straight to M2?

On 9 February 2011 15:20, Geoffrey De Smet <ge0ffrey.spam at gmail.com> wrote:

>  An update with a little bit of bad news.
>
> It's impossible to meaningfully migrate the branches into the split-off
> repositories.
> The reasons are:
> 1) the build on those release branches won't be able to cope with being
> split-off, unless I manually fix them one by one (= big changes, very
> impractical)
> 2) the git command to split-up the repository doesn't support it if a
> split-off repositories contains multiple directories.
>
> *So, branches/tags will not be migrated to the split-off repositories.*
> All history of master will be migrated.
>
> The 4 topic branches (lr_unlinking_20101116, ...) will need to be manually
> migrated by their owners. Sorry.
> The monolithic droolsjbpm git repository will be kept around for a short
> time to give them the time to do this.
>
> The 5 community release branches (up to 5.1.x) will be moved back to
> subversion (to rejoin their SOA release branch brothers),
> so we can remove the monolithic droolsjbpm git repository before it causes
> to much confusion.
> The community release branch 5.2.0.M1.x will be lost.
>
> HTH
>
> Op 07-02-11 13:06, Geoffrey De Smet schreef:
>
> Hi guys,
>
> I 'll be doing some changes that will *force you to delete your git
> working directory and all your git forks*.
> I am sorry to put you through this, but it will make development life
> better afterwards.
> Contact me if the dates don't work out for you. Suggestions, ideas are
> still welcome of course.
> Please forward this message to any droolsjbpm developer not reading the
> mailing list.
>
> *Please do not make any build changes in the next 2 weeks, because those
> changes might be lost.*
> Mail me the build changes and I 'll do them for you and make sure they
> aren't lost.
> What will change?
>
>    - We ‘ll split up the monolithic droolsjbpm repository into a few
>    smaller repositories.
>       - We will preserve history per repository.
>       - The droolsjbpm repository will be retired but not deleted.
>       - Your guvnor clone won’t take 1.2 GB diskspace anymore.
>    - We ‘ll split up the monolithic build into a few smaller builds (one
>    per repo).
>       - You’ll be able to build/test just guvnor.
>          - Even if drools-core doesn’t build/test.
>        - We ‘ll split up the monolithic hudson job into a few smaller jobs
>    (one per repo).
>       - If the drools-eclipse guys break a test, the guvnor job will still
>       be blue (and vica versa), only the drools-eclipse job will be red.
>       - The build will be broken less and the cause will be easier to
>       identify and fix.
>       - Hudson won’t be red all the time anymore.
>    - We ‘ll make some directory name changes, so artifactId’s are less
>    confusing and more correct
>       - For example: drools-server (which has nothing to do with the
>       guvnor server) will be renamed to drools-camel-server
>    - We ‘ll clean up some general things, like file endings, etc
>
> New repository’s We will end up with these repositories after the split-up
> is completely done:
>
>    - repo droolsjbpm-parent
>       - The parent pom (common stuff for the build)
>    - repo droolsjbpm-knowledge
>       - The public API and the internal API
>    - repo drools
>       - The rule engine modules
>    - repo jbpm
>       - The workflow engine modules
>    - repo drools-planner
>       - The planning optimizer modules
>    - repo droolsjbpm-integration (groupId org.droolsjbpm)
>       - Integrating Drools & jBPM with Seam, Spring, Camel, etc
>    - repo guvnor
>       - The web app to manage Drools & jBPM repositories
>    - repo droolsjbpm-eclipse
>       - The eclipse plugin for drools & jbpm
>    - repo droolsjbpm-dist
>       - Installer, aggregated assemblies, ...
>
> New structure guidelines
>
>    - Docs and examples
>       - Must be updated together with the main and test code => same pull
>       request!
>       - Are in the repo that provides their functionality
>       - Are build (if fast enough) together with the rest
>          - docs might be slow, we ‘ll see if we need to only do them in
>          the -Dfull build
>
>
>    - We prefer long repo names, because
>       - Project dirs must much artifactId<http://java.dzone.com/articles/maven-tip-project-directories>
>       - Forking “eclipse” on github to myUsername would confuse (as it’s
>       not eclipse but droolsjbpm-eclipse) and clash with eclipse itself.
>          - Not https://github.com/etirelli/eclipse but
>          https://github.com/etirelli/droolsjbpm-eclipse
>
> New dir structure
>
>    - repo droolsjbpm-parent (groupId org.droolsjbpm)
>       - This contains one pom, which is the parent pom for all the general
>       build stuff.
>       - artifactId renamed from drools
>       - Includes shell script (and maybe bat script) to clone all of these
>       repo’s
>       - droolsjbpm-bom ? - TODO research bill of material poms
>    - repo droolsjbpm-knowledge (groupId org.droolsjbpm)
>       - knowledge-api
>          - renamed from drools-api
>             - GAV backward independency => TODO document
>          - groupId org.droolsjbpm
>       - knowledge-internal-api
>          - empty for now, will be filled by markp, krisv, etc
>       - TODO later one day: knowledge-core
>          - extracted from drools-core
>       - TODO later one day: knowledge-builder
>          - extracted from drools-compiler
>       - TODO later one day: knowledge-persistence
>          - extracted drools-persistence-jpa
>       - droolsjbpm-introduction-docs
>          - renamed drools-docs-introduction
>        - repo drools (groupId org.drools)
>       - drools-core
>       - drools-builder
>          - renamed from drools-compiler
>       - drools-persistence
>          - renamed drools-persistence-jpa
>       - drools-jsr94
>       - drools-clips
>       - drools-templates
>       - drools-decisiontables
>       - drools-verifier
>       - drools-expert-docs
>       - drools-fusion-docs
>       - drools-expert-examples
>          - renamed from drools-examples-drl
>       - drools-fusion-examples
>          - renamed from drools-examples-fusion
>        - repo jbpm (groupId org.jbpm)
>       - will be moved from the krisv github account to the droolsjbpmgithub organization
>       - no other changes for now
>    - repo guvnor (groupId org.drools or org.droolsjbpm.guvnor or
>    org.guvnor)
>       - guvnor-repository
>          - renamed from drools-repository
>       - guvnor-repository-jcr-connector
>          - renamed from drools-repository-jcr-connector
>       - guvnor-repository-jackrabbit-connector
>          - renamed from drools-repository-jackrabbit-connector
>       - guvnor-repository-modeshape-connector
>          - renamed from drools-repository-modeshape-connector
>       - knowledge-ide-common (TODO)
>          - renamed from drools-ide-common
>          - eats drools-factconstraint (esteban working on that)
>       - guvnor-api?
>          - TODO needed?
>       - guvnor-gwtclient
>          - extracted from drools-guvnor: all the GWT stuff
>       - guvnor-webapp
>          - renamed from drools-guvnor
>       - guvnor-examples
>          - renamed from drools-examples-brms
>             - currently disabled, might be removed and rewritten from
>             scratch
>           - guvnor-docs
>          - renamed from drools-docs-guvnor
>       - guvnor-modules
>          - moved modules (under drools-guvnor)
>          - includes bulk-import-util
>             - TODO later: remove the module and get the feature as a
>             button in the GWT gui
>           - repo droolsjbpm-eclipse (groupId org.drools - might be changed
>    over time)
>       - org.drools.eclipse (might be changed over time)
>       - org.drools.eclipse.task (might be changed over time)
>       - org.guvnor.tools (might be changed over time)
>       - org.drools.updatesite (might be changed over time)
>    - repo droolsjbpm-integration (groupId org.drools or
>    org.drools.integration)
>       - drools-camel
>       - drools-camel-server
>          - renamed from drools-server
>       - drools-pipeline
>          - (deprecated)
>       - drools-seam
>          - drools-seam2
>             - TODO do we want to keep this?
>          - drools-seam3
>       - drools-spring
>       - drools-ant
>       - drools-maven-plugin
>       - osgi-bundles
>       - drools-rhq-plugin
>       - drools-simulator
>       - drools-grid
>       - drools-rhq-plugin
>       - knowledge-integration-docs
>          - renamed from drools-docs-integration
>        - repo drools-planner (groupId org.drools.planner)
>       - drools-planner-core
>       - drools-planner-examples
>       - drools-planner-docs
>          - renamed from drools-docs-planner
>       - drools-planner-assembly
>    - repo droolsjbpm-dist (groupId org.droolsjbpm)
>       - Assemblies? Or per repo?
>          - Per repo, but make src etc here
>       - TODO later: uber documentation?
>       - install-stale
>          - renamed from install because it’s been moved into jbpm.
>
> Implications: a very disruptive change
>
>    - Difficult copying patches to 4.x, 5.0 and 5.1...
>       - But not impossible, as I 'll first all directories to the new
>       repo, before renaming them
>          - so the old release branches/tags will still have the old
>          directory names
>           - and git is suppose to be able to deal with directory name
>          changes of branches
>            - Some Maven GAV (groupId, artifactId’s) change
>       - Everything will be documented in the release notes
>
> While we’re freezing anyway:
>
>    - Before the move:
>       - Simplify & stabilize build
>          - Simplify javadocs generation
>             - keep groups if possible, but not required
>           - Before pushing the moved part into a new repo:
>       - [Guvnor] Remove all the generated GWT files from the history
>          - because it smaller repo makes a faster clone.
>          - $ git filter-branch --tree-filter
>          '~/removeGeneratedGwtScript.sh' --all
>             - TODO check removeGeneratedGwtScript.sh vs
>             https://github.com/droolsjbpm/droolsjbpm/blob/5.0.x/drools-guvnor/build.xml
>             - rm -f src/main/webapp/org.drools.guvnor.Guvnor/**/*.gwt.rpc
>             - rm -f
>             src/main/webapp/org.drools.guvnor.Guvnor/**/*.cache.html
>             - rm -f src/main/webapp/org.drools.guvnor.Guvnor/**/*.cache.js
>             - rm -f
>             src/main/webapp/org.drools.guvnor.Guvnor/**/*.cache.xml
>           - Before allowing others to touch the new repo:
>       - All line endings to \n (unix), except *.bat files
>          - https://issues.jboss.org/browse/JBRULES-2855
>       - All \t (tabs) in *.java files replace by 4 spaces
>          - all \t (tabs) in *.xml files replace by 2 spaces
>       - All copyright should start with /* and not /** because a copyright
>       is not a valid javadoc.
>       - Strip the @author from each *.java
>          - It’s not accurate at all anymore (=bitrot).
>             - Actually, most of the time it’s the original author, not the
>             current guy who currently knows what it does.
>             - Git history is much, much more accurate.
>                - Statistics generated by ohloh and github.
>                - Git can distinguish the author from the committer
>              - Credit is given on the team page and the blog.
>             - These pages are actually read by outsiders.
>             - Contact me to improve your entry on the team page. Don’t be
>             shy.
>          - Motivation (must see video): How to get a healthy open source
>          project?
>          http://video.google.com/videoplay?docid=-4216011961522818645#
>
>
> How will this change happen?
>
>    - I'll split-off drools-planner tomorrow 8-FEB-2011
>       - To flesh out the split-up process.
>       - I don't think anyone forked and changed these modules.
>        - I'll split-off droolsjbpm-eclipse Wednesday 9-FEB-2011
>       - I don't think anyone forked and changed these modules.
>        - I'll probably split-off guvnor Friday 11-FEB-2011
>       - *Get your guvnor fork changes merged into master by Thursday
>       10-FEB-2011.*
>       - Contact me if this date is a problem.
>        - Other splits-off will be announced later.
>
> --
> With kind regards,
> Geoffrey De Smetirc.codehaus.org #drools
>
>
> _______________________________________________
> rules-dev mailing listrules-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> --
> With kind regards,
> Geoffrey De Smet
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20110209/600e16c7/attachment-0001.html 


More information about the rules-dev mailing list