Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update DTD for GWT-module descriptors #1

Merged
merged 1 commit into from
Apr 16, 2015
Merged

Update DTD for GWT-module descriptors #1

merged 1 commit into from
Apr 16, 2015

Conversation

azatsarynnyy
Copy link
Member

No description provided.

vparfonov pushed a commit that referenced this pull request Apr 16, 2015
Update DTD for GWT-module descriptors
@vparfonov vparfonov merged commit b7bc273 into master Apr 16, 2015
@vparfonov vparfonov deleted the updateDTD branch April 16, 2015 07:49
evidolob pushed a commit that referenced this pull request Apr 5, 2016
CHE-370: add loader widget for the process of resolving dependencies
benoitf added a commit that referenced this pull request May 27, 2016
…ove InstanceKey

#1 new docker recipe type

currently we have type:"dockerfile", location: "http://path-to-recipe"

now we could provide
type:"dockerfile", content: "FROM codenvy/foo\nENV FLORENT=TRUE\"

and
type:"image", location or content: "codenvy/foo"

#2 InstanceKey
Up to now, InstanceKey was used to perform snapshot recovery.
But machine source is a way to provide this information.
So remove InstanceKey and replace it by MachineSource (and DockerMachineSource instead of DockerInstanceKey)

InstanceProvider:
void removeInstanceSnapshot(InstanceKey instanceKey)
--> void removeInstanceSnapshot(MachineSource machineSource)

Instance:
InstanceKey saveToSnapshot(String owner)
--> MachineSource saveToSnapshot(String owner)

#3 InstanceProvider model
To avoid also that MachineManager "knows" the inner type, the recipe handling is moved to the instance provider implementation
And as the snapshot handling is with MachineSource (included in MachineConfig included in Machine), no need to give extra InstanceKey parameter

Replace two previous methods

Instance createInstance(Recipe recipe,
                            Machine machine,
                            LineConsumer creationLogsOutput)

 Instance createInstance(InstanceKey instanceKey,
                            Machine machine,
                            LineConsumer creationLogsOutput) throws NotFoundException, InvalidInstanceSnapshotException, MachineException;

by only one:
   createInstance(Machine machine,
                            LineConsumer creationLogsOutput)

Change-Id: Ia7ea97bc1a44059b4892f5db387f54f2e1709fa3
Signed-off-by: Florent BENOIT <fbenoit@codenvy.com>
ashumilova pushed a commit that referenced this pull request May 27, 2016
Added samples to CHE project, renamed groupId, artifactId

Signed-off-by: Edgar Mueller <emueller@eclipsesource.com>
benoitf added a commit that referenced this pull request May 29, 2016
…ove InstanceKey

#1 new docker recipe type

currently we have type:"dockerfile", location: "http://path-to-recipe"

now we could provide
type:"dockerfile", content: "FROM codenvy/foo\nENV FLORENT=TRUE\"

and
type:"image", location or content: "codenvy/foo"

#2 InstanceKey
Up to now, InstanceKey was used to perform snapshot recovery.
But machine source is a way to provide this information.
So remove InstanceKey and replace it by MachineSource (and DockerMachineSource instead of DockerInstanceKey)

InstanceProvider:
void removeInstanceSnapshot(InstanceKey instanceKey)
--> void removeInstanceSnapshot(MachineSource machineSource)

Instance:
InstanceKey saveToSnapshot(String owner)
--> MachineSource saveToSnapshot(String owner)

#3 InstanceProvider model
To avoid also that MachineManager "knows" the inner type, the recipe handling is moved to the instance provider implementation
And as the snapshot handling is with MachineSource (included in MachineConfig included in Machine), no need to give extra InstanceKey parameter

Replace two previous methods

Instance createInstance(Recipe recipe,
                            Machine machine,
                            LineConsumer creationLogsOutput)

 Instance createInstance(InstanceKey instanceKey,
                            Machine machine,
                            LineConsumer creationLogsOutput) throws NotFoundException, InvalidInstanceSnapshotException, MachineException;

by only one:
   createInstance(Machine machine,
                            LineConsumer creationLogsOutput)

Change-Id: Ia7ea97bc1a44059b4892f5db387f54f2e1709fa3
Signed-off-by: Florent BENOIT <fbenoit@codenvy.com>
benoitf added a commit that referenced this pull request May 30, 2016
…ove InstanceKey

#1 new docker recipe type

currently we have type:"dockerfile", location: "http://path-to-recipe"

now we could provide
type:"dockerfile", content: "FROM codenvy/foo\nENV FLORENT=TRUE\"

and
type:"image", location or content: "codenvy/foo"

#2 InstanceKey
Up to now, InstanceKey was used to perform snapshot recovery.
But machine source is a way to provide this information.
So remove InstanceKey and replace it by MachineSource (and DockerMachineSource instead of DockerInstanceKey)

InstanceProvider:
void removeInstanceSnapshot(InstanceKey instanceKey)
--> void removeInstanceSnapshot(MachineSource machineSource)

Instance:
InstanceKey saveToSnapshot(String owner)
--> MachineSource saveToSnapshot(String owner)

#3 InstanceProvider model
To avoid also that MachineManager "knows" the inner type, the recipe handling is moved to the instance provider implementation
And as the snapshot handling is with MachineSource (included in MachineConfig included in Machine), no need to give extra InstanceKey parameter

Replace two previous methods

Instance createInstance(Recipe recipe,
                            Machine machine,
                            LineConsumer creationLogsOutput)

 Instance createInstance(InstanceKey instanceKey,
                            Machine machine,
                            LineConsumer creationLogsOutput) throws NotFoundException, InvalidInstanceSnapshotException, MachineException;

by only one:
   createInstance(Machine machine,
                            LineConsumer creationLogsOutput)

Change-Id: Ia7ea97bc1a44059b4892f5db387f54f2e1709fa3
Signed-off-by: Florent BENOIT <fbenoit@codenvy.com>
benoitf added a commit that referenced this pull request May 30, 2016
…ove InstanceKey

#1 new docker recipe type

currently we have type:"dockerfile", location: "http://path-to-recipe"

now we could provide
type:"dockerfile", content: "FROM codenvy/foo\nENV FLORENT=TRUE\"

and
type:"image", location or content: "codenvy/foo"

#2 InstanceKey
Up to now, InstanceKey was used to perform snapshot recovery.
But machine source is a way to provide this information.
So remove InstanceKey and replace it by MachineSource (and DockerMachineSource instead of DockerInstanceKey)

InstanceProvider:
void removeInstanceSnapshot(InstanceKey instanceKey)
--> void removeInstanceSnapshot(MachineSource machineSource)

Instance:
InstanceKey saveToSnapshot(String owner)
--> MachineSource saveToSnapshot(String owner)

#3 InstanceProvider model
To avoid also that MachineManager "knows" the inner type, the recipe handling is moved to the instance provider implementation
And as the snapshot handling is with MachineSource (included in MachineConfig included in Machine), no need to give extra InstanceKey parameter

Replace two previous methods

Instance createInstance(Recipe recipe,
                            Machine machine,
                            LineConsumer creationLogsOutput)

 Instance createInstance(InstanceKey instanceKey,
                            Machine machine,
                            LineConsumer creationLogsOutput) throws NotFoundException, InvalidInstanceSnapshotException, MachineException;

by only one:
   createInstance(Machine machine,
                            LineConsumer creationLogsOutput)

Change-Id: Ia7ea97bc1a44059b4892f5db387f54f2e1709fa3
Signed-off-by: Florent BENOIT <fbenoit@codenvy.com>
benoitf added a commit that referenced this pull request May 30, 2016
…ove InstanceKey

#1 new docker recipe type

currently we have type:"dockerfile", location: "http://path-to-recipe"

now we could provide
type:"dockerfile", content: "FROM codenvy/foo\nENV FLORENT=TRUE\"

and
type:"image", location or content: "codenvy/foo"

#2 InstanceKey
Up to now, InstanceKey was used to perform snapshot recovery.
But machine source is a way to provide this information.
So remove InstanceKey and replace it by MachineSource (and DockerMachineSource instead of DockerInstanceKey)

InstanceProvider:
void removeInstanceSnapshot(InstanceKey instanceKey)
--> void removeInstanceSnapshot(MachineSource machineSource)

Instance:
InstanceKey saveToSnapshot(String owner)
--> MachineSource saveToSnapshot(String owner)

#3 InstanceProvider model
To avoid also that MachineManager "knows" the inner type, the recipe handling is moved to the instance provider implementation
And as the snapshot handling is with MachineSource (included in MachineConfig included in Machine), no need to give extra InstanceKey parameter

Replace two previous methods

Instance createInstance(Recipe recipe,
                            Machine machine,
                            LineConsumer creationLogsOutput)

 Instance createInstance(InstanceKey instanceKey,
                            Machine machine,
                            LineConsumer creationLogsOutput) throws NotFoundException, InvalidInstanceSnapshotException, MachineException;

by only one:
   createInstance(Machine machine,
                            LineConsumer creationLogsOutput)

Change-Id: Ia7ea97bc1a44059b4892f5db387f54f2e1709fa3
Signed-off-by: Florent BENOIT <fbenoit@codenvy.com>
@ghost ghost mentioned this pull request Feb 8, 2019
johnmcollier pushed a commit to johnmcollier/che that referenced this pull request Jun 20, 2019
tomgeorge pushed a commit that referenced this pull request Apr 21, 2020
che #15906 Adding 'che.workspace.stop.role.enabled' property in order to have a possibility to disable the 'OpenShiftStopWorkspaceRoleProvisioner'
@tolusha tolusha mentioned this pull request Mar 23, 2021
38 tasks
@mkuznyetsov mkuznyetsov mentioned this pull request Mar 24, 2021
17 tasks
@nickboldt nickboldt mentioned this pull request Apr 7, 2021
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants