[rules-dev] The droolsjbpm repository split-up and directory structure changes - PLEASE READ
Geoffrey De Smet
ge0ffrey.spam at gmail.com
Wed Feb 9 14:22:28 EST 2011
Branch 5.2.0.M1.x and tag 5.2.0.M1 can indeed not be lost.
Migrating them to the split-off repo's is not an option (see reasons in
my previous mail),
so we can just create the tag in subversion and check them in there.
Its much better than allowing the monolothic droolsjbpm to live in the
long term and cause a lot of confusion.
Op 09-02-11 20:14, Toni Rikkola schreef:
> We don't really need the 5.2.0.M1.x branch if we have the tag, but I
> have a feeling that we will lose that one too.
>
> We don't usually need the minor release branches or tags after the
> release, but they are nice to have. The M1 is codes are saved in the
> src.zip in our downloads page. So if somebody needs them they can get
> them from there.
>
> Toni
>
> On Feb 9, 2011, at 6:34 PM, Michael Anstis wrote:
>
>> 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
>> <http://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
>> <mailto: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.
>>> o We will preserve history per repository.
>>> o The droolsjbpm repository will be retired but not
>>> deleted.
>>> o 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).
>>> o 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).
>>> o 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.
>>> o The build will be broken less and the cause will be
>>> easier to identify and fix.
>>> o 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
>>> o 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
>>> o The parent pom (common stuff for the build)
>>> * repo droolsjbpm-knowledge
>>> o The public API and the internal API
>>> * repo drools
>>> o The rule engine modules
>>> * repo jbpm
>>> o The workflow engine modules
>>> * repo drools-planner
>>> o The planning optimizer modules
>>> * repo droolsjbpm-integration (groupId org.droolsjbpm)
>>> o Integrating Drools & jBPM with Seam, Spring, Camel, etc
>>> * repo guvnor
>>> o The web app to manage Drools & jBPM repositories
>>> * repo droolsjbpm-eclipse
>>> o The eclipse plugin for drools & jbpm
>>> * repo droolsjbpm-dist
>>> o Installer, aggregated assemblies, ...
>>>
>>>
>>> New structure guidelines
>>>
>>> * Docs and examples
>>> o Must be updated together with the main and test code
>>> => same pull request!
>>> o Are in the repo that provides their functionality
>>> o 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
>>> o Project dirs must much artifactId
>>> <http://java.dzone.com/articles/maven-tip-project-directories>
>>> o 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/eclipsebut
>>> https://github.com/etirelli/droolsjbpm-eclipse
>>>
>>>
>>> New dir structure
>>>
>>> * repo droolsjbpm-parent (groupId org.droolsjbpm)
>>> o This contains one pom, which is the parent pom for
>>> all the general build stuff.
>>> o artifactId renamed from drools
>>> o Includes shell script (and maybe bat script) to
>>> clone all of these repo’s
>>> o droolsjbpm-bom ? - TODO research bill of materialpoms
>>> * repo droolsjbpm-knowledge (groupId org.droolsjbpm)
>>> o knowledge-api
>>> + renamed from drools-api
>>> # GAV backward independency => TODO document
>>> + groupId org.droolsjbpm
>>> o knowledge-internal-api
>>> + empty for now, will be filled by markp, krisv, etc
>>> o TODO later one day: knowledge-core
>>> + extracted from drools-core
>>> o TODO later one day: knowledge-builder
>>> + extracted from drools-compiler
>>> o TODO later one day: knowledge-persistence
>>> + extracted drools-persistence-jpa
>>> o droolsjbpm-introduction-docs
>>> + renamed drools-docs-introduction
>>> * repo drools (groupId org.drools)
>>> o drools-core
>>> o drools-builder
>>> + renamed from drools-compiler
>>> o drools-persistence
>>> + renamed drools-persistence-jpa
>>> o drools-jsr94
>>> o drools-clips
>>> o drools-templates
>>> o drools-decisiontables
>>> o drools-verifier
>>> o drools-expert-docs
>>> o drools-fusion-docs
>>> o drools-expert-examples
>>> + renamed from drools-examples-drl
>>> o drools-fusion-examples
>>> + renamed from drools-examples-fusion
>>> * repo jbpm (groupId org.jbpm)
>>> o will be moved from the krisvgithub account to the
>>> droolsjbpmgithub organization
>>> o no other changes for now
>>> * repo guvnor (groupId org.drools or org.droolsjbpm.guvnor
>>> or org.guvnor)
>>> o guvnor-repository
>>> + renamed from drools-repository
>>> o guvnor-repository-jcr-connector
>>> + renamed from drools-repository-jcr-connector
>>> o guvnor-repository-jackrabbit-connector
>>> + renamed from
>>> drools-repository-jackrabbit-connector
>>> o guvnor-repository-modeshape-connector
>>> + renamed from drools-repository-modeshape-connector
>>> o knowledge-ide-common (TODO)
>>> + renamed from drools-ide-common
>>> + eats drools-factconstraint (esteban working on
>>> that)
>>> o guvnor-api?
>>> + TODO needed?
>>> o guvnor-gwtclient
>>> + extracted from drools-guvnor: all the GWT stuff
>>> o guvnor-webapp
>>> + renamed from drools-guvnor
>>> o guvnor-examples
>>> + renamed from drools-examples-brms
>>> # currently disabled, might be removed and
>>> rewritten from scratch
>>> o guvnor-docs
>>> + renamed from drools-docs-guvnor
>>> o 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)
>>> o org.drools.eclipse (might be changed over time)
>>> o org.drools.eclipse.task (might be changed over time)
>>> o org.guvnor.tools (might be changed over time)
>>> o org.drools.updatesite (might be changed over time)
>>> * repo droolsjbpm-integration (groupId org.drools or
>>> org.drools.integration)
>>> o drools-camel
>>> o drools-camel-server
>>> + renamed from drools-server
>>> o drools-pipeline
>>> + (deprecated)
>>> o drools-seam
>>> + drools-seam2
>>> # TODO do we want to keep this?
>>> + drools-seam3
>>> o drools-spring
>>> o drools-ant
>>> o drools-maven-plugin
>>> o osgi-bundles
>>> o drools-rhq-plugin
>>> o drools-simulator
>>> o drools-grid
>>> o drools-rhq-plugin
>>> o knowledge-integration-docs
>>> + renamed from drools-docs-integration
>>> * repo drools-planner (groupId org.drools.planner)
>>> o drools-planner-core
>>> o drools-planner-examples
>>> o drools-planner-docs
>>> + renamed from drools-docs-planner
>>> o drools-planner-assembly
>>> * repo droolsjbpm-dist(groupId org.droolsjbpm)
>>> o Assemblies? Or per repo?
>>> + Per repo, but make src etc here
>>> o TODO later: uber documentation?
>>> o 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...
>>> o 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
>>> o Everything will be documented in the release notes
>>>
>>>
>>> While we’re freezing anyway:
>>>
>>> * Before the move:
>>> o Simplify & stabilize build
>>> + Simplify javadocs generation
>>> # keep groups if possible, but not required
>>> * Before pushing the moved part into a new repo:
>>> o [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:
>>> o All line endings to \n (unix), except *.bat files
>>> + https://issues.jboss.org/browse/JBRULES-2855
>>> o All \t (tabs) in *.java files replace by 4 spaces
>>> + all \t (tabs) in *.xml files replace by 2 spaces
>>> o All copyright should start with /* and not /**
>>> because a copyright is not a valid javadoc.
>>> o 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
>>> o To flesh out the split-up process.
>>> o I don't think anyone forked and changed these modules.
>>> * I'll split-off droolsjbpm-eclipse Wednesday 9-FEB-2011
>>> o I don't think anyone forked and changed these modules.
>>> * I'll probably split-off guvnor Friday 11-FEB-2011
>>> o *Get your guvnor fork changes merged into master by
>>> Thursday 10-FEB-2011.*
>>> o Contact me if this date is a problem.
>>> * Other splits-off will be announced later.
>>>
>>> --
>>> With kind regards,
>>> Geoffrey De Smet
>>> irc.codehaus.org <http://irc.codehaus.org/> #drools
>>>
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>> --
>> With kind regards,
>> Geoffrey De Smet
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
--
With kind regards,
Geoffrey De Smet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20110209/a16818db/attachment-0001.html
More information about the rules-dev
mailing list