Home » Forums » Ant4Eclipse User Forum » PDE

buildFeature calls buildPlugin with pluginId but expects projectName?

April 20, 2010 by florian
Posted in

Hello everybody,

maybe I'm doing it wrong but I came across the following oddity:

I'm trying to build a feature with one plugin.

The projectName of the plugin (according to Eclipse's .project) is "Saros", the pluginId is "de.fu_berlin.inf.dpp" (according to the feature.xml in the feature project). Both projects (plugin and feature reside in the same workspace).

a4e1.0.0.M3 (earlier version hat the feature-is-not-built problem) delivers the following error: "The specified project 'de.fu_berlin.inf.dpp' does not exists in the workspace"

Looking into a4e-pde-macros.xml shows that buildPlugin is called using the projectName attribute (rev 1786, line 778). EclipseProjectDelegate#getEclipseProject which appears to be called eventually, also references the Eclipse project by projectName (rev 1557, line 87).

But the value that's passed to buildPlugin appears to be the pluginId, not the projectName...

(Hard-Coding the projectName ("Saros") builds the plugin but fails later).

So, who's wrong? a4e or me?

If you need more information I will gladly provide it.
Thanks in advance for all your input.

Florian
Btw: a4e1.0.0.M3 still has some minor typos ("resolvedversion" when it should be "resolved.version") which appear in the log messages.

‹ "<accessrules>" entries in the ".classpath" file are not recognized Thanks! - And: mkdir output directory ›

I think we have an open issue here...

Submitted by Gerd Wuetherich on Wed, 04/21/2010 - 09:07.

Hi,

I think that is a problem in ant4eclipse. Unfortunately I have no time to take a look at it today, but I will investigate this one tomorrow...

Regards,
Gerd

Hi Florian, Btw: a4e1.0.0.M3

Submitted by costamojan on Tue, 04/20/2010 - 22:05.

Hi Florian,

Btw: a4e1.0.0.M3 still has some minor typos ("resolvedversion" when it should be "resolved.version") which appear in the log messages.

Thanks for the hint. I fixed that, so the latest build won't contain this anymore (see http://hudson.nilshartmann.net/job/ant4eclipse/). Nevertheless feel free to find some more if there were some ;-)

Looking into a4e-pde-macros.xml shows that buildPlugin is called using the projectName attribute (rev 1786, line 778). EclipseProjectDelegate#getEclipseProject which appears to be called eventually, also references the Eclipse project by projectName (rev 1557, line 87).
 
But the value that's passed to buildPlugin appears to be the pluginId, not the projectName...
 
(Hard-Coding the projectName ("Saros") builds the plugin but fails later).
 
So, who's wrong? a4e or me?
If you need more information I will gladly provide it.

Generally this should work as expected (The delegate is not the cause of the issue). The 'buildPlugin' macro just builds a project being aware that a plugin is a special kind of project. Therefore the usage of the projectname is valid. I need more information in order to identify what might be the cause of your problem:

  1. Tell me the plugin-id as it's specified within you project "Saros" (will be found under workspace/Saros/META-INF/MANIFEST.MF
  2. Check whether Eclipse is capable to export the feature. If it's not possible you've probably got a configuration error.
  3. Go into the macro a4e-pde-macros.xml

    and jump to the 'buildPlugin' part (currently line 778). Add the following line and tell me what has been printed: <echo>PLUGIN-NAME: ${executeFeature.plugin.filename}

  4. If possible strap down your feature to a minimum and post it, so we can analyse it.

Best regards

Daniel Kasmeroglu

Re: buildFeature calls buildPlugin with pluginId...

Submitted by florian on Wed, 04/21/2010 - 08:33.

Thanks for the quick reply, Daniel,

1. de.fu_berlin.inf.dpp (Bundle-SymbolicName, the Eclipse wizard shows this as the plugin ID)
2. Yes, that works
3. Line 776 already contains a reference to ${executeFeature.plugin.filename}, it returns "de.fu_berlin.inf.dpp" (which is the correct directory name in the workspace)
4.

<?xml version="1.0" encoding="UTF-8"?>
<feature
      id="de.fu_berlin.inf.dpp.feature"
      label="Saros Feature"
      version="10.4.14.r2128">
 
   <description>
      Distributed Pair Programming for Eclipse.
   </description>
   <license>
....
   </license>
   <requires>
      <import plugin="org.eclipse.ui"/>
      <import plugin="org.eclipse.core.runtime"/>
      <import plugin="org.eclipse.ui.workbench.texteditor"/>
      <import plugin="org.eclipse.jface.text"/>
      <import plugin="org.eclipse.ui.editors"/>
      <import plugin="org.eclipse.core.resources"/>
      <import plugin="org.eclipse.ui.ide"/>
   </requires>
 
   <plugin
         id="de.fu_berlin.inf.dpp"
         download-size="0"
         install-size="0"
         version="10.4.14.r2128"
         unpack="false"/>
</feature>

Here the featureId corresponds to the path relative to the workspace, again.

Thanks in advance,
Florian

I'm afraid that I need to ask

Submitted by costamojan on Wed, 04/21/2010 - 08:56.

I'm afraid that I need to ask for the complete workspace (which means all of your projects stripped down to the absolute minimum).
Otherwise I don't see what might be wrong. Telling from your input everything seems to work as expected.

Best regards

Daniel Kasmeroglu

Re: buildFeature calls buildPlugin with pluginId but expects pro

Submitted by florian on Mon, 05/10/2010 - 15:19.

I found the problem.

The plugin project is called "Saros" according to the .project file (and also the directory name in the eclipse workspace). Eclipse takes care of the project name and the directory name in the workspace being the same.

This is not the case on our build server. The directory is called de.fu_berlin.inf.dpp (the pluginId) and .project contains "Saros" as the projectName. This seems to be legal (which is to say that I couldn't find examples to the contrary).

The problem:
buildFeature calls buildPlugin with "${executeFeature.plugin.filename}" as the "projectName", which in our case is incorrect and results in the feature build failing. Changing the "projectName" attribute in the .project file to the pluginId ("de.fu_berlin.inf.dpp") solves the problem.

Do you know if the assumption you're making (plugin directory name == projectName) is founded? I could try to convince my co-developers to rename the project but having a better reason than "this tool requires it" would be great.

In another issue, buildPlugin does not work for me if I provide a "featureId" instead of a "projectName" (complains about "required attribute projectName"). The web documentation says that this should be legal (I wonder why it isn't called pluginId, though).

If you need more information about any of these issues, I'll gladly provide it.

Thanks in advance,
florian

This is not the case on our

Submitted by costamojan on Mon, 05/10/2010 - 17:41.

This is not the case on our build server. The directory is called de.fu_berlin.inf.dpp (the pluginId) and .project contains "Saros" as the projectName. This seems to be legal (which is to say that I couldn't find examples to the contrary).

Ah, the dust turns away ;-) As you've said yourself the assumption 'directoryname = projectname' is maintained by Eclipse itself. This is the right way (just try to create this discrepancy within Eclipse and you won't have any success). Basically the configuration information within your development environment is just inconsistent with the environment on your ci server.

I suspect that you're using subversion as a source control system so I'm explaining what has happened on your system based on this assumption (not the first time that this came up to me):

In earlier versions the project was originally named 'de..XXX' and has been checked in this way. At some point in the past someone has changed the projectname and checked it in. A renamed project just causes the '.project' file to be altered, so the subversion location remained the same on the repository.
Whenever you checkout a project Eclipse is checking for the '.project' file to get the name, so Eclipse sets up the directory correctly.
On your CI server (let me guess: it's hudson ;-) there's no such analysis step, so the subversion directory is checked out as is thus causing this inconsistency.
So the issue is not related to A4E. Nevertheless there are some solutions you can use:

1. You can rename the project directory within the subversion repository correctly (must be done within the repository browser). I suggest this one as this establishes consistency.

2. You could configure your CI server accordingly, so the project would be checked out into the correct directory (basically forcing the CI server to behave like Eclipse).

3. You could write a little ant script which would be called ahead of the build process. This script would just check for each directory containing a '.project' file and compares the projectname with the directory name. If there's a difference just make a rename.

Best regards

Daniel Kasmeroglu

re: This is not the case on our

Submitted by florian on Tue, 05/11/2010 - 08:48.

Hey Daniel,

thanks for the clarification. I know that eclipse takes care of the directory name being equal to the projectName but the documentation (http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.platform.doc...) does not say anything about that being a guarantee. I will now assume it is.

Your theory about how that came into being is totally correct. Furthermore, the Working Set files include the "incorrect" filename (nobody knew that this was a violation).

And yes, our CI is Hudson. I will choose your option 1) as this is appears to be "the way it's supposed to be". I just wanted to make sure that we're doing it wrong atm.

Thanks for your detailed analysis.

florian

A final comment

Submitted by costamojan on Tue, 05/18/2010 - 19:18.

but the documentation (<a href="http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.platform.doc" title="http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.platform.doc">http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.platform.doc</a>...) does not say anything about that being a guarantee. I will now assume it is.

This is unfortunately very common. Nevertheless it's also understandable if you consider the number of components provided with eclipse. It's simply hard to keep everything in perfect shape.

Best regards

Daniel Kasmeroglu