JBossDeveloper

I downloaded and installed a command line CVS client, that IS needed (I thought the error was because of firewall issues). Besides that, the checkout.jbpm.repository is configured to have CVS commit rights. I think it should be changed to anoncvs. Otherwise a commandline SSH is also needed.

One thing I observe again is the need to have a JAVA_HOME set for some tasks, when building from eclipse (3.2), which COULD point to a different JVM. Is this wanted behaviour? I think not. Another thing is that there is an unknown target all.doc in the userguid build.xml

I Will set JAVA_HOME again and see what the result is

hmmm.... why do I need a command line ZIP tool as well? Doesn't ant all provide this??? (unzipping seems to work for the eclipse stuff ). So zip, ssh, and cvs are all needed on the commandline?

You don't need 'a' zip tool on the command line or 'a' cvs client, but the exact same zip tool and cvs client as specified by the Eclipse PDE build guidelines. So I think we should collectively booh the Eclipse PDE team on this one indeed...

Nevertheless, I have some good news that Tom will like a lot. I have worked my way around the requirement to checkout the plugin and feature projects during the Eclipse build. If you checkout the entire jbpm.3 tree and invoke the build.xml in the build project, no cvs checkout will happen during the GPD build. So it becomes faster and faster. What currently takes most of the time is the Eclipse installation. I will see what I can do to work around this too so that it only happens when the Eclipse configuration has changed.

Regards,
Koen

About the good news, I pointed the new eclipse.home to the eclipse instance I'm running in (so a kind of 'this'). When doing a full build, I get some exeptions about a data file in one of the eclipse plugin dirs. After that, this eclipse instances will not startup any more. The <eclipse.home>/configuration/config.ini is GONE. So one advise, do not do this in a running or needed eclipse instance.

taking a completely fresh install of eclipse 3.2 with gpd 3.0.11, gave me the following error when doing a fresh cvs checkout and build

run-eclipse-plugin-builder:
[java] java.lang.NoClassDefFoundError: org/eclipse/core/launcher/Main
[java] Exception in thread "main"
[java] Java Result: 1

The eclipse.home in the build.properties points to what is initially an empty dir. after the build there are 5 text files 0 bytes large with the following names

eclipse-SDK-3.2-win32.zip.txt
emf-sdo-xsd-SDK-2.2.0.zip.txt
GEF-SDK-3.2.zip.txt
JEM-SDK-1.2.zip.txt
wtp-sdk-R-1.5.0-200606281455.zip.txt

And did you do the get.dependencies? Are the Ecipse files in your local repository? Normally not only the text files should be there but also the unzipped content of all the Eclipse files...
The files are a way to explicitly keep track of the Eclipse/WTP/GEF/... configuration. If this configuration changes, the eclipse.home folder is erased and the fresh Eclipse configuration is installed. This allowed me yesterday to do a complete build of all the jBPM artifacts in less than 3 minutes. But maybe there is still a bug in it of course...
Anyone else seeing the same thing?

Regards,
Koen

By the way... I still have to document this stuff in a readme..

James,

Have a look at the build.properties file in the first level build project. More in particular there is a eclipse.home and jboss.home property that should point to the folder you want...

Regards,
Koen

We've now had success in building the eclipse plugin.

The biggest thing we needed to do is to make sure that inheritall is turned on where the designer/jpdl/org.jbpm.gd.jpdl.build/build.xml file passes properties to the gpd.userguide build,
and to modify designer/jpdl/org.jbpm.gd.jpdl.docs/gpd.userguide/build.xml so that it looks for the the docbook-support/support.xml file relative to ${local.repository}, rather than ${user.home}. This after pulling the docbook support pieces down, of course.

We also had to make sure that we specified the ${eclipse.home} property in build/build.properties so that it matches the name that the eclipse-SDK-3.2-win32.zip is exploded to (i.e., we had to use "eclipse" rather than "eclipse_build").

Now that we've got the
/designer/jpdl/org.jbpm.gd.jpdl.build/target/workspace/plugins/org.jbpm.gd.jpdl.ui/ui.jar file generated, what do we do with it?

One other thing we needed to do was to modify build/build.properties to define jbpm.3.location , which allows the jpdl/db artifact to build properly, even if we've integrated the jbpm-identity.jar and jbpm-jpdl.jar files into our local Ant installation (or into our CLASSPATH), so as to enable the eclipse plugin build to operate.

Can you post the modified files here in this thread. It might be interesting to commit those modifications to CVS so that others don't run into these very same issues...

Regards,
Koen

Koen,

Some other small things regarding the GPD build:
- add the target dir to cvs ignore
- add the target/output dir for the classes to the .project file explicitly on the designer source tree and have it point to the same dir as in the ant file (that prevents the javac issue I posted before, which happend on the new ws dir I added locally as well until I added an explicit target/output dir.

There should in fact not be a .project file on the level of the designer or designer/jpdl source tree. This cvs folder should IMO never be an Eclipse project.
Adding the target dir to .cvsignore is fine. Go ahead and do it! ;-)

Cheers,
Koen