RTC 2.0.2.I201007292044 scm accept won't flow new component

Anytime you get an "Unexpected Exception", that is a bug, and we'd appreciate it if you could submit a bug report (either directly on jazz.net, or by calling Rational Support, whatever is easier for you). There might be some reasonable explanation and/or easy way to avoid it, but in that case, the bug is in the error reporting ... it should make it clear what happened and what the workaround is.

It could be something as simple as "the component is a private component that you don't have read access to", with a workaround of making it public (but if so, there should be a reasonable error message to that effect).

Cheers,
Geoff

Using the scm CLI to run automated builds
have a workspace that flows from a stream which has had a couple of components added.

running `scm accept --flow-components` results in a "Workspace unchanged." message

running `scm list components` on the workspace results in:

 'scm command' returned 13

'Workspace: (2676:_gGUhEHVFEeGr3dMo9BrB6Q) "the_workspace" <-> (0972:_7RI6AHQ8EeGr3dMo9BrB6Q) "the_stream"

  Component: (2702:_iLahsF1REeGh-_JJPPxPnQ) "comp1"

    Baseline: (2703:_3DefpZqwEeGJG62D510CwQ) 268 "a_baseline"

  Component: (2724:_a5BcsF1SEeGh-_JJPPxPnQ) "comp2"

    Baseline: (2725:_3DTggpqwEeGJG62D510CwQ) 286 "a_baseline"

  Component: (2740:_5yjhsF57EeGh-_JJPPxPnQ) "new_comp1" (incoming addition)

Unexpected exception

java.lang.NullPointerException

	at com.ibm.team.filesystem.cli.core.util.PendingChangesUtil.printComponent(PendingChangesUtil.java:698)

	at com.ibm.team.filesystem.cli.core.util.PendingChangesUtil.printWorkspace(PendingChangesUtil.java:598)

	at com.ibm.team.filesystem.cli.core.util.PendingChangesUtil.printWorkspace(PendingChangesUtil.java:448)

	at com.ibm.team.filesystem.cli.client.internal.listcommand.ListComponentsCmd.listComponentsForWorkspace(ListComponentsCmd.java:151)

	at com.ibm.team.filesystem.cli.client.internal.listcommand.ListComponentsCmd.run(ListComponentsCmd.java:65)

	at com.ibm.team.filesystem.cli.core.internal.SubcommandLauncher.run(Unknown Source)

	at com.ibm.team.filesystem.cli.core.internal.SubcommandLauncher.doStart(Unknown Source)

	at com.ibm.team.filesystem.cli.core.internal.SubcommandLauncher.run(Unknown Source)

	at com.ibm.team.filesystem.cli.core.internal.Application.start(Unknown Source)

	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(Unknown Source)

	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(Unknown Source)

	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(Unknown Source)

	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(Unknown Source)

	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(Unknown Source)

	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)

	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

	at java.lang.reflect.Method.invoke(Method.java:618)

	at org.eclipse.equinox.launcher.Main.invokeFramework(Unknown Source)

	at org.eclipse.equinox.launcher.Main.basicRun(Unknown Source)

	at org.eclipse.equinox.launcher.Main.run(Unknown Source)

"new_comp1" is the first new component added to the stream.
Is this a bug? or is there something I'm missing?

thanks

Thanks Geoff, I'll copy the info to the bug tracker

cheers
Chris