Eclipse Community Forums: Buckminster » Problem building plugins with special builders

Help

Home

Home » Archived » Buckminster » Problem building plugins with special builders

Show: Today's Messages :: Show Polls :: Message Navigator

Problem building plugins with special builders [message #383051]

Tue, 17 February 2009 14:17

John

Messages: 107
Registered: July 2009

Senior Member

Hi!

We have some plugins that are used for calling webservices.
The structure in CVS is fairly similar for all of them.
Here's an example from a specific one that's failing:

my.company.cd.core.webservice.auditinglog
-.settings
-META-INF
-wsdl-src
--wsdl
---AuditingLog_v1.wsdl
-.project

When the project is checked out to a workspace and built, the structure is:

my.company.cd.core.webservice.auditinglog
-.settings
-bin
-META-INF
-src
-wsdl-src
--wsdl
---AuditingLog_v1.wsdl
-xmlbeans_bin
-.classpath
-.project
-build.properties

So there is no source checked in except for the wsdl file.
src above contains the generated java files and bin contains the class
files.

When I run the build of our product from my local workspace, everything
works fine.
When I run the build of our product from cvs, it appear that the
webservice projects aren't built.
The jar file in Buckminster build directory has the same contents as
listed above for CVS.
There are no class files.

In the debug log the Actions to perform (in order) has de following for
the project:

my.company.cd.core.webservice.auditinglog:osgi.bundle$1.0.0# OSGi#target.fragments

my.company.cd.core.webservice.auditinglog:osgi.bundle$1.0.0# OSGi#bundle.jar

so Buckminster doesn't want to perform an eclipse.build.

Why is that?

Looking in an previous debug log from a build made against the workspace I
see:

my.company.cd.core.webservice.auditinglog:osgi.bundle$1.0.0# OSGi#eclipse.build

my.company.cd.core.webservice.auditinglog:osgi.bundle$1.0.0# OSGi#target.fragments

my.company.cd.core.webservice.auditinglog:osgi.bundle$1.0.0# OSGi#bundle.jar

So here an eclipse.build is performed first.

the .project file contains:

<projectDescription>
<name>my.company.cd.core.webservice.auditinglog</name>
<comment></comment>
<projects>
</projects>
<buildSpec>
<buildCommand>
<name>org.eclipse.jdt.core.javabuilder</name>
<arguments>
</arguments>
</buildCommand>
<buildCommand>
<name>my.company.cd.dev.plugin.stubbuilder.builder</name>
<arguments>
</arguments>
</buildCommand>
<buildCommand>
<name>org.eclipse.pde.ManifestBuilder</name>
<arguments>
</arguments>
</buildCommand>
<buildCommand>
<name>org.eclipse.pde.SchemaBuilder</name>
<arguments>
</arguments>
</buildCommand>
</buildSpec>
<natures>
<nature>my.company.cd.dev.plugin.stubbuilder.nature</nature >
<nature>org.eclipse.pde.PluginNature</nature>
<nature>org.eclipse.jdt.core.javanature</nature>
</natures>
</projectDescription>

Any suggestions?

Thanks.

/John.

Report message to a moderator

Re: Problem building plugins with special builders [message #383052 is a reply to message #383051]

Tue, 17 February 2009 15:11

Achim Demelt

Messages: 160
Registered: July 2009

Senior Member

John,

your custom builder (my.company.cd.dev.plugin.stubbuilder.builder) must be
installed in your Buckminster build host. You can use "buckminster install
<yourSite> <yourBuilderFeature>", in the same way you installed
Buckminster's PDE and CVS features.

If the builder is not present in your host, it cannot be executed. This is
very similar to your IDE: Try uninstalling your builder from Eclipse and
then build your project---it won't do.

I'm not sure about this, but I think you should see some warning messages in
the Eclipse log saying that the builder or nature cannot be found.

Achim

John wrote:

> Hi!
>
>
> We have some plugins that are used for calling webservices.
> The structure in CVS is fairly similar for all of them.
> Here's an example from a specific one that's failing:
>
> my.company.cd.core.webservice.auditinglog
> -.settings
> -META-INF
> -wsdl-src
> --wsdl
> ---AuditingLog_v1.wsdl
> -.project
>
> When the project is checked out to a workspace and built, the structure
> is:
>
> my.company.cd.core.webservice.auditinglog
> -.settings
> -bin
> -META-INF
> -src
> -wsdl-src
> --wsdl
> ---AuditingLog_v1.wsdl
> -xmlbeans_bin
> -.classpath
> -.project
> -build.properties
>
> So there is no source checked in except for the wsdl file.
> src above contains the generated java files and bin contains the class
> files.
>
> When I run the build of our product from my local workspace, everything
> works fine.
> When I run the build of our product from cvs, it appear that the
> webservice projects aren't built.
> The jar file in Buckminster build directory has the same contents as
> listed above for CVS.
> There are no class files.
>
> In the debug log the Actions to perform (in order) has de following for
> the project:
>
>
>
my.company.cd.core.webservice.auditinglog:osgi.bundle$1.0.0# OSGi#target.fragments
>
>
my.company.cd.core.webservice.auditinglog:osgi.bundle$1.0.0# OSGi#bundle.jar
>
> so Buckminster doesn't want to perform an eclipse.build.
>
> Why is that?
>
> Looking in an previous debug log from a build made against the workspace I
> see:
>
>
>
my.company.cd.core.webservice.auditinglog:osgi.bundle$1.0.0# OSGi#eclipse.build
>
>
my.company.cd.core.webservice.auditinglog:osgi.bundle$1.0.0# OSGi#target.fragments
>
>
my.company.cd.core.webservice.auditinglog:osgi.bundle$1.0.0# OSGi#bundle.jar
>
> So here an eclipse.build is performed first.
>
>
> the .project file contains:
>
> <projectDescription>
> <name>my.company.cd.core.webservice.auditinglog</name>
> <comment></comment>
> <projects>
> </projects>
> <buildSpec>
> <buildCommand>
> <name>org.eclipse.jdt.core.javabuilder</name>
> <arguments>
> </arguments>
> </buildCommand>
> <buildCommand>
> <name>my.company.cd.dev.plugin.stubbuilder.builder</name>
> <arguments>
> </arguments>
> </buildCommand>
> <buildCommand>
> <name>org.eclipse.pde.ManifestBuilder</name>
> <arguments>
> </arguments>
> </buildCommand>
> <buildCommand>
> <name>org.eclipse.pde.SchemaBuilder</name>
> <arguments>
> </arguments>
> </buildCommand>
> </buildSpec>
> <natures>
> <nature>my.company.cd.dev.plugin.stubbuilder.nature</nature >
> <nature>org.eclipse.pde.PluginNature</nature>
> <nature>org.eclipse.jdt.core.javanature</nature>
> </natures>
> </projectDescription>
>
> Any suggestions?
>
> Thanks.
>
>
> /John.

Report message to a moderator

Re: Problem building plugins with special builders [message #383053 is a reply to message #383052]

Tue, 17 February 2009 20:31

John

Messages: 107
Registered: July 2009

Senior Member

Hi Achim!

Thanks for the response. I was wondering if this builder would give me a
problem and how it would appear. The surprise is that so far I haven't
been warned at all.
I think it makes sense that I should do as you describe, so I will try
that back at work tomorrow.

However, it doesn't really explain what I've experienced so far.
When resolving from CVS I don't get any error of the missing builder. I
think the explanation is that Buckminster decides not to call
eclipse.build. The question is why it doesn't do that.

When resolving from my local workspace I have the headless Buckminster
with the plugins, a separate workspace to materialize to, a separate RCP
used as target and then the local workspace, from where I pull my project
as specified in my rmap. So there's no where to pull the builder plugin
from, but Buckminster decides to call eclipse.build, I don't get an error,
and the build product works perfectly.

I will try some more experiments tomorrow.

Thanks again.

/John.

Report message to a moderator

Re: Problem building plugins with special builders [message #383056 is a reply to message #383053]

Thu, 19 February 2009 11:32

John

Messages: 107
Registered: July 2009

Senior Member

Hi!

I have now tried a couple of experiments and still have a problem with
building our webservice projects, that have a custom made builder.

As described earlier the source structure in CVS is:

my.company.cd.core.webservice.auditinglog
-.settings
-META-INF
--MANIFEST.MF
-wsdl-src
--wsdl
---AuditingLog_v1.wsdl
-.project

The .project file contains:
<projectDescription>
<name>my.company.cd.core.webservice.auditinglog</name>
<comment></comment>
<projects>
</projects>
<buildSpec>
<buildCommand>
<name>org.eclipse.jdt.core.javabuilder</name>
<arguments>
</arguments>
</buildCommand>
<buildCommand>
<name>my.company.cd.dev.plugin.stubbuilder.builder</name>
<arguments>
</arguments>
</buildCommand>
<buildCommand>
<name>org.eclipse.pde.ManifestBuilder</name>
<arguments>
</arguments>
</buildCommand>
<buildCommand>
<name>org.eclipse.pde.SchemaBuilder</name>
<arguments>
</arguments>
</buildCommand>
</buildSpec>
<natures>
<nature>my.company.cd.dev.plugin.stubbuilder.nature</nature >
<nature>org.eclipse.pde.PluginNature</nature>
<nature>org.eclipse.jdt.core.javanature</nature>
</natures>
</projectDescription>

As you can see it uses our own nature and builder.

The MANIFEST.MF contains:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: auditinglog plug-in
Bundle-SymbolicName: my.company.cd.core.webservice.auditinglog
Bundle-Version: 1.0.0
Bundle-Vendor: Auto genererated by MyCompany Eclipse Plugin
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Require-Bundle: my.company.cd.core.axis2.runtime
Export-Package: my.company.cd.core.webservice.auditinglog.gendata.impl,
my.company.cd.core.webservice.auditinglog.gendata,
my.company.cd.core.webservice.auditinglog
Bundle-ClassPath: xmlbeans_bin/,
.

As you can see it mentions the generated packages in Export-Package.
This is from a previous build and the file has been checked into CVS after.
All other generated files are marked derived and are not checked into CVS.

My setup is as follows:

E1 - I have an Eclipse 3.4 installation with all necessary features and
plugins installed.

W1 - I have a workspace which was opened with E1. Source has been checked
out from CVS and built with Eclipse.

B1 - I have a Buckminster installation version 1.1.340.r09908 with the
following features:
org.eclipse.buckminster.core.headless.feature_1.1.340.r09917
org.eclipse.buckminster.cvs.headless.feature_1.0.0.r09908
org.eclipse.buckminster.maven.feature_1.1.0.r09904
org.eclipse.buckminster.pde.headless.feature_1.1.340.r09913
org.eclipse.buckminster.product_1.1.340.r09908

B2 - This is similar to B1, but has also our feaure
my.company.cd.dev.plugin.feature_1.1.3, which includes the nature and
builder mentioned in .project above.

W2 - A workspace opened with E1. Source has been checked out from CVS but
NOT built with Eclipse. So the structure is similar to what's in CVS.

W3 - A empty workspace that is used to materialize into using headless
Buckminster by specifying the -data option.
RCP - Another Eclipse 3.4 with the target RCP.
The RCP and a new W3 has been used in all scenarios.

Using this I have tried the following Buckminster headless build scenarios:
S1 - B1, W1 referenced from rmap.
This one works and is used for comparison.

S2 - B1, CVS referenced from rmap (product taken from W1 since it doesn't
work taking it from CVS).
This is the scenario we want to use, of course with the product also
taken from CVS.

S3 - B1, W2 referenced from rmap.'
This one is done to see if the problem is with Buckminster against
CVS.

S4 - B2, W2 referenced from rmap.
This one is done to see if the missing builder in the Buckminster
install is causing the problem.

S1 works fine. The build completes and the product can be run without
errors.

S2-S4 don't work. The build stops with the error:

"The project cannot be built until its prerequisite
my.company.cd.core.webservice.auditinglog is built. Cleaning and building
all projects is recommended"

In S1 our builder has been in action and has generated the sources and
created files like:

classpath:

<classpath>
<classpathentry kind="src" path="src"/>
<classpathentry kind="con"
path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
<classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"/>
<classpathentry kind="output" path="bin"/>
</classpath>

build.properties

source.. = src/
output.. = bin/
bin.includes = META-INF/,\
xmlbeans_bin/,\
.

As you can see the the project now has source folders, since the source
has been generated.

From the debug log we can see that Buckminster decides to perform the
following actions:

my.company.cd.core.webservice.auditinglog:osgi.bundle$1.0.0# OSGi#eclipse.build

my.company.cd.core.webservice.auditinglog:osgi.bundle$1.0.0# OSGi#target.fragments

my.company.cd.core.webservice.auditinglog:osgi.bundle$1.0.0# OSGi#bundle.jar

In S2-S4 Buckminster decides only to perform the following actions:

my.company.cd.core.webservice.auditinglog:osgi.bundle$1.0.0# OSGi#target.fragments

my.company.cd.core.webservice.auditinglog:osgi.bundle$1.0.0# OSGi#bundle.jar

I suppose the main difference is that in this case .classpath and
build.properties aren't available?
Are there any other files that could influence this decision?

The only other difference in the debug logs is the information logged when
performing bundle.jar.

In S1 it reads:
Action
my.company.cd.core.webservice.auditinglog:osgi.bundle$1.0.0# OSGi#bundle.jar
using 'up to date' policy COUNT: Rebuild needed: File count(0) <
expected(1)

In S2-S4 it reads:
Action
my.company.cd.core.webservice.auditinglog:osgi.bundle$1.0.0# OSGi#bundle.jar
using 'up to date' policy DEFAULT: Rebuild needed: Product has folders

OK, so I decided to introduce some of the generated files into
my.company.cd.core.webservice.auditinglog in W2 and to run S4.
I found out that just adding the previously generated build.properties
actually makes Buckminster decide to perform an eclipse.build!

my.company.cd.core.webservice.auditinglog:osgi.bundle$1.0.0# OSGi#eclipse.build

my.company.cd.core.webservice.auditinglog:osgi.bundle$1.0.0# OSGi#target.fragments

my.company.cd.core.webservice.auditinglog:osgi.bundle$1.0.0# OSGi#bundle.jar

Does this mean that we must have build.properties checked into CVS even if
we actually generate it?

There's not any interesting debug information around the execution of
eclipse.build.
It appear to be running successfully, but unfortunately there is no output
from our builder.
I guess this means it doesn't run.

Acccording to "Buckminster component meta-data language 1.0 (Reference)"
it reads: "eclipse.build - requests a full build from the Eclipse build
system ".
I assume this mens doing the same as a build from inside Eclipse? This
means invoking all the builders listed in .project, right?
So, should everything then be OK here and if so, why is our builder not
run?
Do I still miss something?

As I was experimenting with the contents of .project (like changing the
orders of builders or removing them) I accidently had just the line below
commented out.



This gave the following error, which shows that the Eclipse build system
is really called:

!ENTRY org.eclipse.jdt.core 4 4 2009-02-19 12:15:27.026
!MESSAGE JavaBuilder handling CoreException while building:
my.company.cd.core.webservice.auditinglog
!STACK 1
Java Model Exception: Java Model Status
[my.company.cd.core.webservice.auditinglog does not exist]
at
org.eclipse.jdt.internal.core.JavaElement.newNotPresentExcep tion(JavaElement.java:491)
at
org.eclipse.jdt.internal.core.JavaModelManager.getPerProject InfoCheckExistence(JavaModelManager.java:1941)
at
org.eclipse.jdt.internal.core.JavaProject.getPerProjectInfo( JavaProject.java:1756)
at
org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspa th(JavaProject.java:1826)
at
org.eclipse.jdt.internal.core.JavaProject.computeExpandedCla sspath(JavaProject.java:420)
at
org.eclipse.jdt.internal.core.JavaProject.getExpandedClasspa th(JavaProject.java:1421)
at
org.eclipse.jdt.internal.core.builder.NameEnvironment.comput eClasspathLocations(NameEnvironment.java:93)
at
org.eclipse.jdt.internal.core.builder.NameEnvironment.<init >(NameEnvironment.java:41)
at
org.eclipse.jdt.internal.core.builder.JavaBuilder.initialize Builder(JavaBuilder.java:596)
at
org.eclipse.jdt.internal.core.builder.JavaBuilder.build(Java Builder.java:167)
at
org.eclipse.core.internal.events.BuildManager$2.run(BuildMan ager.java:633)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:170)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:201)
at
org.eclipse.core.internal.events.BuildManager$1.run(BuildMan ager.java:253)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:256)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:218)
at
org.eclipse.core.internal.events.BuildManager.build(BuildMan ager.java:360)
at
org.eclipse.core.internal.resources.Project.internalBuild(Pr oject.java:516)
at org.eclipse.core.internal.resources.Project.build(Project.ja va:94)
at
org.eclipse.buckminster.core.internal.actor.AbstractBuildInt egrationActor.internalPerform(AbstractBuildIntegrationActor. java:46)
at
org.eclipse.buckminster.core.actor.AbstractActor.perform(Abs tractActor.java:136)
at
org.eclipse.buckminster.core.internal.actor.PerformManager.p erform(PerformManager.java:299)
at
org.eclipse.buckminster.core.internal.actor.PerformManager.p erform(PerformManager.java:343)
at
org.eclipse.buckminster.core.commands.Perform.internalRun(Pe rform.java:198)
at
org.eclipse.buckminster.core.commands.WorkspaceCommand.run(W orkspaceCommand.java:99)
at
org.eclipse.buckminster.cmdline.AbstractCommand.basicRun(Abs tractCommand.java:52)
at org.eclipse.buckminster.cmdline.Headless.run(Headless.java:2 95)
at org.eclipse.buckminster.cmdline.Headless.run(Headless.java:2 29)
at org.eclipse.buckminster.cmdline.Headless.start(Headless.java :304)
at
org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:193)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:110)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:79)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:386)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 549)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
at org.eclipse.equinox.launcher.Main.run(Main.java:1236)
at org.eclipse.equinox.launcher.Main.main(Main.java:1212)
!SUBENTRY 1 org.eclipse.jdt.core 4 969 2009-02-19 12:15:27.026
!MESSAGE my.company.cd.core.webservice.auditinglog does not exist

Since my S1 scenario works I guess this means that the eclipse.build
action works.
Since S2-S4 don't work, does this mean that eclipse.build doesn't execute
all the builders from .project?
Should I then do something else to get our builder called?
Must I e.g. create CSPECX's for all the projects with this builder?
If so, what should I write in them?

I would very much appreciate any help. I'm kind of stuck here.

Thanks.

/John.

Report message to a moderator

Re: Problem building plugins with special builders [message #383057 is a reply to message #383056]

Thu, 19 February 2009 14:14

Achim Demelt

Messages: 160
Registered: July 2009

Senior Member

John,

Thanks for your detailed investigation. First of all, you're right about
Buckminster not building the project if the build.properties file is not
present. I didn't know about this, either, but I dug it up in the code and
confirm your observation. Buckminster makes use of PDE's IBuildModel, which
cannot be created if there is no build.properties file. Buckminster then
assumes your project to be a binary bundle and does not build it from
source.

As for your scenarios:

* S1 works because Buckminster find build.properties and thus performs a
build. Your builder won't be executed, but it doesn't matter since the
projects in the workspace still contain the files that were generated when
you built the workspace in your IDE. So everything can be compiled and
packaged.
* S2 and S3 will never work since they're using B1, which doesn't have your
builder feature installed.
* S4 _should_ work if the build.properties file is present. You should make
sure that your builder comes before the JDT builder in the .project file. I
have experienced strange results in the past if the order isn't right here.

*If* Buckminster runs the eclipse.build Action, things are out of
Buckminster's hands and the Eclipse workspace build is in charge. I then see
only two reasons why your build output is not as you would expect it to be:

1. Installation problem: Your builder cannot run since its bundle could not
be started due to unresolved dependencies. We used to have this problem when
our builder code had some rogue dependencies to JFace or SWT. You should see
some output in the Eclipse log in this case.
2. Coding problem: Your builder _is_ invoked, but for some reason it decides
not to do anything. It may run into an exception which gets swallowed or
logged in the wrong place.

I hope my analysis helps you narrow your investigation. Maybe Thomas has
some additional insights?

Achim

John wrote:

> Hi!
>
>
> I have now tried a couple of experiments and still have a problem with
> building our webservice projects, that have a custom made builder.
>
> As described earlier the source structure in CVS is:
>
> my.company.cd.core.webservice.auditinglog
> -.settings
> -META-INF
> --MANIFEST.MF
> -wsdl-src
> --wsdl
> ---AuditingLog_v1.wsdl
> -.project
>
> The .project file contains:
> <projectDescription>
> <name>my.company.cd.core.webservice.auditinglog</name>
> <comment></comment>
> <projects>
> </projects>
> <buildSpec>
> <buildCommand>
> <name>org.eclipse.jdt.core.javabuilder</name>
> <arguments>
> </arguments>
> </buildCommand>
> <buildCommand>
> <name>my.company.cd.dev.plugin.stubbuilder.builder</name>
> <arguments>
> </arguments>
> </buildCommand>
> <buildCommand>
> <name>org.eclipse.pde.ManifestBuilder</name>
> <arguments>
> </arguments>
> </buildCommand>
> <buildCommand>
> <name>org.eclipse.pde.SchemaBuilder</name>
> <arguments>
> </arguments>
> </buildCommand>
> </buildSpec>
> <natures>
> <nature>my.company.cd.dev.plugin.stubbuilder.nature</nature >
> <nature>org.eclipse.pde.PluginNature</nature>
> <nature>org.eclipse.jdt.core.javanature</nature>
> </natures>
> </projectDescription>
>
> As you can see it uses our own nature and builder.
>
> The MANIFEST.MF contains:
> Manifest-Version: 1.0
> Bundle-ManifestVersion: 2
> Bundle-Name: auditinglog plug-in
> Bundle-SymbolicName: my.company.cd.core.webservice.auditinglog
> Bundle-Version: 1.0.0
> Bundle-Vendor: Auto genererated by MyCompany Eclipse Plugin
> Bundle-RequiredExecutionEnvironment: JavaSE-1.6
> Require-Bundle: my.company.cd.core.axis2.runtime
> Export-Package: my.company.cd.core.webservice.auditinglog.gendata.impl,
> my.company.cd.core.webservice.auditinglog.gendata,
> my.company.cd.core.webservice.auditinglog
> Bundle-ClassPath: xmlbeans_bin/,
> .
>
> As you can see it mentions the generated packages in Export-Package.
> This is from a previous build and the file has been checked into CVS
> after. All other generated files are marked derived and are not checked
> into CVS.
>
> My setup is as follows:
>
> E1 - I have an Eclipse 3.4 installation with all necessary features and
> plugins installed.
>
> W1 - I have a workspace which was opened with E1. Source has been checked
> out from CVS and built with Eclipse.
>
> B1 - I have a Buckminster installation version 1.1.340.r09908 with the
> following features:
> org.eclipse.buckminster.core.headless.feature_1.1.340.r09917
> org.eclipse.buckminster.cvs.headless.feature_1.0.0.r09908
> org.eclipse.buckminster.maven.feature_1.1.0.r09904
> org.eclipse.buckminster.pde.headless.feature_1.1.340.r09913
> org.eclipse.buckminster.product_1.1.340.r09908
>
> B2 - This is similar to B1, but has also our feaure
> my.company.cd.dev.plugin.feature_1.1.3, which includes the nature and
> builder mentioned in .project above.
>
> W2 - A workspace opened with E1. Source has been checked out from CVS but
> NOT built with Eclipse. So the structure is similar to what's in CVS.
>
> W3 - A empty workspace that is used to materialize into using headless
> Buckminster by specifying the -data option.
> RCP - Another Eclipse 3.4 with the target RCP.
> The RCP and a new W3 has been used in all scenarios.
>
> Using this I have tried the following Buckminster headless build
> scenarios: S1 - B1, W1 referenced from rmap.
> This one works and is used for comparison.
>
> S2 - B1, CVS referenced from rmap (product taken from W1 since it doesn't
> work taking it from CVS).
> This is the scenario we want to use, of course with the product also
> taken from CVS.
>
> S3 - B1, W2 referenced from rmap.'
> This one is done to see if the problem is with Buckminster against
> CVS.
>
> S4 - B2, W2 referenced from rmap.
> This one is done to see if the missing builder in the Buckminster
> install is causing the problem.
>
> S1 works fine. The build completes and the product can be run without
> errors.
>
> S2-S4 don't work. The build stops with the error:
>
> "The project cannot be built until its prerequisite
> my.company.cd.core.webservice.auditinglog is built. Cleaning and building
> all projects is recommended"
>
> In S1 our builder has been in action and has generated the sources and
> created files like:
>
> classpath:
>
> <classpath>
> <classpathentry kind="src" path="src"/>
> <classpathentry kind="con"
> path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
> <classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"/>
> <classpathentry kind="output" path="bin"/>
> </classpath>
>
>
> build.properties
>
> source.. = src/
> output.. = bin/
> bin.includes = META-INF/,\
> xmlbeans_bin/,\
> .
>
> As you can see the the project now has source folders, since the source
> has been generated.
>
> From the debug log we can see that Buckminster decides to perform the
> following actions:
>
>
>
my.company.cd.core.webservice.auditinglog:osgi.bundle$1.0.0# OSGi#eclipse.build
>
>
my.company.cd.core.webservice.auditinglog:osgi.bundle$1.0.0# OSGi#target.fragments
>
>
my.company.cd.core.webservice.auditinglog:osgi.bundle$1.0.0# OSGi#bundle.jar
>
> In S2-S4 Buckminster decides only to perform the following actions:
>
>
>
my.company.cd.core.webservice.auditinglog:osgi.bundle$1.0.0# OSGi#target.fragments
>
>
my.company.cd.core.webservice.auditinglog:osgi.bundle$1.0.0# OSGi#bundle.jar
>
> I suppose the main difference is that in this case .classpath and
> build.properties aren't available?
> Are there any other files that could influence this decision?
>
> The only other difference in the debug logs is the information logged when
> performing bundle.jar.
>
> In S1 it reads:
> Action
>
my.company.cd.core.webservice.auditinglog:osgi.bundle$1.0.0# OSGi#bundle.jar
> using 'up to date' policy COUNT: Rebuild needed: File count(0) <
> expected(1)
>
> In S2-S4 it reads:
> Action
>
my.company.cd.core.webservice.auditinglog:osgi.bundle$1.0.0# OSGi#bundle.jar
> using 'up to date' policy DEFAULT: Rebuild needed: Product has folders
>
> OK, so I decided to introduce some of the generated files into
> my.company.cd.core.webservice.auditinglog in W2 and to run S4.
> I found out that just adding the previously generated build.properties
> actually makes Buckminster decide to perform an eclipse.build!
>
>
>
my.company.cd.core.webservice.auditinglog:osgi.bundle$1.0.0# OSGi#eclipse.build
>
>
my.company.cd.core.webservice.auditinglog:osgi.bundle$1.0.0# OSGi#target.fragments
>
>
my.company.cd.core.webservice.auditinglog:osgi.bundle$1.0.0# OSGi#bundle.jar
>
> Does this mean that we must have build.properties checked into CVS even if
> we actually generate it?
>
> There's not any interesting debug information around the execution of
> eclipse.build.
> It appear to be running successfully, but unfortunately there is no output
> from our builder.
> I guess this means it doesn't run.
>
> Acccording to "Buckminster component meta-data language 1.0 (Reference)"
> it reads: "eclipse.build - requests a full build from the Eclipse build
> system ".
> I assume this mens doing the same as a build from inside Eclipse? This
> means invoking all the builders listed in .project, right?
> So, should everything then be OK here and if so, why is our builder not
> run?
> Do I still miss something?
>
> As I was experimenting with the contents of .project (like changing the
> orders of builders or removing them) I accidently had just the line below
> commented out.
>
> 
>
> This gave the following error, which shows that the Eclipse build system
> is really called:
>
> !ENTRY org.eclipse.jdt.core 4 4 2009-02-19 12:15:27.026
> !MESSAGE JavaBuilder handling CoreException while building:
> my.company.cd.core.webservice.auditinglog
> !STACK 1
> Java Model Exception: Java Model Status
> [my.company.cd.core.webservice.auditinglog does not exist]
> at
>
org.eclipse.jdt.internal.core.JavaElement.newNotPresentExcep tion(JavaElement.java:491)
> at
>
org.eclipse.jdt.internal.core.JavaModelManager.getPerProject InfoCheckExistence(JavaModelManager.java:1941)
> at
>
org.eclipse.jdt.internal.core.JavaProject.getPerProjectInfo( JavaProject.java:1756)
> at
>
org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspa th(JavaProject.java:1826)
> at
>
org.eclipse.jdt.internal.core.JavaProject.computeExpandedCla sspath(JavaProject.java:420)
> at
>
org.eclipse.jdt.internal.core.JavaProject.getExpandedClasspa th(JavaProject.java:1421)
> at
>
org.eclipse.jdt.internal.core.builder.NameEnvironment.comput eClasspathLocations(NameEnvironment.java:93)
> at
>
org.eclipse.jdt.internal.core.builder.NameEnvironment.<init >(NameEnvironment.java:41)
> at
>
org.eclipse.jdt.internal.core.builder.JavaBuilder.initialize Builder(JavaBuilder.java:596)
> at
>
org.eclipse.jdt.internal.core.builder.JavaBuilder.build(Java Builder.java:167)
> at
> org.eclipse.core.internal.events.BuildManager$2.run(BuildMan ager.java:633)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
> at
>
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:170)
> at
>
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:201)
> at
> org.eclipse.core.internal.events.BuildManager$1.run(BuildMan ager.java:253)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
> at
>
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:256)
> at
>
org.eclipse.core.internal.events.BuildManager.basicBuild(Bui ldManager.java:218)
> at
> org.eclipse.core.internal.events.BuildManager.build(BuildMan ager.java:360)
> at
>
org.eclipse.core.internal.resources.Project.internalBuild(Pr oject.java:516)
> at org.eclipse.core.internal.resources.Project.build(Project.ja va:94)
> at
>
org.eclipse.buckminster.core.internal.actor.AbstractBuildInt egrationActor.internalPerform(AbstractBuildIntegrationActor. java:46)
> at
>
org.eclipse.buckminster.core.actor.AbstractActor.perform(Abs tractActor.java:136)
> at
>
org.eclipse.buckminster.core.internal.actor.PerformManager.p erform(PerformManager.java:299)
> at
>
org.eclipse.buckminster.core.internal.actor.PerformManager.p erform(PerformManager.java:343)
> at
>
org.eclipse.buckminster.core.commands.Perform.internalRun(Pe rform.java:198)
> at
>
org.eclipse.buckminster.core.commands.WorkspaceCommand.run(W orkspaceCommand.java:99)
> at
>
org.eclipse.buckminster.cmdline.AbstractCommand.basicRun(Abs tractCommand.java:52)
> at org.eclipse.buckminster.cmdline.Headless.run(Headless.java:2 95)
> at org.eclipse.buckminster.cmdline.Headless.run(Headless.java:2 29)
> at org.eclipse.buckminster.cmdline.Headless.start(Headless.java :304)
> at
>
org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:193)
> at
>
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:110)
> at
>
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:79)
> at
>
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:386)
> at
>
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:179)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 549)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1236)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1212)
> !SUBENTRY 1 org.eclipse.jdt.core 4 969 2009-02-19 12:15:27.026
> !MESSAGE my.company.cd.core.webservice.auditinglog does not exist
>
> Since my S1 scenario works I guess this means that the eclipse.build
> action works.
> Since S2-S4 don't work, does this mean that eclipse.build doesn't execute
> all the builders from .project?
> Should I then do something else to get our builder called?
> Must I e.g. create CSPECX's for all the projects with this builder?
> If so, what should I write in them?
>
> I would very much appreciate any help. I'm kind of stuck here.
>
> Thanks.
>
>
> /John.

Report message to a moderator

Re: Problem building plugins with special builders [message #383063 is a reply to message #383057]

Wed, 25 February 2009 09:51

John

Messages: 107
Registered: July 2009

Senior Member

Hi Achim!

Thanks for the pointers. They have been helpful.

Actually I didn't expect S2 and S3 to work. I was just trying to get an
error caused by our missing builder (actually I also expected that for S1).
But that didn't happen and seems to be explained in this old article
http://www.eclipse.org/articles/Article-Builders/builders.ht ml.
Among other things it says that problems with e.g. a project nature will
fail silently. :-(
But after I found the correct Tracing options, I suddenly got some useful
output.

!ENTRY org.eclipse.core.resources 2 1 2009-02-24 10:45:41.906
!MESSAGE Skipping builder 'my.company.cd.dev.plugin.stubbuilder.builder'
for project 'my.company.cd.core.webservice.auditinglog'.
Either the builder is missing from the install, or it belongs to a project
nature that is missing or disabled.

and later when Buckminster calls the eclipse.build:

Tue Feb 24 10:45:41 CET 2009 - [main] Invoking (FULL_BUILD) on builder:
BuildManager$MissingBuilder(my.company.cd.core.webservice.au ditinglog)
Tue Feb 24 10:45:41 CET 2009 - [main] Builder finished:
BuildManager$MissingBuilder(my.company.cd.core.webservice.au ditinglog)
time: 0ms

So finally I got the error I was expecting and of course you were correct
that our builder has dependencies on plugins, which are not available in
the headless Buckminster install.
We will remove those, but until then I just installed the required
dependencies and now got the following trace output:

init actor:
eclipse.build[my.company.cd.core.webservice.auditinglog:osgi .bundle$1.0.0#OSGi#eclipse.build]
INFO: [start
my.company.cd.core.webservice.auditinglog:osgi.bundle$1.0.0# OSGi#eclipse.build]
...
Tue Feb 24 13:27:17 CET 2009 - [main] Build requested, needsBuild: false
state: 0 delay: 100
Tue Feb 24 13:27:17 CET 2009 - [main] Invoking (FULL_BUILD) on builder:
Axis2StubBuilder(my.company.cd.core.webservice.auditinglog)
-Dclient.wsdl=C:\Temp\psd\workspace\plugins\my.company.cd.co re.webservice.auditinglog\wsdl-src\wsdl\AuditingLog_v1.wsdl
-Dclient.project=my.company.cd.core.webservice.auditinglog
-Dtarget.gen=C:\Temp\psd\workspace\plugins\my.company.cd.cor e.webservice.auditinglog\src
-Dtarget.bin=C:\Temp\psd\workspace\plugins\my.company.cd.cor e.webservice.auditinglog\xmlbeans_bin
-Dpackagedata.file=C:\Temp\psd\workspace\plugins\my.company. cd.core.webservice.auditinglog\builderfiles\packagedata.prop erties
-Daxis2.lib=/C:/buckminster-1.1.340.r09908/plugins/my.compan y.cd.dev.plugin.builderruntime_1.1.4/./
Tue Feb 24 13:29:14 CET 2009 - [main] Builder finished:
Axis2StubBuilder(my.company.cd.core.webservice.auditinglog) time: 116119ms
Tue Feb 24 13:29:14 CET 2009 - [main] Invoking (FULL_BUILD) on builder:
JavaBuilder(my.company.cd.core.webservice.auditinglog)

Starting build of my.company.cd.core.webservice.auditinglog @ Tue Feb 24
13:29:14 CET 2009
Performing full build as requested by user
FULL build
About to compile
src/org/xmlsoap/schemas/soap/encoding/impl/UnsignedShortImpl .java
About to compile
src/org/xmlsoap/schemas/soap/encoding/impl/UnsignedShortDocu mentImpl.java
...
[parsing
/my.company.cd.core.webservice.auditinglog/src/my/company/cd /core/webservice/auditinglog/AuditingLogServiceStub.java
- #232/233]
[parsing
/my.company.cd.core.webservice.auditinglog/src/my/company/cd /core/webservice/auditinglog/AuditingLogService.java
- #233/233]
[analyzing
/my.company.cd.core.webservice.auditinglog/src/org/xmlsoap/s chemas/soap/encoding/impl/UnsignedShortImpl.java
- #1/233]
The project was not built since its build path is incomplete. Cannot find
the class file for java.lang.Object. Fix the build path then try building
this project
Writing new class file UnsignedShortImpl.class
[analyzing
/my.company.cd.core.webservice.auditinglog/src/org/xmlsoap/s chemas/soap/encoding/impl/UnsignedShortDocumentImpl.java
- #2/233]
[completed
/my.company.cd.core.webservice.auditinglog/src/org/xmlsoap/s chemas/soap/encoding/impl/UnsignedShortImpl.java
- #1/233]
Writing new class file UnsignedShortDocumentImpl.class
...
Writing new class file AuditingLogService.class
[completed
/my.company.cd.core.webservice.auditinglog/src/my/company/cd /core/webservice/auditinglog/AuditingLogService.java
- #233/233]
[233 units compiled]
>FULL BUILD STATS for: my.company.cd.core.webservice.auditinglog
> compiled 37569 lines in 26559ms:1414.5lines/s
> parse: 9126 ms (34.3%), resolve: 3272 ms (12.3%), analyze: 0 ms (0.0%),
generate: 2062 ms (7.7%)
Recording new state : State for my.company.cd.core.webservice.auditinglog
(#0 @ Tue Feb 24 13:29:14 CET 2009)
Finished build of my.company.cd.core.webservice.auditinglog @ Tue Feb 24
13:30:26 CET 2009
Tue Feb 24 13:30:26 CET 2009 - [main] Builder finished:
JavaBuilder(my.company.cd.core.webservice.auditinglog) time: 72656ms
Tue Feb 24 13:30:26 CET 2009 - [main] Invoking (FULL_BUILD) on builder:
ManifestConsistencyChecker(my.company.cd.core.webservice.aud itinglog)
Tue Feb 24 13:30:26 CET 2009 - [main] Build: no tree for delta
org.eclipse.pde.internal.core.builders.ManifestConsistencyCh ecker
[/my.company.cd.core.webservice.auditinglog]
Tue Feb 24 13:30:26 CET 2009 - [main] Builder finished:
ManifestConsistencyChecker(my.company.cd.core.webservice.aud itinglog)
time: 70ms
Tue Feb 24 13:30:26 CET 2009 - [main] Invoking (FULL_BUILD) on builder:
ExtensionPointSchemaBuilder(my.company.cd.core.webservice.au ditinglog)
Tue Feb 24 13:30:26 CET 2009 - [main] Builder finished:
ExtensionPointSchemaBuilder(my.company.cd.core.webservice.au ditinglog)
time: 30ms
Tue Feb 24 13:30:26 CET 2009 - [main] Build requested, needsBuild: true
state: 1 delay: 100
Tue Feb 24 13:30:28 CET 2009 - [main] Build requested, needsBuild: false
state: 0 delay: 100

So now our builder has finally run and has generated the necessary source
files.
Then Eclipse's JavaBuilder takes over and after a while reports the error
seen above:
"The project was not built since its build path is incomplete. Cannot find
the class file for java.lang.Object. Fix the build path then try building
this project"
Then it continues to write .class files.

I'm still stuggling with this error and I'm really unsure where the
problem is.
It's most likely caused by the .classpath file, but I can't see the
problem.

As I mentioned earlier we have a build.properties with the contents:

source.. = src/
output.. = bin/
bin.includes = META-INF/,\
xmlbeans_bin/,\
.

During the build process Eclipse generates .classpath with the contents:

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
<classpathentry kind="src" path="src"/>
<classpathentry kind="con"
path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
<classpathentry kind="con"
path="org.eclipse.pde.core.requiredPlugins"/>
<classpathentry kind="output" path="bin"/>
</classpath>

src and bin should be OK. org.eclipse.jdt.launching.JRE_CONTAINER should
default to the Java I'm running with.
The org.eclipse.pde.core plugin is part of the Buckminster headless
install so I suppose this should cover the las entry.

As an experiment I opened the workspace I've materialized to in Eclipse
and had the same error.
The I made a clean and build on the failing project and the error
disappeared.

Does anybody have an idea of what is causing this problem?

Thanks in advance.

/John.

Report message to a moderator

Re: Problem building plugins with special builders [message #383065 is a reply to message #383063]

Wed, 25 February 2009 15:23

Thomas Hallgren

Messages: 3240
Registered: July 2009

Senior Member

Hi John,

John wrote:
> The project was not built since its build path is incomplete. Cannot
> find the class file for java.lang.Object. Fix the build path then try
> building this project

what platform are you on and what's your current Buckminster version? I
very recently fixed a problem that had this symptom on MacOS X.

What target platform are you using?

Regards,
Thomas Hallgren

Report message to a moderator

Re: Problem building plugins with special builders [message #383067 is a reply to message #383065]

Thu, 26 February 2009 09:47

John

Messages: 107
Registered: July 2009

Senior Member

Hi Thomas!

I run on Windows XP SP2.

I have a Buckminster installation version 1.1.340.r09952 with the
following features:
org.eclipse.buckminster.core.headless.feature_1.1.340.r09952
org.eclipse.buckminster.cvs.headless.feature_1.0.0.r09930
org.eclipse.buckminster.maven.feature_1.1.0.r09904
org.eclipse.buckminster.pde.headless.feature_1.1.340.r09961
org.eclipse.buckminster.product_1.1.340.r09952

They were all downloaded wednesday.

I use an empty workspace that is used to materialize into using headless
Buckminster by specifying the -data option.
The folder I specify is deleted before every build to avoid potential
problems from last build.

I use an Eclipse 3.4 as the target RCP.
This isn't updated with the latest updates, but I expect this to be OK,
since it's just used as target.
I specify this as target using the preference
org.eclipse.buckminster.pde.targetPlatformPath.

/John

Report message to a moderator

Re: Problem building plugins with special builders [message #383072 is a reply to message #383067]

Fri, 27 February 2009 11:02

John

Messages: 107
Registered: July 2009

Senior Member

Hi!

I finally got my webservice project to build! :-)

As mentioned earlier in the thread we only check into CVS the minimum
files and folders required to build the project, since the most of it is
generated by our builder. This works fine when building the project from
Eclipse.

We then discovered the need to also have build.properties in CVS, in order
for Buckminster not to rule the plugin as binary and skip the
eclipse.build action.
Then we got the classpath problem with the missing java.lang.Object.

Since I could open the materialized workspace in Eclipse and build the
project, I decided to also try including the generated .classpath file in
CVS. This actually solved the classpath problem, but there was now a
complaint about a missing required src folder. After having also created
this folder the build actually completed successfully.

So there seems to be a crucial difference between building inside the
Eclipse IDE and to do it in the headless version. But I will continue to
do the same for all our webservice projects and then hopefully we get the
product to build.

Thanks for the help.

/John

Report message to a moderator

Re: Problem building plugins with special builders [message #383170 is a reply to message #383072]

Fri, 27 February 2009 21:23

Achim Demelt

Messages: 160
Registered: July 2009

Senior Member

Hi John,

That's great!

Although I wonder why you are experiencing these build problems... While we
do check in the .classpath file, the source folder where the generated files
are written to isn't. This works fine in our case. Does your builder (and
project nature) precede JDT in the .project file?

Achim

John wrote:

> Hi!
>
>
> I finally got my webservice project to build! :-)
>
> As mentioned earlier in the thread we only check into CVS the minimum
> files and folders required to build the project, since the most of it is
> generated by our builder. This works fine when building the project from
> Eclipse.
>
> We then discovered the need to also have build.properties in CVS, in order
> for Buckminster not to rule the plugin as binary and skip the
> eclipse.build action.
> Then we got the classpath problem with the missing java.lang.Object.
>
> Since I could open the materialized workspace in Eclipse and build the
> project, I decided to also try including the generated .classpath file in
> CVS. This actually solved the classpath problem, but there was now a
> complaint about a missing required src folder. After having also created
> this folder the build actually completed successfully.
>
> So there seems to be a crucial difference between building inside the
> Eclipse IDE and to do it in the headless version. But I will continue to
> do the same for all our webservice projects and then hopefully we get the
> product to build.
>
> Thanks for the help.
>
>
> /John

Report message to a moderator

Re: Problem building plugins with special builders [message #383172 is a reply to message #383170]

Sun, 01 March 2009 17:03

John

Messages: 107
Registered: July 2009

Senior Member

Hi Achim!

Yes, our builder is first (now), otherwise it doesn't work.
Our nature is not (actually I think it's last), but I'll check this
tomorrow.

Thanks.

/John.

Report message to a moderator

Re: Problem building plugins with special builders [message #383174 is a reply to message #383172]

Mon, 02 March 2009 09:38

John

Messages: 107
Registered: July 2009

Senior Member

Hi again!

It still complaints about missing src folder with the feature first.
It's strange though, that there is this difference compared to when
building inside an Eclipse IDE. There it works without problems.

/John.

Report message to a moderator

Previous Topic:	Editing cspex
Next Topic:	Problems with two entries for one component

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 25 06:10:46 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter