Community
Participate
Working Groups
The overall build process makes use of the map file "tag" of each element (feature / plugin / feature) to compute the appropriate qualifier. Each factory is responsible to return this value. What is it for the copytask?
From my understanding it's the root to the "exported" repository. For example, we use the "tag" to indicate if it should copy from the path containing the /main/LATEST version of a ClearCase View (e.g. tag=d:/views/latest) or from that stable branch (e.g. tag="d:/views/stable"). We also use it to customize the environment. For example, the map files may point to x:/aPath/plugins by default but on a Linux build machine there is no drive "X:". Instead the elements must be copied from "/home/aPath/plugins".
Unfortunately this won't work because the tag is directly used as is as a qualifier in the version number and the qualifier has a restricted grammar (I just updated the javadoc). Moreover since I suspect that your folders do not change, then you would produce plug-ins that always have the same version. Maybe should the COPY override tag take an additional parameter indicating the value to be given to the map file.
Gunnar?
Sorry, I completely missed this. So you propose the following syntax: element=TAG,PATH,PATH_PREFIX TAG would be the version PATH the path to the element PATH_PREFIX an optional path prefix that can be overwritten at build time
Pascal, I'm preparing the patch. But I'm not sure how to pass the TAG. Should we make the first entry in the TAG file the version to use or should I introduce an additional syntax? fetchTag=NIGHTLY, COPY=D:\PREFIX, CVS=HEAD, SVN=trunk or fetchTag=CVS=HEAD, SVN=trunk, COPY=D:\PREFIX, COPY_TAG=NIGHTLY
(In reply to comment #5) > the first entry in the TAG file should be: > the first entry in the fetchTag property in build.properties
Created attachment 39499 [details] Patch for specifying tag via COPY_TAG=... This patch goes with option two. The map file format is now expected to be "TAG, PATH[, PREFIX]". The PREFIX and the TAG can be overwritten independendly via fetchTag=COPY=D:/dev, COPY_TAG=NIGHTLY. Also updated the JavaDoc.
The same problem exists for SVN (SVNFetchFactory) implementation. SVN map files format: <type>@<id>=SVN,<tag>[:revision],<svnRepositoryURL>,<preTagPath>,<postTagPath> The resulting svn repository path is: $(svnRepositoryURL)/$(preTagPath)/$(tag)/$(postTagPath) Example for HEAD: svn://svnroot/component/trunk/plugin/project This format works for tag=trunk, but not for tags (requires the path svn://svnroot/component/ *tags/tagname* /plugin/project) The current solution is: - allow a relative path in the map file tag segment. The parseMapFileEntry() method sets the final directory in the IFetchFactory.KEY_ELEMENT_TAG element (used for the version qualifier). - it is possible to override this value by 'fetchTag=SVN=tags/somedirs/qualifier' This solution requires that the final tag directory is the version qualifier. An alternative solution is to set the svn preTagPath segment via fetchTag. Unfortunately you must repeat the map file component part (component/tags/tagname)
Currently we are not actively enhancing PDE build anymore. Therefore, I close this bug as WONTFIX. Please reopen, if you plan to provide a fix.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
