eclipsedotnet-developers — Discussions about Eclipse.NET development

[Eclipsedotnet-developers] =?windows-1252?q?AUTOMGEN8_and_LEGO_NX?= =?windows-1252?q?T_brick=3A_let=27s_go_to_the_world_of_robots?=

[Stephane M. - I. <sm...@ir...>]

TmV3OiBBVVRPTUdFTjggaXMgbm93IGFibGUgdG8gcHJvZ3JhbSBMRUdPIE5YVCBCUklDSyAodHJh
ZGVtYXJrIG9mIExFR08gR3JvdXApLiANCg0KWW91IGNhbiBub3cgYnVpbGQgcm9ib3RpY3MgYXBw
bGljYXRpb25zIGJ5IHVzaW5nIHVzdWFsIEFVVE9NR0VOIGZ1bmN0aW9uYWxpdGllcy4NCkhlcmUg
aXMgYSBsaW5rIHRvIGEgZG9jdW1lbnQgd2hpY2ggaXMgc2hvd2luZyBBVVRPTUdFTiBwcm9qZWN0
cyBmb3IgTEVHTyBOWFQgYnJpY2ssIGEgd2lyZSBndWlkZWQgcm9ib3QgYnkgZXhhbXBsZSA6IHd3
dy5pcmFpLmNvbS9hOC9hOGFuZG54dF9lLnBkZg0KQVVUT01HRU4gOC4wMDQgdmVyc2lvbiBpcyBh
dmFpbGFibGUgZm9yIGRvd25sb2FkIGhlcmUgOiB3d3cuaXJhaS5jb20vYThlDQpQbGVhc2UgY29u
dGFjdCB1cyBpZiB5b3UgbmVlZCBtb3JlIGluZm9ybWF0aW9ucy4NCkJlc3QgcmVnYXJkcw0KSVJB
SQ0KMTcsIGF2ZW51ZSBkdSAxOSBtYXJzIDE5NjINCjMwMTEwIExBIEdSQU5EIENPTUJFDQpGUkFO
Q0UgDQp0ZWwgKzMzIDQgNjYgNTQgOTEgMzANCmZheCArMzMgNCA2NiA1NCA5MSAzMw0Kc21AaXJh
aS5jb20NCmh0dHA6Ly93d3cuaXJhaS5jb20vDQogSWYgeW91IHdhbnQgbm8gbW9yZSBpbmZvcm1h
dGlvbiBmcm9tIHVzLCBwbGVhc2UgcmVwbHkgdG8gdGhpcyBlbWFpbCB3aXRoICJjYW5jZWwiIGFz
IHN1YmplY3QNCiANCg0KDQoNCg==

[Eclipsedotnet-developers] RE: I'm getting an error checking out from SVN

[<jpp...@gm...>]

I think that, for the current version of Eclipse (SWT-based, 2.1.3-based
Core, etc.), we should only do bug-fixing, and that we should start =
working
out the new SWF-based UI, for one. That would certainly have a =
much-greater
impact in the .NET community than the SWT-based version.


So, I would say that the most important for that is to start looking at =
the
semantics of Jface and start adapting it to .NET + SWF, meanwhile =
creating
additional useful mechanisms/features of our own for it. I had already
created a project in Development/SWF_UI/Nface to do exactly that. If you
wish to start adapting some Jface mechanisms (such as Actions, Wizards,
Windows, etc.) or create your own, feel free to do so - pick a mechanism =
(or
mechanisms) that you would like to work on, and go for it :) . Anyway, =
this
developing-something-new should be a lot more fun than =
bug-hunting/fixing ;)
.

Also, I would say that, when we begin this new-version development, we
should start taking a more test-oriented approach. I unfortunately had =
to
neglect that part last year, as I had only some months to create a =
working
platform, and porting the existing tests at the time would be (even =
more)
nightmar-ish.
One thing I've been meaning to do for a long time is take a good, long =
look
at Nunit and its internals and try to adapt it (or create a wrapper =
around
it) that would allow us to have test-plugins in the Platform (i.e., =
there
would be a Test core plugin - with some of Nunit's dlls included - that
would provide a framework for testing other plugins). So, if one wanted =
to
run all the tests available for the platform (assuming that the testing
plugins were present), one would only have to run Eclipse.NET specifying
that the application to run would be something like "Tests" (like =
Eclipse
itself does, nowadays).


So, pick your favorite, if you have one. If you don't have a favorite, =
I'd
recommend Jface/Nface, as it involves less research and most likely will
present a lot less problems to solve (so you can consider your time
well-spent :-) ).


I had forgotten to do so, but I'm attaching a svn-commit hook to our =
commits
mailing list.



BTW, just out of curiosity: for the OSGi-part that you have been doing, =
do
you already have a prototype of the API (i.e., the API more-or-less =
created,
even if it does nothing yet)? Are you basing your R&D on any particular
documentation? It's just that I would like to do some reading too, to
realize to some extent how currently existing plugins will be affected
(i.e., if we will/would use attributes to identify plugin classes, =
etc.).



Best regards,
JS



P.S.: I hope you don't mind, but I'm also sending this to the developers
mailing list, just for archival purposes, as it is related to the
development of Eclipse.NET .

=20

> -----Original Message-----
> From: Kunle Odutola [mailto:kun...@vi...]=20
> Sent: s=E1bado, 18 de Mar=E7o de 2006 15:01
> To: 'Jo=E3o Saraiva'
> Subject: RE: I'm getting an error checking out from SVN
>=20
> > Hey again.
> >=20
> > I've been trying out with the latest version of TortoiseSVN and it=20
> > sometimes still gives me the error. However, if I continue making=20
> > Update over the
> > (incomplete) checkout, it gets some more files.
>=20
> ;-)
>=20
> I worked that out and managed to get it to complete before=20
> you replied.
> Thanks anyway. I am doing an export right now to see if the=20
> same issues still apply.
>=20
> > I guess this means that we should, in future releases, also=20
> release a=20
> > zip file with the source code _and_ the .svn directories (so that=20
> > people can just get the source zip, extract it and then=20
> Update it to=20
> > get the latest - yet unreleased - source).
>=20
> Not sure about that. Sounds like a format that's more=20
> appropriate for nightly builds etc. A normal zip (without=20
> .svn dirs) with binaries-only and sources-only (or=20
> binaries+sources) is more suited to a release.
>=20
> Incidentally, I've got a little free time so, which=20
> tasks/moduels are highest priority?. I've had to put the OSGi=20
> for 3.x stuff on hold for the mo' due to time restrictions.... ;-(
>=20
>=20
> Thanks
>=20
> Kunle
>=20

RE: [Eclipsedotnet-developers] SVN is on!

[<jpp...@gm...>]

Hi, Kunle.


I think I moved everything (unless I forgot some small file, but what is =
in
the SVN repository is the latest version and everything compiles/works). =
I
also took the opportunity to place our existing code in =
src_platform/Trunk
(where I placed our _relatively_ stable code), and created a new =
directory
called Development (where we can place code that is currently under
development/testing - WinForms UI, your new Platform Core, etc.). Right =
now,
I'm only using the SVN repository (where I also committed some minor =
changes
- bug corrections that David pointed out, mostly), so feel free to use =
that
as our development repository. Also, feel free to commit code whenever =
you
want; that's why the Development branch is there :) .

As for the build scripts, I did update them.

I'm sorry, I should have said this earlier in the ML, but I've been =
having a
ton of work :( . I aim to get clear of some of it soon, though.

BTW, if you need someone to help you out in development, feel free to =
use
the project's Task Manager to create tasks you think are relevant. I'll =
be
happy to help you out in any way I can.


Regards,
JS

=20

> -----Original Message-----
> From: ecl...@li...=20
> [mailto:ecl...@li...]=20
> On Behalf Of Kunle Odutola
> Sent: sexta-feira, 17 de Mar=E7o de 2006 6:07
> To: ecl...@li...
> Subject: RE: [Eclipsedotnet-developers] SVN is on!
>=20
> > Finally, SF.net has made available SVN for everyone! :-D
> >=20
> > I'll be committing all of the stuff from the old repository
> > (CVS) to the new repository (SVN) as quick as I can (this,=20
> of course,=20
> > is dependant on my very-short free time).
>=20
> > I won't delete anything from CVS, but I would appreciate if=20
> > someone/everyone could check the repository to make sure that=20
> > everything is OK (nothing missing that you'll need, etc.).
>=20
>=20
> Jo=E3o,
>=20
> Did you get the time to move all the stuff across?. Should we=20
> be ignoring CVS now and doing everything with SVN?
>=20
> I'm just about to pull down everything from SVN.
>=20
> >=20
> > I don't think I'll have the time to update the build scripts for a=20
> > while, so if anyone wants to do that, go for it.
>=20
> Kunle
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking=20
> scripting language that extends applications into web and=20
> mobile media. Attend the live webcast and join the prime=20
> developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=121642
> _______________________________________________
> Eclipsedotnet-developers mailing list
> Ecl...@li...
> https://lists.sourceforge.net/lists/listinfo/eclipsedotnet-developers
>=20

RE: [Eclipsedotnet-developers] SVN is on!

[Kunle O. <kun...@vi...>]

> Finally, SF.net has made available SVN for everyone! :-D
>=20
> I'll be committing all of the stuff from the old repository=20
> (CVS) to the new repository (SVN) as quick as I can (this, of=20
> course, is dependant on my very-short free time).

> I won't delete anything from CVS, but I would appreciate if=20
> someone/everyone could check the repository to make sure that=20
> everything is OK (nothing missing that you'll need, etc.).


Jo=E3o,

Did you get the time to move all the stuff across?. Should we be =
ignoring
CVS now and doing everything with SVN?

I'm just about to pull down everything from SVN.

>=20
> I don't think I'll have the time to update the build scripts=20
> for a while, so if anyone wants to do that, go for it.

Kunle

[Eclipsedotnet-developers] SVN is on!

[<jpp...@gm...>]

Finally, SF.net has made available SVN for everyone! :-D

I'll be committing all of the stuff from the old repository (CVS) to the new
repository (SVN) as quick as I can (this, of course, is dependant on my
very-short free time).

I won't delete anything from CVS, but I would appreciate if someone/everyone
could check the repository to make sure that everything is OK (nothing
missing that you'll need, etc.).

I don't think I'll have the time to update the build scripts for a while, so
if anyone wants to do that, go for it.

BTW, since the SVN repository doesn't feature a Branch/Trunk structure, I
took the liberty of adopting something like this:

\www
\docs
\src
	\java_src
	\src_platform
		\ToDeploy
		\Development
		\Trunk
	\src_emf
	\src_gef

The "ToDeploy" directories were already present in the CVS repository, and
are used to support Nant in the process of deploying auxilliary files
(plugin manifests, etc). The "Development" and "Trunk" directories are new
and do exactly what they say they do: hold the development and "stable"
versions of the code. This will allow one to hold the latest released/stable
version of the platform in the Trunk and hold new under-development features
(such as WinForms UI) in Development, until they are stable enough to be
used by the Platform and to be released.

By the time you receive this mail, we should already have most (if not all)
of the contents of the old repository in SVN.


Regards,
JS

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 268.1.0/269 - Release Date: 24-02-2006
 

Re: [Eclipsedotnet-developers] UML modeller

[<jpp...@gm...>]

S3VubGUsIEkgZGlkbid0IGtub3cgeW91IHdlcmUgc3RpbGwgYWltaW5nIGZvciB0aGUgMy54LXN0
eWxlIGNvcmUgcnVudGltZS4KR29vZCB0byBrbm93IHRoYXQsIHRob3VnaC4gOi0pIEJUVywgSSBk
aWRuJ3QgbWVhbiB0byBydXNoIGFueXRoaW5nOyB0aGUKcHJldmlvdXMgbWFpbCB3YXMganVzdCBt
eSBhdHRlbXB0IHRvIGdldCB1cyB0byAic3RhbmRhcmRpemUiIG91cgptb2RlbC1kcml2ZW4gZGV2
ZWxvcG1lbnQgYXBwcm9hY2ggOy0pIC4KCk5vdywgdG8gYWRkIHRvIHRoZSBsaXN0LCBoZXJlIGFy
ZSB0aGUgVU1MIG1vZGVsbGVycyBJIGtub3cgb2Y6CgpSYXRpb25hbCBSb3NlIC0gbm90IGZyZWU7
IHRoZSAyMDAzIGVkaXRpb24gKHRoZSBvbmx5IG9uZSBJIGhhdmUgdXNlZCkgb25seQpzdXBwb3J0
cyBVTUwxLjQgKGZvciBvYnZpb3VzIHJlYXNvbnMuLi4pCkVudGVycHJpc2UgQXJjaGl0ZWN0IC0g
bm90IGZyZWU7IGVhc3kgdG8gdXNlOyBzdXBwb3J0cyBVTUwyLjAKQXJnb1VNTCAtIGxpa2UgeW91
IHNhaWQsIGl0J3MgZnJlZTsgaG93ZXZlciwgZnJvbSB3aGF0IEkndmUgc2VlbiwgaXQgZG9lc24n
dApzdXBwb3J0IFVNTDIuMCB5ZXQgKGV2ZW4gdGhvdWdoIHRoZSBwYWdlIHNheXMgaXQgZG9lcy4u
LikKUG9zZWlkb24gLSBoZWFyZCBhYm91dCBpdCwgbmV2ZXIgdXNlZCBpdDsgSSdtIGRvd25sb2Fk
aW5nIHRoZSBmcmVlIGVkaXRpb24Kbm93IGJ1dCwgZnJvbSB3aGF0IEkndmUgcmVhZCwgaXQgbWln
aHQgYmUgYSBnb29kIGNhbmRpZGF0ZQpNb25vVU1MIC0gSSd2ZSB0YWtlbiBhIGxvb2sgYXQgaXQu
IEFsdGhvdWdoIHRoZSBkZXZlbG9wbWVudCBlZmZvcnQgc2VlbXMgdG8KcHJvZ3Jlc3MgbmljZSBh
bmQgc3RlYWR5IChpbnN0ZWFkIG9mIHRoZSB1c3VhbCAiaGlja3VwLWRldmVsb3BtZW50IiksIGl0
CnN0aWxsIGFwcGVhcnMgdG8gYmUgYSBiaXQgZWFybHkgdG8gdXNlIGl0LgpWUyAyMDA1IC0gSSBk
b24ndCBrbm93IGlmIHRoZSBFeHByZXNzIEVkaXRpb24gYWxzbyBmZWF0dXJlcyB0aGUgQ2xhc3MK
RGVzaWduZXIgKEkgd291bGQgc3VwcG9zZSBub3QpLCBidXQgSSBmcmFua2x5IGRvbid0IGxpa2Ug
aXQgdmVyeSBtdWNoLiBXaHksCkkgY2FuJ3Qgc2F5IC0gSSBqdXN0IGRvbid0IGxpa2UgaXQuIDot
KCBCdXQgSSdsbCBiZSB3aWxsaW5nIHRvIHVzZSBpdCwgaWYgd2UKZGVjaWRlIHRvIHVzZSBpdC4K
ClRoaXMgaXMgbXkgc2hvcnQtcmFuZ2UgYW5hbHlzaXMgb2YgdGhlIHBvdGVuY2lhbCB0b29scy4g
SSBjb3VsZCBiZQpjb21wbGV0ZWx5IHdyb25nIGFib3V0IHNvbWUgb2YgdGhlIHRoaW5ncyBJIG1l
bnRpb25lZCwgc28gaWYgYW55b25lIGhhcyBhbnkKaW5mbywgZmVlbCBmcmVlIHRvIHNheSBzby4K
CldlbGwsIHRoZSBQb3NlaWRvbiBkb3dubG9hZCBoYXMganVzdCBmaW5pc2hlZCBhcyBJIHdyaXRl
IHRoaXMsIHNvIEknbGwgdGFrZQphIGxvb2sgYXQgaXQgYW5kIHNheSBzb21ldGhpbmcgYWJvdXQg
dGhhdC4KCkxhdGVyLCBwZW9wbGUuCgpCZXN0IHJlZ2FyZHMsCkpTCgoKT24gMi8yMy8wNiwgS3Vu
bGUgT2R1dG9sYSA8a3VubGUub2R1dG9sYUB2aXJnaW4ubmV0PiB3cm90ZToKPgo+IEhpLAo+Cj4g
PiBJIHRoaW5rIGl0J3MgdGltZSB3ZSBzdGFydCB0aGlua2luZyBhYm91dAo+ID4gInVwZ3JhZGlu
ZyIvZXZvbHZpbmcgRWNsaXBzZS5ORVQncyB0ZWNobm9sb2dpY2FsIGFyY2hpdGVjdHVyZQo+ID4g
KGJvdGggaW4gaXRzIHBsdWdpbiBhcmNoaXRlY3R1cmUsIGFuZCBtYXliZSBpbiBpdHMgVUkgbGF5
ZXIKPiA+IGFzIHdlbGwpLiBXaGF0IEkgbWVhbiBieSB0aGlzIGlzIHRoYXQgd2Ugc2hvdWxkIHN0
YXJ0Cj4gPiB0aGlua2luZyBhYm91dCB1cGdyYWRpbmcgdGhlIGN1cnJlbnQgKGFuZCB0ZXJyaWJs
ZSkgaW1wbGVtZW50YXRpb24uCj4KPiBTdGlsbCB0cnlpbmcgdG8gZmluZCB0aW1lIHRvIGNvbnRp
bnVlL2NvbXBsZXRlIG15IHdvcmsgb24gdGhlIDMueAo+IGNvcmUvcnVudGltZS4KPgo+ID4gQnV0
IHRoZSBwb2ludCBvZiB0aGlzIG1haWwgaXMgdGhhdCBJIGJlbGlldmUgd2Ugc2hvdWxkIGZpcnN0
Cj4gPiBzdGFydCBieSBkb2luZyBzb21lL2EtbG90LW9mIHNjaGVtYXRpY3MgKEkgd291bGQgb3B0
IGZvciBVTUwKPiA+IGRpYWdyYW1zKSBmb3IgdGhpcywgYmVmb3JlIHdlIHN0YXJ0IGRldmVsb3Bp
bmcgY29kZSwgc28gdGhhdAo+ID4gd2UgY2FuIGNhdGNoL3NvbHZlIGFzIG1hbnkgcHJvYmxlbXMg
YXMgcG9zc2libGUgaW4gZGVzaWduCj4gPiB0aW1lLiBTbywgd2hhdCBJIHdhbnRlZCB0byBrbm93
IGlzOiB3aGljaCBVTUwgbW9kZWxsZXIgd291bGQKPiA+IHlvdSBwcmVmZXIgdG8gdXNlIChpZiBh
bnkpPwo+ID4KPiA+IEl0IHdvdWxkIGJlIHByZWZlcmFibGUgdGhhdCBldmVyeW9uZSB1c2VkIHRo
ZSBzYW1lIG1vZGVsbGVyLAo+ID4gc28gdGhhdCB0aGUgZGlhZ3JhbXMgd2lsbCBhbHdheXMgbG9v
ayB0aGUgc2FtZSBmb3IgZXZlcnlvbmUuCj4gPiBXZSBfY291bGRfIGV4cG9ydCB0aGUgZGlhZ3Jh
bXMgdG8gWE1JIGFuZCBpbXBvcnQgdGhlbSBpbgo+ID4gYW5vdGhlciB0b29sLCBidXQgWE1JIGRp
YWdyYW0gaW1wb3J0L2V4cG9ydCBub3dhZGF5cyBpcy4uLgo+ID4gd2VsbCwgY3JhcHB5LiA6LSgg
KE1heWJlIHdoZW4gZXZlcnlvbmUgc3RhcnRzIGZvbGxvd2luZyBPTUcncwo+ID4gRGlhZ3JhbSBJ
bnRlcmNoYW5nZSBzcGVjaWZpY2F0aW9uLCB0aGlzIHdpbGwgY2hhbmdlLi4uKS4gSQo+ID4gYmVs
aWV2ZSBpdCB3b3VsZCBhbHNvIGJlIHByZWZlcmFibGUgdGhhdCB0aGUgbW9kZWxsZXIgdXNlZAo+
ID4gd291bGQgYmUgZnJlZS9vcGVuLXNvdXJjZSAoYWx0aG91Z2ggSSB3b3VsZCBwbGFjZSBtb3Jl
IGZvY3VzCj4gPiBvbiB0aGUgImZyZWUiIHBhcnQpLCBzbyB0aGF0IGV2ZXJ5b25lIGNvdWxkIGFj
Y2VzcyBpdCB3aXRob3V0Cj4gPiBhbnkgKGxlZ2FsKSBwcm9ibGVtcy4KPgo+IFNvbWUgY2hvaWNl
cyB0byBjb25zaWRlciB3b3VsZCBpbmNsdWRlOgo+IC0gUG9zZWlkb24gZm9yIFVNTCAoY29tbWVy
Y2lhbCBKYXZhIC0gZ3JldyBvdXQgb2YgQXJnb1VNTCwgaGFzIGZyZWUKPiBlZGl0aW9uKQo+IC0g
QXJnb1VNTCAob3BlbiBzb3VyY2UgSmF2YSAtIHVzZWQgaXQgbWFueSB5ZWFycyBhZ28sIHdhcyBh
IGJpdCBmbGFreSkKPiAtIE1vbm9VTUwgKG9wZW4gc291cmNlIEMjIC0gbmV2ZXIgdXNlZCBpdCkK
PiAtIFZTIDIwMDUKPgo+IENoZWVycywKPgo+IEt1bmxlCj4KPgo+Cj4gLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+IFRoaXMgU0YuTmV0IGVt
YWlsIGlzIHNwb25zb3JlZCBieSB4UE1MLCBhIGdyb3VuZGJyZWFraW5nIHNjcmlwdGluZwo+IGxh
bmd1YWdlCj4gdGhhdCBleHRlbmRzIGFwcGxpY2F0aW9ucyBpbnRvIHdlYiBhbmQgbW9iaWxlIG1l
ZGlhLiBBdHRlbmQgdGhlIGxpdmUKPiB3ZWJjYXN0Cj4gYW5kIGpvaW4gdGhlIHByaW1lIGRldmVs
b3BlciBncm91cCBicmVha2luZyBpbnRvIHRoaXMgbmV3IGNvZGluZwo+IHRlcnJpdG9yeSEKPiBo
dHRwOi8vc2VsLmFzLXVzLmZhbGthZy5uZXQvc2VsP2NtZGxuayZraWQRMDk0NCZiaWQkMTcyMCZk
YXQSMTY0Mgo+IDxodHRwOi8vc2VsLmFzLXVzLmZhbGthZy5uZXQvc2VsP2NtZGxuayZraWQlMTEw
OTQ0JmJpZCQxNzIwJmRhdCUxMjE2NDI+Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KPiBFY2xpcHNlZG90bmV0LWRldmVsb3BlcnMgbWFpbGluZyBsaXN0
Cj4gRWNsaXBzZWRvdG5ldC1kZXZlbG9wZXJzQGxpc3RzLnNvdXJjZWZvcmdlLm5ldAo+IGh0dHBz
Oi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL2VjbGlwc2Vkb3RuZXQtZGV2
ZWxvcGVycwo+Cg==

RE: [Eclipsedotnet-developers] UML modeller

[Kunle O. <kun...@vi...>]

Hi,
=20
> I think it's time we start thinking about=20
> "upgrading"/evolving Eclipse.NET's technological architecture=20
> (both in its plugin architecture, and maybe in its UI layer=20
> as well). What I mean by this is that we should start=20
> thinking about upgrading the current (and terrible) implementation.

Still trying to find time to continue/complete my work on the 3.x
core/runtime.

> But the point of this mail is that I believe we should first=20
> start by doing some/a-lot-of schematics (I would opt for UML=20
> diagrams) for this, before we start developing code, so that=20
> we can catch/solve as many problems as possible in design=20
> time. So, what I wanted to know is: which UML modeller would=20
> you prefer to use (if any)?
>
> It would be preferable that everyone used the same modeller,=20
> so that the diagrams will always look the same for everyone.=20
> We _could_ export the diagrams to XMI and import them in=20
> another tool, but XMI diagram import/export nowadays is...=20
> well, crappy. :-( (Maybe when everyone starts following OMG's=20
> Diagram Interchange specification, this will change...). I=20
> believe it would also be preferable that the modeller used=20
> would be free/open-source (although I would place more focus=20
> on the "free" part), so that everyone could access it without=20
> any (legal) problems.

Some choices to consider would include:
- Poseidon for UML (commercial Java - grew out of ArgoUML, has free =
edition)
- ArgoUML (open source Java - used it many years ago, was a bit flaky)
- MonoUML (open source C# - never used it)
- VS 2005

Cheers,

Kunle

[Eclipsedotnet-developers] UML modeller

[<jpp...@gm...>]

I think it's time we start thinking about "upgrading"/evolving Eclipse.NET's
technological architecture (both in its plugin architecture, and maybe in
its UI layer as well). What I mean by this is that we should start thinking
about upgrading the current (and terrible) implementation.

But the point of this mail is that I believe we should first start by doing
some/a-lot-of schematics (I would opt for UML diagrams) for this, before we
start developing code, so that we can catch/solve as many problems as
possible in design time. So, what I wanted to know is: which UML modeller
would you prefer to use (if any)?

It would be preferable that everyone used the same modeller, so that the
diagrams will always look the same for everyone. We _could_ export the
diagrams to XMI and import them in another tool, but XMI diagram
import/export nowadays is... well, crappy. :-( (Maybe when everyone starts
following OMG's Diagram Interchange specification, this will change...).
I believe it would also be preferable that the modeller used would be
free/open-source (although I would place more focus on the "free" part), so
that everyone could access it without any (legal) problems.


Put your opinions in this mailing list, people.


Best regards,
JS


P.S.: I know everyone is horribly busy. I am too. But when I say that we
should start doing this, I only mean that maybe we should start putting some
spare time (if any is available) into this. Don't interpret this as pressure
to commit stuff ;-) .




-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 268.0.0/266 - Release Date: 21-02-2006
 

RE: [Eclipsedotnet-developers] OSGi for .NET implementation

[<jpp...@gm...>]

> -----Original Message-----
> From: ecl...@li... 
> [mailto:ecl...@li...] 
> On Behalf Of Kunle Odutola
> Sent: quarta-feira, 1 de Fevereiro de 2006 1:38
> To: ecl...@li...
> Subject: RE: [Eclipsedotnet-developers] OSGi for .NET implementation
> 
> The Site FAQ lists "fee...@ti..." as the address for 
> help and feedback.

Yes, I found it out after some digging. They _should_ have it on their
homepage, however... And that's the address where I sent those 2 mails (and
got no reply). :\

> Raised an issue for this.

OK, thanks. Only supporting port 80 and not any other (not usually filtered
port) is a great limitation on their part, it would seem.

BTW, according to SF.net's SVN FAQ, the port will be on 443 (HTTPS), so HTTP
requests should not be filtered by any proxies. \o/

Regards,
JS

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.25/247 - Release Date: 31-01-2006
 

RE: [Eclipsedotnet-developers] OSGi for .NET implementation

[Kunle O. <kun...@vi...>]

> 1) SVN - I've been looking at things (i.e., SF.net vs. 
> Tigris.org) and, frankly, I'm a tad disappointed with Tigris. 
> The reasons for this are:
> - Their site is frankly lacking in important info (the most 
> important lack I noticed is ease to find an e-mail address to 
> send questions)

The Site FAQ lists "fee...@ti..." as the address for help and
feedback.

> - I sent 2 e-mails to them questioning whether they had an 
> alternative port to use their SVN repositories, other than 
> port 80 (HTTP), as my workplace's proxy filters out SVN HTTP 
> requests. I received no reply to either of them.

Raised an issue for this.

> And, 
> personally, I like SF.net better :) . So, I'm waiting for 
> SF's SVN (that should come in February). But that doesn't 
> mean we shouldn't work on the platform until then.

;-)

Cheers,

Kunle

RE: [Eclipsedotnet-developers] OSGi for .NET implementation

[<jpp...@gm...>]

No problem. Glad to have you back :-) .


No ground-breaking news here, too. BTW, I'm replying here to all the =
mails
so as not to clutter the mailing list (any more than I cluttered it =
lately,
anyway :-P ).

1) SVN - I've been looking at things (i.e., SF.net vs. Tigris.org) and,
frankly, I'm a tad disappointed with Tigris. The reasons for this are:
- Their site is frankly lacking in important info (the most important =
lack I
noticed is ease to find an e-mail address to send questions)
- I sent 2 e-mails to them questioning whether they had an alternative =
port
to use their SVN repositories, other than port 80 (HTTP), as my =
workplace's
proxy filters out SVN HTTP requests. I received no reply to either of =
them.
And, personally, I like SF.net better :) . So, I'm waiting for SF's SVN
(that should come in February). But that doesn't mean we shouldn't work =
on
the platform until then.

2) OSGi - That was exactly my greatest doubt about OSGi on .NET: "would =
OSGi
be adaptable to the .NET life-style?". Since it apparently would not, I
guess we should start thinking about putting our Core subproject as best =
as
possible (in order to stabilize the API ASAP), and implement some useful
features into it (perhaps some features that OSGi has, but implemented =
from
root by us.
Kunle, since you have taken the greatest in-depth look at the OSGi
internals, would you like to "coordinate" this? Feel free to use the =
SF.net
tasks (use the Tasks tab; I have already inserted some sub-projects into =
it)
to create whichever tasks you see necessary, and I'll put whatever =
little
spare time I have into it.


Regards,
JS


> -----Original Message-----
> From: ecl...@li...=20
> [mailto:ecl...@li...]=20
> On Behalf Of Kunle Odutola
> Sent: ter=E7a-feira, 31 de Janeiro de 2006 11:05
> To: ecl...@li...
> Subject: RE: [Eclipsedotnet-developers] OSGi for .NET implementation
>=20
> > BTW, Kunle, I just remembered this: Physalis is (was) a=20
> project that=20
> > attempted to create an OSGi implementation for the .NET Compact=20
> > Framework. It is located at=20
> > http://developer.berlios.de/projects/physalis/ . According to its=20
> > authors, it's not complete, but it could give some leverage=20
> to get you=20
> > started (if you haven't already).
>=20
> Thanks for the info. I have had a look at Physalis already.=20
> It's a little raw/incomplete but OSGi is too tied to Java IMO.
>=20
> Been a little busy since the year began. Hoping to catch a break soon.
>=20
> Kunle
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep=20
> through log files for problems?  Stop!  Download the new AJAX=20
> search engine that makes searching your log files as easy as=20
> surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&
> dat=3D121642
> _______________________________________________
> Eclipsedotnet-developers mailing list
> Ecl...@li...
> https://lists.sourceforge.net/lists/listinfo/eclipsedotnet-developers
>=20
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.375 / Virus Database: 267.14.23/242 - Release=20
> Date: 26-01-2006
> =20
>=20

--=20
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.25/246 - Release Date: =
30-01-2006
=20

RE: [Eclipsedotnet-developers] Some considerations to plague our Christmas...

[Kunle O. <kun...@vi...>]

> - Nant
>=20
> As I have said in the last 2 days, the platform can now be=20
> build using Nant scripts (i.e., no VS needed).

Woo-hoo!


> - SWT_UI
>=20
> SWT_UI has had a lot of bug corrections, as you may have=20
> noticed. However, as Kunle Odutola pointed out some time ago,=20
> the SWT plugin is still using IKVM (and I think that is one=20
> big reason of why the platform is so slow and
> memory-consuming: the average memory used is about 40 MBs,=20
> which I consider very heavy). So, a conversion of SWT to C#=20
> could be based entirely on System.Drawing or (like Eclipse's=20
> SWT approach) defining an API in managed code, and that API=20
> would sometimes invoke platform-specific code. I personally=20
> would go for the System.Drawing approach, as it would make=20
> porting to other platforms (like Mono on Windows, Linux,=20
> etc.) much easier (it would only depend on System.Drawing=20
> being available in such a platform).

+1

> - AppDomains
>=20
> OK. Long one approaching. Take a deep breath and then dive in.
>=20
> After doing some research on AppDomains, I jotted down the=20
> ups and downs of using AppDomains in the plug-in based=20
> architecture. They are:
>=20
> + supports unloading of Assemblies (IF they are not domain-neutral)
> - each assembly should have multiple copies of itself in some=20
> AppDomains (and subsequent overhead of JITting for each=20
> assembly), because of assembly dependencies (again, unless=20
> the assemblies were loaded as domain-neutral; in that case,=20
> there would be only 1 copy of each assembly in the entire
> Application)
> - performance hit (due to crossing of AppDomain boundaries)
> - no LoadFrom() methods like in Assembly class, only Load()=20
> methods (i.e., you can only load strong-named assemblies)
> - an assembly is only unloaded (when the corresponding AppDomain is
> unloaded) if it is not domain-neutral; otherwise, the=20
> (domain-neutral) assembly will only be unloaded when the=20
> process is terminated
> + increased security (an assembly going kaboom in 1 AppDomain will not
> affect other AppDomains)
>=20
> All this said, I started thinking about the implications of=20
> using AppDomains in our plugin architecture. I think the=20
> performance hit would be worth it, given the increased=20
> security advantage. And the usage of AppDomains would=20
> certainly be appliable to a plugin architecture where plugins=20
> are not related to one another (no dependencies on each other, etc.).
>=20
> However, there are some aspects of our architecture that should be
> considered:
>=20
> A - plugins _are_ aware of each other, as they can be related=20
> (through plugin imports)
>=20
> Because of Statement A, I guess we have 2 choices: load all=20
> assemblies as domain-neutral or in each AppDomain, load a=20
> copy of all necessary assemblies (plugin assemblies +=20
> assemblies of plugins imports). I think the second choice is=20
> unacceptable, as this would boost memory consumption n-fold.=20
> However, if we go towards the first choice, we can't unload=20
> assemblies (because they're domain-neutral).

Load all plug-ins into a second appdomain that can be recreated on =
demand.
All plug-ins implement interfaces in a helper assembly that can be =
loaded as
domain-neutral?. All interaction with plug-ins is via the interface.

This needs testing/refining/validation actually. Just off the top of my
head.

Kunle

RE: [Eclipsedotnet-developers] Project status report

[Kunle O. <kun...@vi...>]

> OK, this mailing list has been very quiet lately (too quiet, IMHO).

;-)

> So, I think a kind-of status report is in order here (it 
> would be useful for archives, for one).
> 
> 
> David and Rui have been developing some plugins for 
> Eclipse.NET (related to ProjectIT-Studio, about which you can 
> read in the paper I made available in the docs_platform CVS 
> repository module). Although these plugins do not directly 
> contribute to the Eclipse.NET project, they allow us to test (and
> correct) various aspects of the platform.

Cool.

> On my part, I have been working on some other plugins: GEF 
> (Graphical Editing Framework) and EMF (Eclipse Modelling 
> Framework). GEF because I believe a graphical modelling 
> framework will be very important (if not
> fundamental) to a wide acceptance of the platform by other 
> developers (and, let's face it, we need other - non-platform 
> - developers if we are to test the platform thoroughly). EMF 
> is also very important because of Eclipse's MDA approach 
> (which, among other things, allows developers to create 
> plugins from a model); also, my topic in my Advanced Topics 
> course is related to MDA and EMF :-P . In the future (after 
> these two are stable in the .NET environment), I think it 
> would be worthwhile to look at GMF (Graphical Modelling 
> Framework), that tries to make a bridge between these two. As 
> anyone who's been monitoring the commits mailing list can 
> see, I haven't made many corrections to the Platform itself, 
> due mostly to lack of time (I have a zillion things to do 
> right now, as Rui and David can testify; and I still have 
> ProjectIT-Studio to make as well...).
> 
> Kunle, from a little "surfing the net" (and some forums), I 
> figure you are trying to implement the OSGi layer in .NET 
> (for use by Eclipse.NET, I assume). If this is so, do you 
> need some help from me (or anyone else)? I could always 
> squeeze some time into developing that layer too. And just 
> out of curiosity, how is that going?

Very slowly. OSGi and .NET don't mesh too well. Too Java-centric it is. I
just wanted a .NET tools platform comparable to Eclipse 3.2+.

> Oh, before I forget: About SVN. SF.net has _finally_ started 
> implementing their SVN repositories, but they will only be 
> available to all projects in mid-2006, I believe (or later). 
> IMHO, this is a lot of time to wait. So, Kunle, is that 
> Eclipse.NET project you registered to Tigris.org to be used 
> (namely, it's SVN repository)?

Maybe. Are we waiting on SF.net's SVN support?


Kunle

RE: [Eclipsedotnet-developers] OSGi for .NET implementation

[Kunle O. <kun...@vi...>]

> BTW, Kunle, I just remembered this: Physalis is (was) a 
> project that attempted to create an OSGi implementation for 
> the .NET Compact Framework. It is located at 
> http://developer.berlios.de/projects/physalis/ . According to 
> its authors, it's not complete, but it could give some 
> leverage to get you started (if you haven't already).

Thanks for the info. I have had a look at Physalis already. It's a little
raw/incomplete but OSGi is too tied to Java IMO.

Been a little busy since the year began. Hoping to catch a break soon.

Kunle

FW: [Eclipsedotnet-developers] RE: Project status report

[<jpp...@gm...>]

I noticed just now that this message should actually have gone to the
mailing list...

Regards
JS

> -----Original Message-----
> From: da...@me... [mailto:da...@me...]=20
> Sent: quarta-feira, 18 de Janeiro de 2006 18:41
> To: Jo=E3o Saraiva
> Subject: Re: [Eclipsedotnet-developers] RE: Project status report
>=20
> Hi everyone!
>=20
> At the moment this issue does not affect me much, because I?m=20
> not actively working on it so I just get the sources=20
> sporadically when new relevant changes are made.
>=20
> Personally I prefer SVN, so IMHO I think we should wait for SF.net.
>=20
>=20
> Best regards,
> David Ferreira
>=20
>=20
>=20
>=20
> Quoting Jo=E3o Saraiva <jpp...@gm...>:
>=20
> > Hmmm. From
> >=20
> =
http://sourceforge.net/docman/display_doc.php?group_id=3D1&docid=3D19242#=
j
> > anuary
> > -2006 we will apparently have SVN support in February (not in=20
> > mid-2006; it seems they moved fast on this one :-D ). So=20
> maybe we can=20
> > wait a bit and use the SF.net SVN repository.
> >
> > What do you people think about this? SF.net or Tigris.org?=20
> Or stick to=20
> > CVS :-( ?
> >
> > Best regards,
> > JS
> >
> >> -----Original Message-----
> >> From: Jo=E3o Saraiva [mailto:jpp...@gm...]
> >> Sent: quarta-feira, 11 de Janeiro de 2006 18:05
> >> To: 'ecl...@li...'
> >> Subject: Project status report
> >>
> >> [...]
> >>
> >> Oh, before I forget: About SVN. SF.net has _finally_ started=20
> >> implementing their SVN repositories, but they will only be=20
> available=20
> >> to all projects in mid-2006, I believe (or later).
> >> IMHO, this is a lot of time to wait.
> >>
> >> [...]
> >
> > --
> > No virus found in this outgoing message.
> > Checked by AVG Free Edition.
> > Version: 7.1.375 / Virus Database: 267.14.20/233 - Release Date:=20
> > 18-01-2006
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep=20
> through log=20
> > files for problems?  Stop!  Download the new AJAX search=20
> engine that=20
> > makes searching your log files as easy as surfing the  web.=20
>  DOWNLOAD SPLUNK!
> > =
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=103432&bid#0486&dat=121642
> > _______________________________________________
> > Eclipsedotnet-developers mailing list
> > Ecl...@li...
> >=20
> https://lists.sourceforge.net/lists/listinfo/eclipsedotnet-developers
> >
>=20
>=20
>=20
>=20
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.375 / Virus Database: 267.14.20/233 - Release=20
> Date: 18-01-2006
> =20
>=20

--=20
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.21/235 - Release Date: =
19-01-2006
=20

[Eclipsedotnet-developers] RE: Project status report

[<jpp...@gm...>]

Hmmm. From
http://sourceforge.net/docman/display_doc.php?group_id=3D1&docid=3D19242#=
january
-2006 we will apparently have SVN support in February (not in mid-2006; =
it
seems they moved fast on this one :-D ). So maybe we can wait a bit and =
use
the SF.net SVN repository.

What do you people think about this? SF.net or Tigris.org? Or stick to =
CVS
:-( ?

Best regards,
JS

> -----Original Message-----
> From: Jo=E3o Saraiva [mailto:jpp...@gm...]=20
> Sent: quarta-feira, 11 de Janeiro de 2006 18:05
> To: 'ecl...@li...'
> Subject: Project status report
>=20
> [...]
>=20
> Oh, before I forget: About SVN. SF.net has _finally_ started=20
> implementing their SVN repositories, but they will only be=20
> available to all projects in mid-2006, I believe (or later).=20
> IMHO, this is a lot of time to wait.
>=20
> [...]

--=20
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.20/233 - Release Date: =
18-01-2006
=20

[Eclipsedotnet-developers] OSGi for .NET implementation

[<jpp...@gm...>]

BTW, Kunle, I just remembered this: Physalis is (was) a project that
attempted to create an OSGi implementation for the .NET Compact Framework.
It is located at http://developer.berlios.de/projects/physalis/ . According
to its authors, it's not complete, but it could give some leverage to get
you started (if you haven't already).

Also, here is the latest conversation (a few months old) from their mailing
list:


On 2/17/05, Duncan Suttles <du...@ma...> wrote:
We just joined the mailing list. We are interested in cloning the Eclipse
"Update Manager" into a .Net environment. Eclipse uses OSGI .  Is this
project alive ?
 
 
Regards
Duncan Suttles
www.magnetargames.com 



On 2/18/05, Romuald TISSERAND <sof...@ho...> wrote:
Karen has stopped her work on the project because of her technical skills.

Personnaly, I've recently decided to stop it too, not because of my skills,
but because I'll probably stop all my job and activities in computer science
to do a completely different job.

Anyway, the puslished code works well to install/start/stop bundles, it is
not complete (can't install bundle from Internet). So feel free to get it
and continue or do whatever you want.

Regards,

Romu

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.18/230 - Release Date: 14-01-2006
 

[Eclipsedotnet-developers] Project status report

[<jpp...@gm...>]

OK, this mailing list has been very quiet lately (too quiet, IMHO).

So, I think a kind-of status report is in order here (it would be useful for
archives, for one).


David and Rui have been developing some plugins for Eclipse.NET (related to
ProjectIT-Studio, about which you can read in the paper I made available in
the docs_platform CVS repository module). Although these plugins do not
directly contribute to the Eclipse.NET project, they allow us to test (and
correct) various aspects of the platform.

On my part, I have been working on some other plugins: GEF (Graphical
Editing Framework) and EMF (Eclipse Modelling Framework). GEF because I
believe a graphical modelling framework will be very important (if not
fundamental) to a wide acceptance of the platform by other developers (and,
let's face it, we need other - non-platform - developers if we are to test
the platform thoroughly). EMF is also very important because of Eclipse's
MDA approach (which, among other things, allows developers to create plugins
from a model); also, my topic in my Advanced Topics course is related to MDA
and EMF :-P . In the future (after these two are stable in the .NET
environment), I think it would be worthwhile to look at GMF (Graphical
Modelling Framework), that tries to make a bridge between these two.
As anyone who's been monitoring the commits mailing list can see, I haven't
made many corrections to the Platform itself, due mostly to lack of time (I
have a zillion things to do right now, as Rui and David can testify; and I
still have ProjectIT-Studio to make as well...).

Kunle, from a little "surfing the net" (and some forums), I figure you are
trying to implement the OSGi layer in .NET (for use by Eclipse.NET, I
assume). If this is so, do you need some help from me (or anyone else)? I
could always squeeze some time into developing that layer too. And just out
of curiosity, how is that going?


Oh, before I forget: About SVN. SF.net has _finally_ started implementing
their SVN repositories, but they will only be available to all projects in
mid-2006, I believe (or later). IMHO, this is a lot of time to wait. So,
Kunle, is that Eclipse.NET project you registered to Tigris.org to be used
(namely, it's SVN repository)? Personally speaking, I would _really_ like to
use SVN instead of CVS. The advantages that come to mind right now are
(thinking of TortoiseSVN):

- We can tidy up the repository more easily (through the Repo-Browser) (OK,
we can delete files from CVS too, but they always remain in the Attic dir;
besides, you can't delete directories :-( ; and, while browsing the
repository, you only see the latest revision, by default; so the
user/developer only sees what he really _should_ see: the repository as we
use it)
- Solving conflicts and/or incoherent state of local files (relative to the
repository) is a lot easier
- We can reorganize things (files/dirs) in a much easier fashion (this also
comes from the first advantage, but consider this: we have a lot of plugins;
some are directly related to the platform, some are not. With a project of
this magnitude, some reorganizing is bound to take place; this, in CVS,
sometimes leads to empty dirs, deprecated CVS modules, etc... This does not
happen with SVN).


OK. I can't remember anything else right now. Just as well: this mail was
getting too big :-P . Sorry to put you all through all this reading, but I
hope it's worth it.

Best regards,
JS

P.S.: If any users out there are monitoring this, feel free to drop a line!
We can always use the cheering-up (or, we can use feedback reports, if you
think you shouldn't cheer us up. :-P ).

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.17/226 - Release Date: 10-01-2006
 

[Eclipsedotnet-developers] RE: Some considerations to plague our Christmas...

[<jpp...@gm...>]

Hmm. No responses yet.

Should I assume that everyone agrees with everything that I wrote?  :-P
(Please say it ain't so...)

On another topic, I hope everyone had great holidays.

Best regards,
JS


> -----Original Message-----
> From: Jo=E3o Saraiva [mailto:jpp...@gm...]=20
> Sent: quinta-feira, 22 de Dezembro de 2005 14:51
> To: 'ecl...@li...'
> Subject: Some considerations to plague our Christmas...
>=20
> Sorry for the title, but I didn't think of anything better.
>=20
> OK, people, I expect this mail to be a bit long, so bear with=20
> me, please.
>=20
>=20
> - Nant
>=20
> ...
>=20
> ----------------------------------------
>=20
> - SWF_UI
>=20
> ...
>=20
> ----------------------------------------
>=20
> - SWT_UI
>=20
> ...
>=20
> ----------------------------------------
>=20
> - AppDomains
>=20
> ...

--=20
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.16/225 - Release Date: =
09-01-2006
=20

[Eclipsedotnet-developers] Happy New Year!

[<jpp...@gm...>]

Hi!

This mail, unlike its predecessors, is not related to Eclipse.NET. :) This
list can't (shouldn't) be all work ;) .

Just to wish you all a Happy New Year.

Regards,
JS

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.10/218 - Release Date: 02-01-2006
 

[Eclipsedotnet-developers] Some considerations to plague our Christmas...

[<jpp...@gm...>]

Sorry for the title, but I didn't think of anything better.

OK, people, I expect this mail to be a bit long, so bear with me, please.


- Nant

As I have said in the last 2 days, the platform can now be build using Nant
scripts (i.e., no VS needed). Building through Nant automatically sets up
all files in their right places for a first execution of the platform.
Building through VS only builds the assemblies, it doesn't copy the
auxilliary files necessary.
So, the bin module is now obsolete (although I haven't deleted anything from
it yet).

----------------------------------------

- SWF_UI

The src_platform module has, for some time now, included a sub-project
designated SWF_UI (short for System.Windows.Forms User Interface). I have
already committed some code to it (mostly utility classes that would be
helpful in path that we took: registries, etc.). The idea is to define a set
of plugins (like the ones for SWT) that provides a UI based on WinForms.
However, and this is a personal opinion only, I would not support a simple
"port" of Jface and above plugins to use WinForms instead of SWF; instead, I
would go for maintaining important concepts like the Viewers (which I think
give Eclipse a lot of its power) and Windows/WindowManagers (although the
Window concept would probably need some heavy adjusting, as WinForms
simplifies many of the tasks involved with creating an SWT shell/window).

----------------------------------------

- SWT_UI

SWT_UI has had a lot of bug corrections, as you may have noticed. However,
as Kunle Odutola pointed out some time ago, the SWT plugin is still using
IKVM (and I think that is one big reason of why the platform is so slow and
memory-consuming: the average memory used is about 40 MBs, which I consider
very heavy). So, a conversion of SWT to C# could be based entirely on
System.Drawing or (like Eclipse's SWT approach) defining an API in managed
code, and that API would sometimes invoke platform-specific code. I
personally would go for the System.Drawing approach, as it would make
porting to other platforms (like Mono on Windows, Linux, etc.) much easier
(it would only depend on System.Drawing being available in such a platform).

----------------------------------------

- AppDomains

OK. Long one approaching. Take a deep breath and then dive in.

After doing some research on AppDomains, I jotted down the ups and downs of
using AppDomains in the plug-in based architecture. They are:

+ supports unloading of Assemblies (IF they are not domain-neutral)
- each assembly should have multiple copies of itself in some AppDomains
(and subsequent overhead of JITting for each assembly), because of assembly
dependencies (again, unless the assemblies were loaded as domain-neutral; in
that case, there would be only 1 copy of each assembly in the entire
Application)
- performance hit (due to crossing of AppDomain boundaries)
- no LoadFrom() methods like in Assembly class, only Load() methods (i.e.,
you can only load strong-named assemblies)
- an assembly is only unloaded (when the corresponding AppDomain is
unloaded) if it is not domain-neutral; otherwise, the (domain-neutral)
assembly will only be unloaded when the process is terminated
+ increased security (an assembly going kaboom in 1 AppDomain will not
affect other AppDomains)

All this said, I started thinking about the implications of using AppDomains
in our plugin architecture. I think the performance hit would be worth it,
given the increased security advantage. And the usage of AppDomains would
certainly be appliable to a plugin architecture where plugins are not
related to one another (no dependencies on each other, etc.).

However, there are some aspects of our architecture that should be
considered:

A - plugins _are_ aware of each other, as they can be related (through
plugin imports)

Because of Statement A, I guess we have 2 choices: load all assemblies as
domain-neutral or in each AppDomain, load a copy of all necessary assemblies
(plugin assemblies + assemblies of plugins imports). I think the second
choice is unacceptable, as this would boost memory consumption n-fold.
However, if we go towards the first choice, we can't unload assemblies
(because they're domain-neutral).

So, either we stick with what we already have or we define a way to use
AppDomains in this architecture. I would personally tend towards the first,
not because of the work I invested in it but because of the practicality of
it (right now, marshalling and app-domain boundary crossing comes to mind).

Nevertheless, this is the impression I got from my research. In "real life",
things could be harder than I said (or they can also be easier). If anyone
knows something about AppDomains, be sure to put a mail in here.

----------------------------------------

Just my 0.02 * 4 cents.

I expect feedback from everyone regarding any (or all) of these matters so
"let the games begin".

Regards,
JS

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.3/209 - Release Date: 21-12-2005
 

[Eclipsedotnet-developers] RE: New Nant build files online

[<jpp...@gm...>]

I've been reviewing this and changed the build files to use the "normal"
resource naming routine (the default namespace + path from root to file =
+
file name thingie); since I named each build file's project as the =
default
namespace/plugin name and this project name can be accessed, this should
pose no problem. I also updated the resource-calling code (in the .cs =
files)
to reflect this naming.

The main reason for doing this was so that Nant was not the _only_ way =
to
correctly compile the platform; otherwise, assemblies built using VS =
would
not be able to access their own resources... This way, anyone who wants =
to
build using VS can do so (although they will have to copy auxilliary =
files
themselves...) and who wants to use Nant (probably everybody else :P ) =
can
also do it.

However, be advised. I still recommend the Nant way to build the =
platform
from scratch (because of the aux file copying thingie). If you plan to =
debug
using VS, I would recommend that you first build using Nant (so all =
files
are copied to their right places), and then build/debug using VS.


I don't remember anything else to say, so I'm off.

Regards,
JS


P.S.: To any subscribers of the eclipsedotnet-repositorycommits mailing
list: sorry for the huge load of mails yesterday :( .There were lots of =
new
directories created (because of the ToDeploy in each project dirs, and =
icon
dirs, and etc) and the cvs script automatically sends a mail when a
directory is created (this is useless in my opinion, but I don't know =
any
way to disable it), besides the mails that it sends when _real_ commits
occur. :( .

=20

> -----Original Message-----
> From: Jo=E3o Saraiva [mailto:jpp...@gm...]=20
> Sent: ter=E7a-feira, 20 de Dezembro de 2005 18:36
> To: 'ecl...@li...'
> Subject: New Nant build files online
>=20
> OK, this one is just to let you know that I _finally_ made=20
> the switch from building the Platform with VS to building=20
> with NAnt. The build files are available in the CVS=20
> repository, and there is 1 build file for each project and=20
> solution (and for the platform itself).
>=20
>=20
> For each project, I made available the targets "build" (just=20
> builds the dll and places it in the right place), "clean"=20
> (cleans the generated dlls and pdbs), "copyFiles" (copies=20
> auxilliary files, like plugin manifests, to the right place)=20
> and "deploy" (just calls "build" and "copyFiles). "build" and=20
> "copyFiles" are available only to projects (like Java or=20
> Core.Runtime).
>=20
> To build a project/plugin (like, say, Java or UI.WorkBench),=20
> go to the directory of the project and type: "nant deploy"=20
> (or "nant build"; see above for explanation).
>=20
> To build the set of Core plugins (or the SWT_UI plugins, or=20
> whatever), go to the directory where the respective solution=20
> resides and type (what else?): "nant deploy".
>=20
> To build the platform itself, go to the src_platform=20
> directory and type "nant deploy" .
>=20
>=20
> Also, I'm including in the src_platform module the libraries=20
> and other files needed to execute the platform, so that if=20
> the "bin" module has not been downloaded, "nant deploy" will=20
> indeed build everything, setting up the platform for first=20
> time use. This will also render the "bin" module obsolete=20
> (but I will not delete anything from it unless we all agree=20
> that the module is no longer needed; if anyone disagrees with=20
> this, you should let me know).
>=20
> I also took the opportunity to relocate some of the resource=20
> files, as VS has a nasty way to generate namespaces for=20
> embedded resources (I know that it should be <default=20
> namespace> + "." + <path from root of project to resource> +=20
> <name of resource> , but I've seen this rule not being=20
> applied sometimes... :\ ) So, with the new build files, the=20
> namespace should be nothing (unless otherwise specified in=20
> the build file, but I've left all resources at the empty namespace).
>=20
>=20
> Hopefully this will make it much easier to build the=20
> platform, and (finally) remove the dependency on VS that I=20
> had wanted to remove for so long a time...
>=20
> OK, nothing else coming to mind right now, so I'll end this mail here.
>=20
>=20
> If anyone has any comments, you know the address of the=20
> mailing list ;) .
>=20
>=20
> Best regards,
> JS
>=20
> P.S.: I'm still committing some of the files, so don't be=20
> surprised if some of the files don't appear right away.
>=20
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.371 / Virus Database: 267.14.1/207 - Release=20
> Date: 19-12-2005
> =20
>=20

--=20
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.2/208 - Release Date: =
20-12-2005
=20

[Eclipsedotnet-developers] New Nant build files online

[<jpp...@gm...>]

OK, this one is just to let you know that I _finally_ made the switch from
building the Platform with VS to building with NAnt. The build files are
available in the CVS repository, and there is 1 build file for each project
and solution (and for the platform itself).


For each project, I made available the targets "build" (just builds the dll
and places it in the right place), "clean" (cleans the generated dlls and
pdbs), "copyFiles" (copies auxilliary files, like plugin manifests, to the
right place) and "deploy" (just calls "build" and "copyFiles). "build" and
"copyFiles" are available only to projects (like Java or Core.Runtime).

To build a project/plugin (like, say, Java or UI.WorkBench), go to the
directory of the project and type: "nant deploy" (or "nant build"; see above
for explanation).

To build the set of Core plugins (or the SWT_UI plugins, or whatever), go to
the directory where the respective solution resides and type (what else?):
"nant deploy".

To build the platform itself, go to the src_platform directory and type
"nant deploy" .


Also, I'm including in the src_platform module the libraries and other files
needed to execute the platform, so that if the "bin" module has not been
downloaded, "nant deploy" will indeed build everything, setting up the
platform for first time use. This will also render the "bin" module obsolete
(but I will not delete anything from it unless we all agree that the module
is no longer needed; if anyone disagrees with this, you should let me know).

I also took the opportunity to relocate some of the resource files, as VS
has a nasty way to generate namespaces for embedded resources (I know that
it should be <default namespace> + "." + <path from root of project to
resource> + <name of resource> , but I've seen this rule not being applied
sometimes... :\ ) So, with the new build files, the namespace should be
nothing (unless otherwise specified in the build file, but I've left all
resources at the empty namespace).


Hopefully this will make it much easier to build the platform, and (finally)
remove the dependency on VS that I had wanted to remove for so long a
time...

OK, nothing else coming to mind right now, so I'll end this mail here.


If anyone has any comments, you know the address of the mailing list ;) .


Best regards,
JS

P.S.: I'm still committing some of the files, so don't be surprised if some
of the files don't appear right away.

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.1/207 - Release Date: 19-12-2005
 

[Eclipsedotnet-developers] RE: Version 0.03

[<jpp...@gm...>]

I forgot to say this too: I haven't upgraded the ikvmc'ed assemblies to =
the
latest version of IKVM (0.22) because of a bug in ikvmc (should be fixed =
in
0.24). You can read about it at
http://sourceforge.net/mailarchive/forum.php?thread_id=3D9241359&forum_id=
=3D1310
2 and at
http://sourceforge.net/mailarchive/forum.php?thread_id=3D9250431&forum_id=
=3D1310
2 .

Again, regards,
JS
=20

> -----Original Message-----
> From: Jo=E3o Saraiva [mailto:jpp...@gm...]=20
> Sent: sexta-feira, 16 de Dezembro de 2005 14:08
> To: 'ecl...@li...'
> Subject: Version 0.03
>=20
> I released version 0.03 to SF.
>=20
> There were only minor bug fixes (mostly due to JLCA doing a=20
> poor job of converting usages of Iterator to IEnumerator),=20
> but the noticeable change is that you can now edit text files=20
> (although there are sometimes problems saving changes... :( ).
>=20
> I also took the time to inline some methods that JLCA created=20
> and were only used once or never at all (like InitBlock() or=20
> the Enclosing_Instance property in inner classes). Since the=20
> debug-enabled assemblies usually can't change much - I=20
> suppose - (because of the need for keeping the stack trace),=20
> the JIT probably wouldn't do this inlining itself, resulting=20
> in unneeded method calls. The point is, the platform should=20
> run a wee bit faster now (and possibly have a wee bit tinier=20
> memory footprint, as I removed some unneeded references being=20
> stored by inner classes).
>=20
>=20
> Regards,
> JS
>=20
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.371 / Virus Database: 267.14.1/204 - Release=20
> Date: 15-12-2005
> =20
>=20

--=20
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.1/204 - Release Date: =
15-12-2005
=20

[Eclipsedotnet-developers] Version 0.03

[<jpp...@gm...>]

I released version 0.03 to SF.

There were only minor bug fixes (mostly due to JLCA doing a poor job of
converting usages of Iterator to IEnumerator), but the noticeable change is
that you can now edit text files (although there are sometimes problems
saving changes... :( ).

I also took the time to inline some methods that JLCA created and were only
used once or never at all (like InitBlock() or the Enclosing_Instance
property in inner classes). Since the debug-enabled assemblies usually can't
change much - I suppose - (because of the need for keeping the stack trace),
the JIT probably wouldn't do this inlining itself, resulting in unneeded
method calls. The point is, the platform should run a wee bit faster now
(and possibly have a wee bit tinier memory footprint, as I removed some
unneeded references being stored by inner classes).


Regards,
JS

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.1/204 - Release Date: 15-12-2005