Home » Eclipse Projects » Technology Project and PMC » Inconsitent archive
| |
| Re: Inconsitent archive [message #6413 is a reply to message #6354] |
Wed, 10 July 2002 23:59   |
 Mark C. Chu-Carroll
Messages: 64
Registered: July 2009 |
Member |
|
|
On Wed, 10 Jul 2002 19:33:36 -0400, Axel Fontaine wrote:
>
> Hello !
>
> I just downloaded the latest archive from the Stellation website, but it
> seems like it was zipped in the middle of a refactoring, or that simply
> a bunch of the code is missing.
I just checked the archive. It does not contain the material from
org.eclipse.stellation.misc, which it really should. I'll correct that
ASAP. But the rest is actually not missing.
I think that you may be misunderstanding the package structure of the
system. There's a not entirely obvious separation in the system. We use a
very generic communication bus, which is implemented in
org.eclipse.stellation.comm.messaging. There is *no* application specific
code in this part of the system: it's a thoroughly generic communication
system that we're using for Stellation.
The application specific code that interfaces the stellation repository
and client into the messaging system to enable remote access to a server
is in org.eclipse.stellation.repos.messaging.
> So far these are the problems I have encountered:
>
>- no factories in comm.messaging.auth
There aren't supposed to be. As I said, the messaging layer is actually
*very* generic. It isn't specific to Stellation. A particular
implementation of an authenticator is specific to a particular
application.
The application specific messaging code is in the packages under
org.eclipse.stellation.repos.messaging. For example, the authenticator
factory for a repository server is in
org.eclipse.stellation.repos.messaging.server.ReposServerCha llengeFactory.
>- no ClientCompoundManager
It's there in the copy I checked:
org/eclipse/stellation/repos/messaging/client/ClientCompound Manager.java.
>- AuthenticationException is in a different package
I don't know what you mean by this: in a different package from what?
AuthenticationException is in org.eclipse.stellation.comm.messaging.auth,
along with the interface for objects that throw it.
>- no RemoteAccessPoint
RemoteAccessPoint is there, in
org/eclipse/stellation/repos/messaging/client.
> - no specific code for postgresSQL and db2
Specific code for PostgreSQL and DB2 is in org/eclipse/stellation/repos,
in PostgresAccessPoint and DB2AccessPoint.
> Cheers,
> Axel
>
> P.S.: Original plan was to look into adding hsqldb 1.7.0 as a storage
> backend.
I haven't looked at hsqldb before. What kind of support does it have for
long transactions?
-Mark
--
Mark Craig Chu-Carroll, IBM T.J. Watson Research Center
*** The Stellation project: Advanced SCM for Collaboration
*** http://www.eclipse.org/stellation
*** Work Email: mcc@watson.ibm.com ------- Personal Email: markcc@bestweb.net
|
|
|
| Re: Inconsitent archive [message #6432 is a reply to message #6413] |
Thu, 11 July 2002 02:06 |
Axel
Messages: 10
Registered: July 2009 |
Junior Member |
|
|
My apoligies.
I checked a few things and apparently powerarchiver's tar decompression
selects the short version of long file names. example: you get a file named
AuthenticationExceptio and not AuthenticationException.java as it should be.
Still pretty wierd that there are two entries in the tar files in the first
place. Would it be possible to provide a .zip version, as I probably won't
be the only one running into this problem...
"Mark C. Chu-Carroll" <markcc@bestweb.net> wrote in message
news:agig5n$ngc$1@rogue.oti.com...
> On Wed, 10 Jul 2002 19:33:36 -0400, Axel Fontaine wrote:
> >
> > Hello !
> >
> > I just downloaded the latest archive from the Stellation website, but it
> > seems like it was zipped in the middle of a refactoring, or that simply
> > a bunch of the code is missing.
>
> I just checked the archive. It does not contain the material from
> org.eclipse.stellation.misc, which it really should. I'll correct that
> ASAP. But the rest is actually not missing.
>
> I think that you may be misunderstanding the package structure of the
> system. There's a not entirely obvious separation in the system. We use a
> very generic communication bus, which is implemented in
> org.eclipse.stellation.comm.messaging. There is *no* application specific
> code in this part of the system: it's a thoroughly generic communication
> system that we're using for Stellation.
>
> The application specific code that interfaces the stellation repository
> and client into the messaging system to enable remote access to a server
> is in org.eclipse.stellation.repos.messaging.
>
> > So far these are the problems I have encountered:
> >
> >- no factories in comm.messaging.auth
>
> There aren't supposed to be. As I said, the messaging layer is actually
> *very* generic. It isn't specific to Stellation. A particular
> implementation of an authenticator is specific to a particular
> application.
>
> The application specific messaging code is in the packages under
> org.eclipse.stellation.repos.messaging. For example, the authenticator
> factory for a repository server is in
> org.eclipse.stellation.repos.messaging.server.ReposServerCha llengeFactory.
>
> >- no ClientCompoundManager
>
> It's there in the copy I checked:
> org/eclipse/stellation/repos/messaging/client/ClientCompound Manager.java.
>
> >- AuthenticationException is in a different package
>
> I don't know what you mean by this: in a different package from what?
> AuthenticationException is in org.eclipse.stellation.comm.messaging.auth,
> along with the interface for objects that throw it.
>
> >- no RemoteAccessPoint
>
> RemoteAccessPoint is there, in
> org/eclipse/stellation/repos/messaging/client.
>
> > - no specific code for postgresSQL and db2
>
> Specific code for PostgreSQL and DB2 is in org/eclipse/stellation/repos,
> in PostgresAccessPoint and DB2AccessPoint.
>
>
> > Cheers,
> > Axel
> >
> > P.S.: Original plan was to look into adding hsqldb 1.7.0 as a storage
> > backend.
>
> I haven't looked at hsqldb before. What kind of support does it have for
> long transactions?
>
> -Mark
>
> --
> Mark Craig Chu-Carroll, IBM T.J. Watson Research Center
> *** The Stellation project: Advanced SCM for Collaboration
> *** http://www.eclipse.org/stellation
> *** Work Email: mcc@watson.ibm.com ------- Personal Email:
markcc@bestweb.net
|
|
|
| Re: Inconsitent archive [message #6451 is a reply to message #6432] |
Thu, 11 July 2002 01:15 |
Mark C. Chu-Carroll
Messages: 64
Registered: July 2009 |
Member |
|
|
On Wed, 10 Jul 2002 22:06:58 -0400, Axel Fontaine wrote:
> My apoligies.
>
> I checked a few things and apparently powerarchiver's tar decompression
> selects the short version of long file names. example: you get a file
> named AuthenticationExceptio and not AuthenticationException.java as it
> should be. Still pretty wierd that there are two entries in the tar
> files in the first place. Would it be possible to provide a .zip
> version, as I probably won't be the only one running into this
> problem...
There aren't two filenames in the tar... tar uses unix filenames, which
don't have any length limitations. The short filenames are an artifact
of your tar unpacker.
I'm still debating whether there's really any value in putting the
source up there in a tar bundle like that at all. For windows users,
there are all of the filename related issues - and I'm not sure how to
fix that in a zipfile, either.
For unix users, they've got working tar, but they've also got working
CVS. For windows users, the standard windows CVS distributions all
handle filenames correctly. And anyone who has Eclipse has working CVS.
Since the tar file is nothing more than a copy of what's in CVS, it seems
like it just might be causing more trouble than its worth. When we start
self-hosting, it will make sense to provide installable packages for
download without CVS, but I seriously question whether there's any
value in putting up a hard-to-maintain copy of the head version in CVS.
In the meantime: if you're having trouble, I'd encourage you to just to
CVS and check it out. From the command-line:
cvs -d :pserver:anonymous@dev.eclipse.org:/home/technology checkout
org.eclipse.stellation/plugins
Or from eclipse, with the instructions from the "setting up in eclipse"
document on our website.
-Mark
--
Mark Craig Chu-Carroll, IBM T.J. Watson Research Center
*** The Stellation project: Advanced SCM for Collaboration
*** http://www.eclipse.org/stellation
*** Work Email: mcc@watson.ibm.com ------- Personal Email: markcc@bestweb.net
|
|
| |
| Re: Inconsitent archive [message #567347 is a reply to message #6354] |
Wed, 10 July 2002 23:59 |
Mark C. Chu-Carroll
Messages: 64
Registered: July 2009 |
Member |
|
|
On Wed, 10 Jul 2002 19:33:36 -0400, Axel Fontaine wrote:
>
> Hello !
>
> I just downloaded the latest archive from the Stellation website, but it
> seems like it was zipped in the middle of a refactoring, or that simply
> a bunch of the code is missing.
I just checked the archive. It does not contain the material from
org.eclipse.stellation.misc, which it really should. I'll correct that
ASAP. But the rest is actually not missing.
I think that you may be misunderstanding the package structure of the
system. There's a not entirely obvious separation in the system. We use a
very generic communication bus, which is implemented in
org.eclipse.stellation.comm.messaging. There is *no* application specific
code in this part of the system: it's a thoroughly generic communication
system that we're using for Stellation.
The application specific code that interfaces the stellation repository
and client into the messaging system to enable remote access to a server
is in org.eclipse.stellation.repos.messaging.
> So far these are the problems I have encountered:
>
>- no factories in comm.messaging.auth
There aren't supposed to be. As I said, the messaging layer is actually
*very* generic. It isn't specific to Stellation. A particular
implementation of an authenticator is specific to a particular
application.
The application specific messaging code is in the packages under
org.eclipse.stellation.repos.messaging. For example, the authenticator
factory for a repository server is in
org.eclipse.stellation.repos.messaging.server.ReposServerCha llengeFactory.
>- no ClientCompoundManager
It's there in the copy I checked:
org/eclipse/stellation/repos/messaging/client/ClientCompound Manager.java.
>- AuthenticationException is in a different package
I don't know what you mean by this: in a different package from what?
AuthenticationException is in org.eclipse.stellation.comm.messaging.auth,
along with the interface for objects that throw it.
>- no RemoteAccessPoint
RemoteAccessPoint is there, in
org/eclipse/stellation/repos/messaging/client.
> - no specific code for postgresSQL and db2
Specific code for PostgreSQL and DB2 is in org/eclipse/stellation/repos,
in PostgresAccessPoint and DB2AccessPoint.
> Cheers,
> Axel
>
> P.S.: Original plan was to look into adding hsqldb 1.7.0 as a storage
> backend.
I haven't looked at hsqldb before. What kind of support does it have for
long transactions?
-Mark
--
Mark Craig Chu-Carroll, IBM T.J. Watson Research Center
*** The Stellation project: Advanced SCM for Collaboration
*** http://www.eclipse.org/stellation
*** Work Email: mcc@watson.ibm.com ------- Personal Email: markcc@bestweb.net
|
|
|
| Re: Inconsitent archive [message #567373 is a reply to message #6413] |
Thu, 11 July 2002 02:06 |
Axel
Messages: 10
Registered: July 2009 |
Junior Member |
|
|
My apoligies.
I checked a few things and apparently powerarchiver's tar decompression
selects the short version of long file names. example: you get a file named
AuthenticationExceptio and not AuthenticationException.java as it should be.
Still pretty wierd that there are two entries in the tar files in the first
place. Would it be possible to provide a .zip version, as I probably won't
be the only one running into this problem...
"Mark C. Chu-Carroll" <markcc@bestweb.net> wrote in message
news:agig5n$ngc$1@rogue.oti.com...
> On Wed, 10 Jul 2002 19:33:36 -0400, Axel Fontaine wrote:
> >
> > Hello !
> >
> > I just downloaded the latest archive from the Stellation website, but it
> > seems like it was zipped in the middle of a refactoring, or that simply
> > a bunch of the code is missing.
>
> I just checked the archive. It does not contain the material from
> org.eclipse.stellation.misc, which it really should. I'll correct that
> ASAP. But the rest is actually not missing.
>
> I think that you may be misunderstanding the package structure of the
> system. There's a not entirely obvious separation in the system. We use a
> very generic communication bus, which is implemented in
> org.eclipse.stellation.comm.messaging. There is *no* application specific
> code in this part of the system: it's a thoroughly generic communication
> system that we're using for Stellation.
>
> The application specific code that interfaces the stellation repository
> and client into the messaging system to enable remote access to a server
> is in org.eclipse.stellation.repos.messaging.
>
> > So far these are the problems I have encountered:
> >
> >- no factories in comm.messaging.auth
>
> There aren't supposed to be. As I said, the messaging layer is actually
> *very* generic. It isn't specific to Stellation. A particular
> implementation of an authenticator is specific to a particular
> application.
>
> The application specific messaging code is in the packages under
> org.eclipse.stellation.repos.messaging. For example, the authenticator
> factory for a repository server is in
> org.eclipse.stellation.repos.messaging.server.ReposServerCha llengeFactory.
>
> >- no ClientCompoundManager
>
> It's there in the copy I checked:
> org/eclipse/stellation/repos/messaging/client/ClientCompound Manager.java.
>
> >- AuthenticationException is in a different package
>
> I don't know what you mean by this: in a different package from what?
> AuthenticationException is in org.eclipse.stellation.comm.messaging.auth,
> along with the interface for objects that throw it.
>
> >- no RemoteAccessPoint
>
> RemoteAccessPoint is there, in
> org/eclipse/stellation/repos/messaging/client.
>
> > - no specific code for postgresSQL and db2
>
> Specific code for PostgreSQL and DB2 is in org/eclipse/stellation/repos,
> in PostgresAccessPoint and DB2AccessPoint.
>
>
> > Cheers,
> > Axel
> >
> > P.S.: Original plan was to look into adding hsqldb 1.7.0 as a storage
> > backend.
>
> I haven't looked at hsqldb before. What kind of support does it have for
> long transactions?
>
> -Mark
>
> --
> Mark Craig Chu-Carroll, IBM T.J. Watson Research Center
> *** The Stellation project: Advanced SCM for Collaboration
> *** http://www.eclipse.org/stellation
> *** Work Email: mcc@watson.ibm.com ------- Personal Email:
markcc@bestweb.net
|
|
|
| Re: Inconsitent archive [message #567403 is a reply to message #6432] |
Thu, 11 July 2002 01:15 |
Mark C. Chu-Carroll
Messages: 64
Registered: July 2009 |
Member |
|
|
On Wed, 10 Jul 2002 22:06:58 -0400, Axel Fontaine wrote:
> My apoligies.
>
> I checked a few things and apparently powerarchiver's tar decompression
> selects the short version of long file names. example: you get a file
> named AuthenticationExceptio and not AuthenticationException.java as it
> should be. Still pretty wierd that there are two entries in the tar
> files in the first place. Would it be possible to provide a .zip
> version, as I probably won't be the only one running into this
> problem...
There aren't two filenames in the tar... tar uses unix filenames, which
don't have any length limitations. The short filenames are an artifact
of your tar unpacker.
I'm still debating whether there's really any value in putting the
source up there in a tar bundle like that at all. For windows users,
there are all of the filename related issues - and I'm not sure how to
fix that in a zipfile, either.
For unix users, they've got working tar, but they've also got working
CVS. For windows users, the standard windows CVS distributions all
handle filenames correctly. And anyone who has Eclipse has working CVS.
Since the tar file is nothing more than a copy of what's in CVS, it seems
like it just might be causing more trouble than its worth. When we start
self-hosting, it will make sense to provide installable packages for
download without CVS, but I seriously question whether there's any
value in putting up a hard-to-maintain copy of the head version in CVS.
In the meantime: if you're having trouble, I'd encourage you to just to
CVS and check it out. From the command-line:
cvs -d :pserver:anonymous@dev.eclipse.org:/home/technology checkout
org.eclipse.stellation/plugins
Or from eclipse, with the instructions from the "setting up in eclipse"
document on our website.
-Mark
--
Mark Craig Chu-Carroll, IBM T.J. Watson Research Center
*** The Stellation project: Advanced SCM for Collaboration
*** http://www.eclipse.org/stellation
*** Work Email: mcc@watson.ibm.com ------- Personal Email: markcc@bestweb.net
|
|
|
Goto Forum:
Current Time: Tue Apr 23 10:45:07 GMT 2024
Powered by FUDForum. Page generated in 0.03607 seconds |
] 
Search
Help
Register
Login
Home
