Menu
▾
▴
eclipsefp-develop
|
From: Leif F. <hi...@le...> - 2004-07-19 23:03:24
|
Hi all, The new version 0.4 is now available both from the Update site at http://leiffrenzel.de/eclipse/site.xml and the sourceforge project page as archived update site. Thanks again to everybody who has helped :-) We are getting more and more to something that starts to resemble an IDE ;-) Ciao, Leif Changes ======= 2004-07-19 Interpreter support (GCHi) and more bugfixes. a.. Core a.. Before building it is now checked that the output and binary folders for the Haskell project exist (they may not, for instance if the project was just checked out from a code repository). b.. Fixed two bugs in creating the command line and the external process for the compiler (ghc-6.2.1: can't apply -o to multiple source files). Thanks to Andrei for the fix :-) b.. UI a.. You can now start an interactive GHCi session from the Run menu, with either a single source file or all source files in a project or source folder loaded. This is especially useful when you don't want to build an entire application but are working in a more scripting-like manner. |
|
From: Andrei de A. F. <arc...@ya...> - 2004-07-20 01:24:39
|
Leif, great work. Maybe we should announce it on the Haskell lists ? --- []s, Andrei de A. Formiga --- Leif Frenzel <hi...@le...> wrote: > Hi all, > > The new version 0.4 is now available both from the > Update site at > http://leiffrenzel.de/eclipse/site.xml and the > sourceforge project page as > archived update site. > > Thanks again to everybody who has helped :-) We are > getting more and > more to something that starts to resemble an IDE ;-) > > Ciao, > Leif > > > Changes > ======= > > 2004-07-19 Interpreter support (GCHi) and more > bugfixes. > > > a.. Core > a.. Before building it is now checked that the > output and binary folders > for the Haskell project exist (they may not, for > instance if the project was > just checked out from a code repository). > b.. Fixed two bugs in creating the command line > and the external process > for the compiler (ghc-6.2.1: can't apply -o to > multiple source files). > Thanks to Andrei for the fix :-) > b.. UI > a.. You can now start an interactive GHCi > session from the Run menu, > with either a single source file or all source files > in a project or source > folder loaded. This is especially useful when you > don't want to build an > entire application but are working in a more > scripting-like manner. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic > Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 > today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > eclipsefp-develop mailing list > ecl...@li... > https://lists.sourceforge.net/lists/listinfo/eclipsefp-develop > __________________________________ Do you Yahoo!? Vote for the stars of Yahoo!'s next ad campaign! http://advision.webevents.yahoo.com/yahoo/votelifeengine/ |
|
From: Andrei de A. F. <arc...@ya...> - 2004-07-20 03:44:24
|
Hi Leif, As I may have some extra free time after I complete a project at work (2 weeks left), I was thinking about trying my hand at an OCaml plugin. The idea was to see how you've done with the haskell support and try similar things for OCaml. Now, I don't know if I will ever have anything ready. But, if I do and I intend to release the code, do you think it's better to have this in a separate project ? --- []s, Andrei de A. Formiga __________________________________ Do you Yahoo!? Vote for the stars of Yahoo!'s next ad campaign! http://advision.webevents.yahoo.com/yahoo/votelifeengine/ |
|
From: Leif F. <hi...@le...> - 2004-07-20 10:03:00
|
Hi Andrei, > As I may have some extra free time after I complete > a project at work (2 weeks left), I was thinking about > trying my hand at an OCaml plugin. The idea was to see > how you've done with the haskell support and try > similar things for OCaml. > > Now, I don't know if I will ever have anything > ready. But, if I do and I intend to release the code, > do you think it's better to have this in a separate > project ? You are of course most welcome if you would put it into the eclipsefp project :-) In fact, I had from the very start an idea of having some common basis (language-neutral, providing infrastructure) and building not only Haskell support, but also support for other languages on top of it. (That's why I called it 'eclipsefp' intentionally, leaving the possibility to extend it to more functional languages.) Also, the whole architecture is based on this split between language-neutral and language-specific. Using the common.* plugins it should be possible to get some things (like e.g. the New Project wizards) implemented relatively painless. I intend to make more of the stuff in the Haskell plugins more general and put it into the common plugins (e.g. the compiler support). You could just play around with that and have the OCaml support built on top of them (any feedback about how this works out would be appreciated :-). Ciao, Leif |
|
From: Andrei de A. F. <arc...@ya...> - 2004-07-21 01:19:50
|
--- Leif Frenzel <hi...@le...> wrote: > Hi Andrei, > You are of course most welcome if you would put it > into the eclipsefp > project :-) In fact, I had from the very start an > idea of having some common > basis (language-neutral, providing infrastructure) > and building not only > Haskell support, but also support for other > languages on top of it. (That's > why I called it 'eclipsefp' intentionally, leaving > the possibility to extend > it to more functional languages.) > Ok, that's interesting. I have one operational question and the others are from an eclipse semi-newbie :) If you have the time to answer them to me, it'd be great. The operational question is: should the package name be net.eclipsefp.ocaml or something other ? The questions about eclipse are: - the haskell plugins have a "base" plugin (de.leiffrenzel.fp.haskell) with no code and then core, ui, doc, source plugins (which I believe is a common structure). I wonder about this base haskell plugin... why do you need it ? - I don't understand (or can't find) the dependencies between plugins, sure they should be specified somewhere ? Besides, I don't know nothing about deployment, but I'll worry about this later, and read about it. Most of my reading material on eclipse is now dated (2.x), and I hope it's not too different. --- []s, Andrei de A. Formiga __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail |
|
From: Leif F. <hi...@le...> - 2004-07-21 11:39:56
|
Hi Andrei, > The operational question is: should the package > name be net.eclipsefp.ocaml or something other ? I would suggest that the general prefix for all plugins from the project should be net.sf.eclipsefp.*, which is in accord with the usual Java / Eclipse conventions. Everything below can be structured freely by us. I would say, we should divide the packages roughly into subprojects, that means net.sf.eclipsefp.common.* - language-independent common stuff net.sf.eclipsefp.haskell.* - Haskell net.sf.eclipsefp.ocaml.* - OCaml etc. This means of course also changing all the existing stuff from using the de.leiffrenzel.fp.* namespace to using net.sf.eclipsefp.*. I think I will do that sometimes in the near future, but this is something that must be done careful (many ids etc. in xml files are affected) because it is so error-prone, so I will do it on an occasion where I have at least a free weekend ... It is also somewhat of a problem for people who have an older version, because installing the new net.sf.eclipsefp.* plugins and features may leave the old de.leiffrenzel.fp.* stuff in place, and they could interfere with each other. We will have to ask users to completely remove the old plugins when installing the new version. > The questions about eclipse are: > > - the haskell plugins have a "base" plugin > (de.leiffrenzel.fp.haskell) with no code and then > core, ui, doc, source plugins (which I believe is a > common structure). I wonder about this base haskell > plugin... why do you need it ? Yes, you are right about the common structure. This follows also the recommendations of Erich Gamma and Kent Beck in their 'Contributing to Eclipse', which is, btw, a good read for details on Eclipse and Plugin Development. The base plugin contains usually branding, Welcome content (that is, stuff that gets displayed on the Intro pages) and other global configuration (like what is in the About dialog) for the plugins collected in a feature. The thing to keep in mind is that features are only a mechanism for servicing (that is, installing, updating, licensing), but contain no actual funtionality, not even icons. Once all plugins of a feature are installed, it is in principle unnecessary and unused in the workings of the Eclipse platform itself. It comes only into play again if you want to update/re-install/disable. But there is some global stuff, like about texts, icons, etc., which is not associated with a particular plugin, but rather with the bundle. And it is the convention to have these things in a plugin that has the same plugin id as the feature id of the corresponding feature. Some parts of the Eclipse platform (e.g. the About dialog) expect their configuration (about icons, about texts) in that plugin. I believe that these thing will be change in the future a little bit. Some of the plan items in the Eclipse project plans say that the configuration issues (branding) should be decoupled from the update issues (feature organization). But I don't know the exact details of the plans (they are usually hidden in some Bugzilla feature requests on the eclipse.org site). It is also often the case that you have not multiple plugins, but only one in a feature. (Where you have a small tool in one plugin but want to add a feature to make that plugin servicable.) In such a case, the natural thing wuld be to have an equally named feature and plugin, and you would then have the branding and the code both in the plugin. Another case where you need the base plugin is when you have not a feature for the Eclipse platform, but an RCP application (standalone Eclipse-based application). In that case you have some global things to implement (application runnable, basic workbench configuration) which also would have their place in the base plugin (not in the core/ui/... plugins), as it is more or less generic runtime stuff. > - I don't understand (or can't find) the > dependencies between plugins, sure they should be > specified somewhere ? They are declared in the plugin.xml. If you open the plugin.xml editor, there is a tab named 'Dependencies'. You must declare all plugins on which the plugin depends. Once you have declared a plugin A dependent on a plugin B, you can use all (public) classes and all extension points of B in developing the plugin A. > Besides, I don't know nothing about deployment, but > I'll worry about this later, and read about it. Most > of my reading material on eclipse is now dated (2.x), > and I hope it's not too different. No, there is not much difference in these things in Eclipse 3; but the support in PDE has somewhat improved. It is not a big issue and can be done easily later. (But it is needed whenever you want to make it possible for the user to use the Update Manager, and it is for instance also required at Yoxos.) Hope that explaines a bit :-) Ciao, Leif |
|
From: Andrei de A. F. <arc...@ya...> - 2004-07-21 14:06:40
|
Hi, --- Leif Frenzel <hi...@le...> wrote: > Hi Andrei, > I would suggest that the general prefix for all > plugins from the project > should be net.sf.eclipsefp.*, which is in accord > with the usual Java / > Eclipse conventions. Oh, I forgot the sf part, but that's what I meant. > Yes, you are right about the common structure. This > follows also the > recommendations of Erich Gamma and Kent Beck in > their 'Contributing to > Eclipse', which is, btw, a good read for details on > Eclipse and Plugin > Development. Yes, I have access to this book, and I'm planning to read it soon. > > Hope that explaines a bit :-) > It was very helpful, thank you :) --- []s, Andrei de A. Formiga __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail |
|
From: Andrei de A. F. <arc...@ya...> - 2004-07-24 02:12:26
|
I started a very sketchy OCaml plugin, for now with a minimum of code. As I use different workstations in my development, it's very useful to have the modules in CVS. I will commit the modules I'm working on to the eclipsefp repository, is that ok ? --- []s, Andrei de A. Formiga __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail |
|
From: Leif F. <hi...@le...> - 2004-07-24 10:56:04
|
Andrei, of course, feel free to use the repository :-) I presume you would book the Eclipse projects into the CVS, so that we would have then in the repository directory a structure like net.sf.eclipsefp.ocaml net.sf.eclipsefp.ocaml-feature net.sf.eclipsefp.ocaml.ui etc. (whatever). When I start to maintain the Haskell plugins in the repository too, I would then create net.sf.eclipsefp.common.core ... net.sf.eclipsefp.haskell.ui net.sf.eclipsefp.haskell net.sf.eclipsefp.haskell-feature so we get no conflicts here. Ciao, Leif ----- Original Message ----- From: "Andrei de A. Formiga" <arc...@ya...> To: <ecl...@li...> Sent: Saturday, July 24, 2004 4:12 AM Subject: [eclipsefp-develop] ocaml and cvs > > I started a very sketchy OCaml plugin, for now with > a minimum of code. As I use different workstations in > my development, it's very useful to have the modules > in CVS. I will commit the modules I'm working on to > the eclipsefp repository, is that ok ? > > --- > []s, Andrei de A. Formiga > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail - 50x more storage than other providers! > http://promotions.yahoo.com/new_mail > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > eclipsefp-develop mailing list > ecl...@li... > https://lists.sourceforge.net/lists/listinfo/eclipsefp-develop > |
|
From: Andrei de A. F. <arc...@ya...> - 2004-07-24 14:31:34
|
--- Leif Frenzel <hi...@le...> wrote: > net.sf.eclipsefp.ocaml > net.sf.eclipsefp.ocaml-feature > net.sf.eclipsefp.ocaml.ui > > etc. (whatever). When I start to maintain the > Haskell plugins in the > repository too, I would then create > > net.sf.eclipsefp.common.core > ... > net.sf.eclipsefp.haskell.ui > net.sf.eclipsefp.haskell > net.sf.eclipsefp.haskell-feature > > so we get no conflicts here. > > Ciao, > Leif > Erm... two quick questions then: what's the module -feature ? And why do I need a IDocumentProvider to implement an editor ? The documentation is not clear on this... --- []s, Andrei de A. Formiga __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail |
|
From: Andrei de A. F. <arc...@ya...> - 2004-07-24 15:58:34
|
--- "Andrei de A. Formiga" <arc...@ya...> wrote: > And why do I need a IDocumentProvider to > implement an editor ? The documentation is not clear > on this... > About IDocumentProvider, nevermind, I found the docs. --- []s, Andrei Formiga __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail |
|
From: Leif F. <lfr...@in...> - 2004-07-24 20:31:10
|
> Erm... two quick questions then: what's the module > -feature ? That's for the feature. The convention is that the projects are named after the plugin id / feature id of the plugin/feature that is implemented in them. Because there are sometimes plugins and features with one and the same id, usually features are named <featureId>-feature. Features are needed for deploying sets of plugins via the Update Manager. They contain not much more than some license files and the feature.xml (manifest file for the feature). There were times when I created features by hand (and for the Yoxos distribution we have generated some using scripts, because not all plugin authors have provided features), but nowadays PDE has very good support for features and even Update sites :-) Ciao, Leif |
|
From: Andrei de A. F. <arc...@ya...> - 2004-07-25 14:05:58
|
I comitted the first modules for the OCaml plugin. For now, there's only an editor which does syntax highlighting of comments, strings and keywords. Pretty simple, but I spent hours to understand all the fuss about partitions, document providers, scanners, damagers and repairers etc. Speaking about multi-line comments, I submitted a bug report about nested comments. The same problem is occurring in the ocaml editor, and the solution could serve both plugins. I believe my next step will be implementing projects and possibly builders. --- []s, Andrei de A. Formiga __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail |
|
From: Andrei de A. F. <arc...@ya...> - 2004-07-25 16:51:11
|
Hi Leif, I'm about to implement the OCaml nature for projects, and I thought about using FPNature as a base class, which creates a dependency from the ocaml core plugin to the common core plugin. This is probably too early to think about it, but when it's time to distribute the OCaml feature, I guess I'll have to include the common plugins in the distribution, right ? And what if the user installs both the haskell and ocaml plugins (with different versions, maybe) ? --- []s, Andrei de A. Formiga __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail |
|
From: Leif F. <lfr...@in...> - 2004-07-25 22:31:42
|
Hi Andrei, > This is probably too early to think about it, but > when it's time to distribute the OCaml feature, I > guess I'll have to include the common plugins in the > distribution, right ? And what if the user installs > both the haskell and ocaml plugins (with different > versions, maybe) ? Yupp, the commons plugins are intended to be a collection of shared, language-neutral functionality, primarily to reduce code duplications. Well, a feature is nothing more than a grouping with some meta-info for the Update Manager, and a license file. In that meta-info (in a feature.xml file) is declared not only which plugins are contained in the feature, but also on which plugins (with which versions) they depend. Dependencies can be specified as 'exact match' (meaning all three version numbers in the major.minor.service scheme must be equal) or as one of a range of more relaxed dependencies (e.g. 'greater or equal'). So I think there should be no problem if we specify both the OCaml and the Haskell feature as containing the common.* plugins and declaring 'greater or equal' dependencies to them (I'm not entirely sure, but I think this is the default dependency rule anyway). If somebody downloads both, the Update Manager will in any case download and install the higher versions. It may install the older ones too, but then Eclipse will use the latest versions when starting up. We have to make sure, of course, that there is strict backwards-compatibility between all versions of the common.* plugins. But I think we can manage that. There is no problem in adding classes, but it may cause trouble to extend interfaces, or to remove or rename things. (There is a paper, by Jim des Revieres, I think, on the eclipse.org website, which discusses exactly what changes can break existing code and which won't. I'll have a look at it in the next days to find out whether I overlooked something.) If (in the future) the common.* plugins get larger, we should consider dividing them up into API classes and internal classes (which reside in their own packages with an 'internal' somewhere in their name), where API can be used from other plugins, whereas internal classes may not. This is the practice in the various Eclipse subprojects, and it works fine. With the new Eclipse runtime, it should be even possible to effectively block the use of internal packages (simply by not exporting them). Ciao, Leif > > --- > []s, Andrei de A. Formiga > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail - Helps protect you from nasty viruses. > http://promotions.yahoo.com/new_mail > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > eclipsefp-develop mailing list > ecl...@li... > https://lists.sourceforge.net/lists/listinfo/eclipsefp-develop |
|
From: Leif F. <hi...@le...> - 2004-07-25 22:26:31
|
> I comitted the first modules for the OCaml plugin. > For now, there's only an editor which does syntax > highlighting of comments, strings and keywords. Pretty > simple, but I spent hours to understand all the fuss > about partitions, document providers, scanners, > damagers and repairers etc. Yes, I know that feeling ;-) > Speaking about multi-line comments, I submitted a > bug report about nested comments. The same problem is > occurring in the ocaml editor, and the solution could > serve both plugins. Right. This is not a trivial problem, though. (Like the one noted by Marcus, that there is wrong coloring of strings that contain single-line comment characters, e.g. putStr "-- not really a comment"). It probably involves writing special rules for the comments, so that comment-start strings and comment-end strings can be sort of stacked. I classified it as not so critical, so I postponed it until later. It is good to have it in the tracker, but. Ciao, Leif |
|
From: Andrei de A. F. <arc...@ya...> - 2004-08-23 20:09:15
|
Hi Leif, I'm planning on making a first release of the OCaml plugins in the next few days. It's a bit crude yet, but has bare-bones support for editing, building and launching projects. In the spirit of 'release early, release often', I'll unleash it to the world and see what happens. So I need to release the package with sourceforge, but I don't have permission to do so. Either I send you the file and you make a release, or you give me permission and I'll do it. I am not thinking about packaging to the eclipse updater yet, unless it's really easy (I have no clue). It will be done in the next release, at most. --- []s, Andrei de A. Formiga _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush |
|
From: Leif F. <lfr...@in...> - 2004-08-23 22:42:27
|
Hi Andrei, > I'm planning on making a first release of the OCaml > plugins in the next few days. It's a bit crude yet, > but has bare-bones support for editing, building and > launching projects. In the spirit of 'release early, > release often', I'll unleash it to the world and see > what happens. Great :-) > So I need to release the package with sourceforge, > but I don't have permission to do so. Either I send > you the file and you make a release, or you give me > permission and I'll do it. Ahem, I'll look at that permission stuff, should be no problem to give you these, too. I think I can do it tomorrow during the day (need a better internet connection than right now). >I am not thinking about > packaging to the eclipse updater yet, unless it's > really easy (I have no clue). It will be done in the > next release, at most. I think you should really consider that, it is the only really supported way to get plugins installed (in Eclipse parlance, unzipping plugins is only 'tolerated', but not supported ...). (It is also a necessary prerequisite for Yoxos, by the way ;-) I think, making a feature and update site is about the easiest thing of them all, so it should really be done in no time at all. (The article at http://eclipse.org/articles/Article-Update/keeping-up-to-date.html covers all things needed; but you probably have already seen it, just in case :-) Packaging the sources may be a bit more tricky, but since you have them already in a public CVS, that may not even be needed. Ciao, Leif |
|
From: Andrei de A. F. <arc...@ya...> - 2004-08-23 22:57:48
|
--- Leif Frenzel <lfr...@in...> wrote: > > Ahem, I'll look at that permission stuff, should be > no problem to give you > these, too. I think I can do it tomorrow during the > day (need a better > internet connection than right now). Ok, cool :) > > I think you should really consider that, it is the > only really supported way > to get plugins installed (in Eclipse parlance, > unzipping plugins is only > 'tolerated', but not supported ...). (It is also a > necessary prerequisite > for Yoxos, by the way ;-) > [...] > I think, making a feature and update site is about > the easiest thing of them > all, Yes, I gave a look at it and it seemed simple. So I will do it for this release. > Packaging the sources may be a bit more tricky, but > since you have them > already in a public CVS, that may not even be > needed. Yes, packaging the sources was something I was still thinking about how to do... > > Ciao, > Leif --- []s, Andrei de A. Formiga __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail |
|
From: Andrei de A. F. <arc...@ya...> - 2004-08-24 00:05:45
|
Hi Leif, I'm running into trouble and can't seem to find a way out in the documentation. I have the ocaml, ocaml.core and ocaml.ui plugins. When I export the feature, there are compilation errors when building classes in the ocaml.ui plugin that depend on the ocaml.core plugin. I guess that it happens because I don't have the ocaml plugins installed in the plugins directory. When I build the plugins in the workspace, and test them, everything goes ok, the error only pops up when exporting the feature. Do you have any ideas about this ? Thanks in advance. --- []s, Andrei de A. Formiga --- Leif Frenzel <lfr...@in...> wrote: > I think, making a feature and update site is about > the easiest thing of them > all, so it should really be done in no time at all. > > Ciao, > Leif __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail |
|
From: Leif F. <hi...@le...> - 2004-08-24 08:29:11
|
> I'm running into trouble and can't seem to find a > way out in the documentation. I have the ocaml, > ocaml.core and ocaml.ui plugins. When I export the > feature, there are compilation errors when building > classes in the ocaml.ui plugin that depend on the > ocaml.core plugin. I guess that it happens because I > don't have the ocaml plugins installed in the plugins > directory. > > When I build the plugins in the workspace, and test > them, everything goes ok, the error only pops up when > exporting the feature. Ouch, yes, I had that problem, too. Cost me weeks, and I never figured out what happened. The problem disappeared when I switched to a fresh Eclipse 3.0 (final) installation. (I had been using the various milestones and RCs before.) On that occasion, I decided not to import my old preference settings and workspace, but just use a clean new installation, copied all project folders to a new directory, and imported them as 'existing projects'. After that everything went fine. My best guess as to what the problem is is this: the export build consists of a generated Ant build file for every project. (You can generate the build files if you right click the feature.xml and select PDE Tools > Create Ant Build File.) In these files, there seems to be a problem when defining the output folders of one plugin (e.g. core) to the classpath of another, that depends on it (e.g. ui). I had the suspicion, that it had to do with the path structure on my Windows machine, because I had all my project folders in a top-level folder (C:\eclipsefp). But I'm not sure about that. So it seems there is some bug in the PDE build facilities. I'll try to reproduce the problem with a toy project set and ask on eclipse.org. (I remember I made a bugzilla and newsgroup search there when I had the problem, but found nothing.) Ciao, Leif |
|
From: Andrei de A. F. <arc...@ya...> - 2004-08-24 12:58:44
|
--- Leif Frenzel <hi...@le...> wrote: > Ouch, yes, I had that problem, too. Cost me weeks, > and I never figured out > what happened. The problem disappeared when I > switched to a fresh Eclipse > 3.0 (final) installation. (I had been using the > various milestones and RCs > before.) On that occasion, I decided not to import > my old preference > settings and workspace, but just use a clean new > installation, copied all > project folders to a new directory, and imported > them as 'existing > projects'. After that everything went fine. I'm using 3.0 final running on a windows box and a linux box. Both show the problem. With the windows box I copied the project folders and imported them as existing projects; then, besides the ocaml.core errors, there appeared new ones related to dependencies on the common.core and common.ui (de.leiffrenzel) plugins. > > My best guess as to what the problem is is this: the > export build consists > of a generated Ant build file for every project. > (You can generate the build > files if you right click the feature.xml and select > PDE Tools > Create Ant > Build File.) Funny enough, I generated the build file and ran it manually as an ant build, and everything went fine. It didn't package the feature, though, but built jars of all the plugins and the feature, dropping them at their respective projects' directory. > I had the suspicion, that > it had to do with the > path structure on my Windows machine, because I had > all my project folders > in a top-level folder (C:\eclipsefp). But I'm not > sure about that. On my windows box I have most projects under the workspace directory, and the ocaml, ocaml.core and ocaml.ui plugins in a separate top-level directory. On the linux box everything is in the workspace. > > Ciao, > Leif > --- []s, Andrei de A. Formiga __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail |
|
From: Andrei de A. F. <arc...@ya...> - 2004-09-01 19:16:18
|
Hi Leif, I can add new releases, but I still can't create new packages in the file release system. I wouldn't be good to add a release of the ocaml plugins in the already existing eclipsefp package that holds the haskell plugin releases, so I need a separate package. I have everything ready, this is the only thing pending. --- []s, Andrei de A. Formiga _______________________________ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com |
|
From: Leif F. <hi...@le...> - 2004-09-02 17:37:59
|
Hi Andrei, Sorry again. I can't see why that shouldn't be possible (I can't find where I would have to give you these rights on the sf page). Maybe I miss something (but as I am on the road again and have not much time and bandwidth, I can't at the moment browse through the site and read their docs ...). I just created an OCaml release package. I will see whether I can just rename the old one to Haskell, if not, I create one for Haskell and use that from now on. I also updated the project description, but there will be more texts probably out of date (and the website will also need an overhaul ;-). Ciao, Leif ----- Original Message ----- From: "Andrei de A. Formiga" <arc...@ya...> To: <ecl...@li...> Sent: Wednesday, September 01, 2004 9:16 PM Subject: [eclipsefp-develop] File releases > > Hi Leif, > > I can add new releases, but I still can't create > new packages in the file release system. I wouldn't be > good to add a release of the ocaml plugins in the > already existing eclipsefp package that holds the > haskell plugin releases, so I need a separate package. > I have everything ready, this is the only thing > pending. > > --- > []s, Andrei de A. Formiga > > > > > _______________________________ > Do you Yahoo!? > Express yourself with Y! Messenger! Free. Download now. > http://messenger.yahoo.com > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > _______________________________________________ > eclipsefp-develop mailing list > ecl...@li... > https://lists.sourceforge.net/lists/listinfo/eclipsefp-develop > |
|
From: Andrei de A. F. <arc...@ya...> - 2004-09-02 17:58:17
|
--- Leif Frenzel <hi...@le...> wrote: > Hi Andrei, > > Sorry again. I can't see why that shouldn't be > possible (I can't find where > I would have to give you these rights on the sf > page). Maybe I miss > something (but as I am on the road again and have > not much time and > bandwidth, I can't at the moment browse through the > site and read their docs > ...). Yes, I couldn't see why either. This sourceforge permission system is strange. > > I just created an OCaml release package. I will see > whether I can just > rename the old one to Haskell, if not, I create one > for Haskell and use that > from now on. I also updated the project description, > but there will be more > texts probably out of date (and the website will > also need an overhaul ;-). I created a page for the OCaml plugins in http://eclipsefp.sourceforge.net/ocaml And put the update site there as well. Later we can see what will change in both. > > Ciao, > Leif > --- []s, Andrei Formiga __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail |
Thanks for helping keep SourceForge clean.
X