Thanks,
That guidance helped
clear up a number of my issues. One minor correction: I suspect that
both the Committer and Anonymous .psf files for
org.higins.idas.spi suffer from a simple copy-and-paste error.
They refer to "org.higgins.idas.common" instead of
"org.higgins.idas.spi".
One other issue on the
WIKI Components page: The dependency links for the newer STS components
lead to empty pages, and it would be helpful to get those updated.
However, I've largely gotten by using the smae dependent libs as used with the
old (pre-refactoring) STS.
I've experienced problems
building the Higgins icard components recently, and now suspect I may be
working with obsolete projects due to similar refactoring in that
area. Is the component page up to date for package
org.eclipse.higgins.icard?
Finally, it is great step
forward to have the nighly builds available, though not everything
builds (The STS build seems to choke on the ICard components, so may be
having problems similar to the one's I've encountered.) And most consumers
would probably find a few instructions on how to deploy the products of
those builds useful.
Regards,
Brian
This is an example of why I need to tie up these loose ends. There
should not be an "org.eclipse.higgins.idas" project. No one should be using it
anymore. Even though I sent the mail to the dev list announcing this, I
need to do something to cause it to not work at all anymore -- maybe removing
everything and leaving a readme which explains where the new projects are.
Jim
>>> "Brian Carroll" <BCarroll@xxxxxxxxxx> 6/6/07
11:03 AM >>>
I strongly request we
wait to freeze until there we have a consistent set of sources that build.
I've been keeping up to date with the sources and there seem to be
inconistencies. For example the current issue I'm looking into is: there
are references to "org.eclipse.higgins.idas.spi" from files in the "org.eclipse.higgins.idas" project, but I don't see where
the "...spi" package is defined.
Brian
So, I do have one question regarding this.
Some time back I finished refactoring the package names / projects for
IdAS. I still have some outstanding tasks in that area:
1) Remove the code / project files from the old IdAS repository
location.
2) Make new projects work with the nightly build.
Should I also perform these project/build related tasks in a fork and merge
back to the regular dev head after the 25th?
>>> Anthony Nadalin
<drsecure@xxxxxxxxxx> 6/6/07 10:33 AM >>>
I would like to propose that all non-bug related changes be held or forked
until after June 25, thus putting a freeze on current code before the Burton
Interop, as we don't want to spend resources chasing bugs that changes might
cause, and we would resume normal processes after June 25th
Anthony
Nadalin | Work 512.838.0085 | Cell 512.289.4122
**********************************************************************
This email and any files
transmitted with it are confidential and intended solely for the use of the
individual or entity to whom they are addressed. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply e-mail and destroy all copies of the original
message.
**********************************************************************
|