[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