Creating a new project should be less painful

[LisaAlmarode]

There are two ways I've found to create a project such that it is "attached" and doesn't mess up the Jadeite project browser. This complaint is that:

1. you need to use the project tools, definitions don't have complete support. Specifically git init is only called via createProjectFor. For the Jadeite Browser to continue functioning, you must invoke both createProjectFor: and commitProjectDefinition:message:. Write isn't enough.
2. the tools methods are numerous and confusing.

| proj |
proj := Rowan projectTools create 
    createGitBasedProject: 'LisaTest1'
    packageNames: Array new 
    format: 'tonel' 
    root: '$ROWAN_PROJECTS_HOME'.
Rowan projectTools commit commitProjectDefinition: proj message: 'test'.

| proj |
proj := RwProjectDefinition newForGitBasedProjectNamed: 'LisaTest2'.
proj repositoryRootPath:  '$ROWAN_PROJECTS_HOME/LisaTest2'.
Rowan projectTools create createProjectFor: proj.
Rowan projectTools commit commitProjectDefinition: proj message: 'test'.

• [x] it would be nice if there was a way to create a git-based project definition without needing to use the tools.

• [x] the projectTools create methods are confusing and some should be private or deprecated.

  createGitBasedProjectDefinition:packageNames:format:root:
  createGitBasedProjectDefinition:packageNames:format:root:configsPath:repoPath:specsPath: 
    Accepts a name, returns a projectDefinition, but does not do #createProjectFor: 
  
  createGitBasedProject:packageNames:format:root:
  createGitBasedProject:packageNames:format:root:configsPath:repoPath:specsPath: 
    Accepts a name, returns a projectDefinition, and does the #createProjectFor:

• [x] these projectTools methods have unnecessary arguments, such as packageNames: and format:

• [x] some projectTools methods duplicate settings which make it look even more confusing. For example:

  projectDefinition
      repositoryRootPath: rootPath , utils pathNameDelimiter , projectName;
      repoPath: repoPath;
      configsPath: configsPath;
      repoPath: repoPath;
      specsPath: specsPath;
      repositoryRootPath: rootPath , utils pathNameDelimiter , projectName;
      projectOwnerId: Rowan image currentUserId.

• [x] some createProject* methods have the comment line "Create a new loaded project... " which I find baffling since the project is not loaded, just attached.

[dalehenrich]

@LisaAlmarode do you mind taking a look at some example v2.0.0 project creation/load expressions ... I think I'm headed in the right direction (and I think that the examples can be implemented:), but I'm curious what you think ... perhaps we can talk Thursday after staff if needed?

[LisaAlmarode]

This mixes in some of the project configuration stuff which is good, and it reads okay - but I'd have to see what happens when I try to use it. Switching around underlying repositories seems a bit hairy.

onCondition: threw me, since a conditional by itself doesn't really make sense, but I see it refers back to the previous "add". The package add we shall if gemstone the condition is. Easier to find the method; so that's okay.

[dalehenrich]

On 11/27/18 5:00 PM, Lisa Almarode wrote:

This mixes in some of the project configuration stuff which is good, and it reads okay - but I'd have to see what happens when I try to use it.

Passing the eye test means it worth heading that route:) Thanks! So far the examples are all pseudo code ... As I started work on the new tone/filetree reader code it became clear that I needed to clean up the project definition creation logic ... so that's the underlying motivation for the spec and examples...

Switching around underlying repositories seems a bit hairy.

Yes it does:) ... the use case involves being able to switch back and forth between working with the embedded Cypress/Tonel/Ston/FileSystem projects and working with the official GitHub projects ... The embedded projects make it practical to release a coherent version of the complete system without worrying about changes made by others for other reasons interfering with the stability of the release (see what's going on right now with the Pharo7 project) ... Once the release has been released, you want to merge any changes that you've made into the official project as well as integerate and evaluate any changes that were made to the official project ...

This is definitely an area that I will have to explore in detail before making it a public feature;)

onCondition: threw me, since a conditional by itself doesn't really make sense, but I see it refers back to the previous "add". The package add we shall if gemstone the condition is. Easier to find the method; so that's okay.

Now's the time to suggest better selectors or alternative methods ..

Dale

[dalehenrich]

Here is my most recent take on the project creation ... and I think it is pretty concise, doesn't require the user to understand the tools api ...

    | projectName project projectHome |
    projectHome := '$ROWAN_PROJECTS_HOME/RowanSample8/home' asFileReference.
    projectName := 'Example02'.

    project := RwComponentProjectDefinition
        projectName: projectName 
            projectHome: projectHome
            useGit: true
            comment: 'Example project exposing the standard project creation api'.
    project
        addComponentNamed: 'Core'
            comment: 'Primary component used for loading entire system.';
        defaultSymbolDictionary: 'ExampleCore' 
            forUser: 'SystemUser';
        addPackageNamed: 'Example-Core1'
            withConditions: { 'common' };
        addPackageNamed: 'Example-Core2'
            withConditions: { 'common' };
        addPackageNamed: 'Example-Tests'
            withConditions: { 'common' }
            andGroupName: 'tests';
        addPackageNamed: 'Example-GemStone-Extensions'
            withConditions: { 'gemstone' }
            gemstoneDefaultSymbolDictionaryForUser: 'SystemUser' -> 'Globals';
        addPackageNamed: 'Example-GemStone-Test-Extensions'
            withConditions: { 'gemstone' }
            andGroupName: 'tests'
            gemstoneDefaultSymbolDictionaryForUser: 'SystemUser' -> 'Globals';
        yourself.

    (project componentNamed: 'Core')
        addDefinedGroupName: 'tests' includeGroups: { 'core' };
        yourself.

    project export.