For a little while the buildserver also produces plugin files for
Eclipse that will provide Compose*/Java.
The plugins should support both Eclipse 3.2 and 3.3 (current stable
release).
If you've previously installed (through the build scripts) any part of
the eclipse plugins (either Java or C) you should make sure you clean
your plugin directory and remove all traces from the old
plugins. Otherwise you'll get duplicate menu items and probably other
errors.
The current plugin directories will have the following names:
The CORE:
eclipse/plugins/composestar.core_<version>
Java stuff:
eclipse/plugins/composestar.java_<version>
Where <version> is the latest version number (currently 0.6.3). All
other composestar related directories should be deleted.
After deleting the old directories you might want to start eclipse with
`-clean` to refresh the plugin cache.
Compose*/Java for Eclipse can be installed in 3 ways.
Automatic:
Through the eclipse updating/install system:
In eclipse: Help -> Software Updates -> Find and Install ...
"Search for new features to install"
Add a new remote site with the following details:
name: Compose*
url: http://composestar.sourceforge.net/eclipse/
Press "finish" and select Compose*/Java from the list.
This site is also used for updates.
Manually:
Download the composestar.java_<version>.zip file and extract
the contents in the eclipse directory.
Developer:
Execute the build script with the `install` target.
The eclipse update site needs to be manually updated with the files of a
new release. Eclipse does not overwrite previously installed versions,
so developers will always need to use either the manual or developer
install methods to install the latest builds.
Furthermore there have been some important changes to the eclipse plugin
that require manual actions for current projects (the Java examples have
already been updated).
1) The Compose*/Java runtime libraries will no longer be added as
individual entries (with fixed paths). Instead a library container is
used who's entries will be dynamically resolved. New projects will
automatically get this container.
To update older projects you have to remove the current compose* runtime
libraries from the build path and "Add Library" to add the
"Compose*/Java Runtime Library"
2) It's no longer required to include all C*/Java jars in the classpath
configuration entry of the project. In fact, it's better that you
don't. The classpath will be automatically resolved.
3) The standard eclipse "run" dialog can be used to start Compose*/Java
projects. Start them as a Java Application. There is however a caveat,
this is the result of the "Java Builder" (see below) and added
signatures. The Java Builder will produce broken class files of this and
add an error annotation. This annotation isn't cleared when Compose*
builds the project. Thus eclipse will warn the user about a broken
program. you can ignore this warning when you ran the Compose*
compiler. Alternatively you can use the "run" command from the Compose*
menu item in the project's context menu.
4) Commandline compiler. Because the ever changing location of various
required jar files it can be troublesome to execute the Compose*/Java
without the use of the eclipse plugin. For this reason I added a magic
jar file file called "compiler.jar" to the
plugins/composestar.java_<version> directory. This will allow you to
easily call the compiler:
java -jar <eclipse>/plugins/composestar.java_<version>/compiler
BuildConfiguration.xml
However, there are still some items that need to be fixed/improved.
1) Java Builder. The default Java Builder produces various problemes
with Compose*/Java, specially when automatic building is enabled in
eclipse. This builder is required for various functionality, it should
just not be executed. This builder should be deactivated for all
projects (including newly created projects): Project context menu ->
properties -> builders. Uncheck the box for Java Builder.
The Java Builder will, by default, copy almost all files in the project
to the output directory. This includes the intermediate files, which
will cause problems for the execution. Additionally, this builder will
try to build the java code when it's updated. These updated files can
conflict with the compose* output. So it's best to simply disable this
builder.
2) Runtime libraries. Right now a large part of the compiletime is
needed to run the Compose*/Java programs. This is because the repository
contains elements to various classes from the Compiletime but it also
references some classes from the prolog engine. The runtime repository
contains a lot of information that it absolutely not needed for the
runtime (like the FIRE and SECRET results). This is caused by the fact
that the Java repository serializer uses the standard Java
serialization, just like what it done for INCRE to support incremental
compilation. There are two possible sollutions to fix this problem:
- custom serialization (just like .NET 1.1 has)
- deep copy of the repository that is cleaned up
But this is a non-issue when the runtime is dropped for Java in favor of
inlining.
3) The compose* menu's are always available, even though the project is
not a compose* project. Of course any Java project can be compiled as
compose* project (when the runtme libraries are added). But
C/... projects can not be "converted".
4) Compose* project settings not stored in the .settings directory. This
is not very clean/nice/whatever. But probably trivial to fix, but I'm
currently writing this email and not fixing that issue.
As a final note. I do not know how stable the compiletime and runtime
are, but the system test appear to be working. Of course that doesn't
have to be a good sign, but I assume the tests are correct.
It could happen that the examples do not compile/run after a checkout of
the current Compose*/Java. This is mostlikely due to some of the issues
explained in this email. You need to manually clean all intermediate
files in the example dirs. It's probably best to simply delete the
Java/Examples dir and check out a fresh copy.
PS, it's adviced to disable the Compose*/C port if you're not "using"
it. I haven't adjusted it's eclipse plugins and scripts. It will still
copy the C core to the core plugin directory. This shouldn't be a major
problem, unless somebody decides to continue Johan's work.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Composestar-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/composestar-developers
