Jérôme Renard wrote:
> Gaetano,
>
> Le 16/02/10 19:35, Gaetano Giunta a écrit :
>> Jérôme Renard wrote:
>>> Gaetano,
>>>
>>> Le 16/02/10 17:50, Gaetano Giunta a écrit :
>>>> Jérôme Renard wrote:
>>>>> Hi Gaetano,
>>>>>
>>>>
>>>> Hi JR, thanks for the quick reply.
>>>
>>> You are welcome.
>>>
>>> [...]
>>>> I just read the instructions, and there are a couple of questions I have
>>>> that are not answered in there:
>>>>
>>>> - I have a trunk and many branches. Shall the ant files be put in
>>>> /trunk/ant and /branches/2.0/ant
>>>> or in
>>>> /trunk/extension/ezoracle/ant and /branches/2.0/extension/ezoracle/ant
>>>>
>>>
>>> You can have an ant/<extension.name>.properties file for each of your
>>> branch wether it is trunk/ branches/ or anything else.
>>> Actually eZExtensionBuilder's build.xml file fetches the
>>> ${extension.name}.svn.url property so it is not a problem to create
>>> different
>>> builds for different branches.
>>>
>>> For example you could get the following directory structure :
>>>
>>> myextension
>>> ├── branches
>>> │ ├── 1.0
>>> │ │ └── ant
>>> │ │ └── myextension.properties
>>> │ └── 2.0
>>> │ └── ant
>>> │ └── myextension.properties
>>> └── trunk
>>> └── ant
>>> └── myextension.properties
>>>
>>> As long as you build from the correct directory, it will work :)
>>>
>>>> - how about a max and min supported versions for ezp? In the example below
>>>> you specify a single ezp version, but my branch 2.0 is compatible with ezp
>>>> 4.0 to 4.2
>>>> (and other branches have different compatibilities)
>>>
>>> Sounds like an interesting enhancement to me.
>>>
Added the feat. request in the extension forum (and requested membership ;) )
>>>>
>>>> - what is the usage of the create.tarball setting?
>>>
>>> Some extensions require a tarball like ezsi or ezxmlexport for example.
>>> If you set create.tarball to "yes" you will get a tarball once the build
>>> process is finished.
>>>
>>>>
>>>> - can you give more details about management of packages?
>>>>
>>>
>>> Note, here is how to get the list of available targets :
>>>
>>> 18:00 jer...@gimli~/work/www/php5/ezpublish/svn/trunk/extension/ezsi% ant
>>> -p -Dextension.name=ezsi
>>> Buildfile: build.xml
>>> eZExtensionBuilder build file
>>> Main targets:
>>>
>>> -build-dependency Builds a dependency
>>> -create-package-tarball Creates a tarball of an ezpackage.
>>> -fail-if-file-empty checks if a file exists but fails
>>> if it is empty
>>> all Build the extension and generate
>>> the tarball
>>> build Builds the extension
>>> build-dependencies Build dependent extensions
>>> check-gnu-files Checks for LICENSE and README files
>>
>> To be documented: where are these supposed to be
>
> I added the doc about that in the build file, build.xml line 442 :
>
> <!-- Checks for the presence of LICENSE and README files -->
> <!-- These files must be located below the root directory of the extension -->
>
>>
>>> check-sql-files Checks if a schema.sql /
>>> cleandata.sql is available for supported databases
>>
>> Same as above (btw, I thought we'df not settled up on a definitive dir for
>> those. good to see we have).
>
> build.xml on line 322, I agree that should go in the README file :
>
> <!-- Checks if a schema.sql file is present for -->
> <!-- any supported database -->
> <!-- -->
> <!-- The accepted directory structure is : -->
> <!-- -->
> <!-- myextension -->
> <!-- `__ sql -->
> <!-- |__ mysql -->
> <!-- | |__ cleandata.sql -->
> <!-- | `__ schema.sql -->
> <!-- |__ oracle -->
> <!-- | |__ cleandata.sql -->
> <!-- | `__ schema.sql -->
> <!-- `__ postgresql -->
> <!-- |__ cleandata.sql -->
> <!-- `__ schema.sql -->
>
This is nice, but most of the ez-developed extensions do not follow this naming
- they have sql/mysql/mysql.sql instead
Offenders: ezevent, ezgmaplocation, ezstarrating. ezlightbox and mbpaex use a
different naming convention even: sql/mysql/extname.sql...
>>
>>> clean Removes the entire build directory
>>> clean-all Removes the build/ and the dist/
>>> directory
>>> coding-standards-check Checks PHP code coding standard,
>>> requires PHPCodeSniffer
>>
>> I see this has not been implemnted yet.
>> I think the best thing would be to integrate the sniffer defs from
>> http://svn.projects.ez.no/ezcodensiffer/
>>
>
> That was the original plan, but we did not had enough time to do it :'(
>
>>> create-package-tarballs Creates tarballs for ezpackages.
>>> dist Creates a tarball of the built
>>> extension
>>> dist-clean Removes the generated tarball
>>> eznetwork-certify Runs the certification script,
>>> requires the latest eZNetwork extension
>>> generate-documentation Generates the document of the
>>> extension, if created in RST
>>> generate-ezpackage-xml-definition Generates an XML definition for eZ
>>> Publish extension package types
>>> generate-md5sums Generates an MD5 file with all md5
>>> sums of source code files
>>> help Shows this help
>>> init Prepares the extension to be built
>>> show-properties Shows the properties for this build
>>> file
>>> tests Launch unit tests if any
>>> update-ezinfo Updates ezinfo.php with correct
>>> version numbers
>>
>> To document: how is the line to be updated found (regexp used)
>
> Added doc about it in build.xml, line 187 :
>
> <!-- Uses a regular expression to search and replace the correct string
> -->
> <!-- Within the file, please note there is a limit of 25 sets to indent 3rd
> party -->
> <!-- lib version numbers, if you use more than 25 spaces the version number
> will -->
> <!-- not be updated correctly
> -->
>
Another candidate for README
>>
>>> update-license-headers Update license headers in source
>>> code files
>>> update-package-xml Updates version numbers in
>>> package.xml
>>
>> To do (could not find it yet in build.xml): add a target to update a
>> variable list of files setting the version number, ezp version number and
>> license - see as
>> an example of file to be patched:
>> http://svn.projects.ez.no/ezoracle/branches/2.0/extension/ezoracle/INSTALL
>>
Another request: verify for presence of changelog files.
- they are very useful
- if we standardize on their naming/placement, all the best
- we can timestamp them in the build process. A release date in the changelog
text is something we really do miss currently
>
> BTW I forgot to tell you there is a "secret" feature. Sometimes you want to
> exclude a specific file or a list of specific
> files from the build so what you can do is to create a
> ant/files.to.exclude.txt and it is explained how to use it in build.xml line
> 110 :
>
> <!-- in order to get directory removed they must be appended with a '/' -->
> <!-- for example -->
> <!-- ezinfo.php -->
> <!-- tests/ -->
>
> [...]
>>> No, not yet, it already took us (oms and me) quite a while to port the 6000
>>> lines shell script
>>> we used to use to build eZ Publish to its Ant equivalent so we focused on
>>> MySQL.
>>>
>>
>> Nice to see it shrank to 700 lines!
>
> Yes, me too. Unfortunately I lost too much hair during this port and they
> will not come back ^_^
>
--
Sdk-public mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/sdk-public
