Skip to main content
[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Here's a collaboration use case for consideration. If we could solve
this problem, it could greatly increase the productivity of our
customers.
A user checks out one or more Eclipse projects from subversion or
perhaps creates new project(s). The user makes modifications to the
contents of the project(s). The user runs an external program that
uses the Eclipse projects as input, and produces artifacts in a
specified location that is not an Eclipse project. The status of the
process execution is displayed in an eclipse view (along with the
status of previous executions). The process fails to produce the
expected results. The user determines that the root cause is in one
of the Eclipse projects and that data is owned by another developer.
The user selects the process status in the eclipse view, right-clicks
and selects "Share...". The user then selects the developer who
needs to debug the root cause.
The target developer receives a notification that there is a problem
that needs to be debugged. The developer accepts the problem and the
status of the failing process is loaded into their Eclipse view as if
they had originally run the process. They re-run the process, debug
the fail, and fix the bad inputs in the Eclipse project(s). They
right-click the status of the, now passing, process and select
"Fixed". The fixed inputs are sent back to the originator.
Some interesting problems with this use case: If the originating
developer is using a local sandbox for his workspace, how does the
receiving developer get the contents. If the receiving developer is
in the middle of modifying those same Eclipse projects, do they have
to switch worspaces? The incoming projects can't overwrite their
current modifications. What if the originating developer needs to
modify those projects while waiting for the receiving developer to
fix the problem? The original data must be preserved so the
receiving developer can reproduce the fail. If the originating
developer re-runs the process, the new artifacts must be placed in a
different output directory to preserve the original, failing,
artifacts. Consideration must be given to the amount of data
shared / moved - it's not uncommon for us to have a gig or two of
input / output data surrounding a process. Support for a shared
filesystem such as AFS may be necessary as part of a solution to
these problems.
Bryan
PS ... It seems that I will be best served to understand the basics
of OSGi, followed by ECF to use as a foundation for our remote
services use case, and then work on understanding the corona context
container?? to serve this new use case. Suggestions?
Back to the top