OK, now I've added the same distribution funcionality to sdo project...an example of distribution task working on sdo project can be found here: [1]...of course it was necessary some minor changes on distribution task to fit on sdo project : )
Now, I think if everybody is ok with it, we could add this task also to sca subproject, otherwise, I will need some help with it, cause sca structure is a bit more complicated and I'm not used to...can you help me with that Brady? Adriano Crestani [1] http://people.apache.org/~adrianocrestani/sdo_distribution_example/<http://people.apache.org/%7Eadrianocrestani/sdo_distribution_example/> On Nov 28, 2007 10:20 PM, Adriano Crestani <[EMAIL PROTECTED]> wrote: > Hi, > > Sorry for the long time being inactive, but I'm back : ) > > I've got the ant build distribution generator signing correctly the packed > files. I first tried out to call directly gpg using the exec task, but, > unfortunately, during the gpg signing process it requires the password for > the secret key to be input, otherwise, the exec task does not allow any > input during its execution. So, I looked for another solution, and found the > Apache Commons OpenPGP project that provides an ant task just to sign files > using the gpg, then I compiled it and the generated the OpenPGP.jar that > was added to das/antscripts/ folder. The OpenPGP.jar requires another 2 > jars(described below) that should be download manually, I think it's ok, > once OpenPGP.jar will only be used to sign the distributions and will not > be included on the distributed files. Below the usage instructions, that was > added to READ_ANT_INSTALL file, of the ant auto distribution system: > > GENERATING A PROJECT DISTRIBUTION > ================================= > > To create a src and bin distribution of Tuscany DAS subproject, there must > be set some properties on platform.properties files: > > Property Required > Example Description > -------- -------- > ------- ----------- > > platform.public.key.path Yes > "E:/gnupg/trustdb.gpg" The public key ring file path > > platform.secret.key.path Yes > "E:/gnupg/secring.gpg" The secret key ring file path > > platform.key.id Yes > "148CAFB2" The key id used to sign the > distribution files > > platform.tuscanyDAS.distribution.dir NO > "C:\distribution\" The folder where the distribution > files will be generated, default=tuscanyDAS.root.dir/distribution > > platform.tuscanyDAS.release.file.name NO > "tuscany_das_native-1.0-incubator-M4-" The beginning of src and bin > packed distribution file name, default="tuscany_cpp_das". > > TUSCANY_DASCPP_RELEASE_NAME env var may be used as an alternative > > Also is required the bcpg-jdk<latest_version>-<latest_version>.jar and > jce-jdk<latest_version>-<latest_version>.jar files defines on classpath. > Both can be found at http://www.bouncycastle.org/latest_releases.html > > Use the "distribution" target to generate the src and bin distribution > file structure under platform.tuscanyDAS.distribution.dir folder. > Then use the "pack.distribution" target to pack the bin and src > distribution folders as .zip and .tar.gz and generate their .asc and .md5 > files. > A password must be set on the command line when using > pack.distributiontarget, this password is used to sign the packed > distribution files with the > secret key defined on platform.secret.key.path > > Usage: > ant distribution > // do whatever you want on the generated distribution files > ant pack.distribution -Dpassword="123456" > > The bad point in this system is that you have to type your password on > command line, a bad practice once shells usually have a log file of all > typed commands. I thought about a file, which contains the password, then > the ant could read the password from this file...this way the password would > not be typed on the command line, but I think it's a lot of work just to set > a password :S...suggestions??? > > I have also updated the distribution example on [1]. > > I think next step is to create the NOTICE, LICENSE...files for das that > are still missing :P > > [1] http://people.apache.org/ <http://tr_1196323527526> > ~adrianocrestani/das_distributi > <http://tr_1196323527526>on_example/<http://people.apache.org/%7Eadrianocrestani/das_distribution_example/%20> > > > On Nov 14, 2007 1:10 AM, ant elder < [EMAIL PROTECTED]> wrote: > > > On Nov 14, 2007 7:29 AM, Adriano Crestani < [EMAIL PROTECTED]> > > wrote: > > > > <snip> > > > > Luciano: > > > Distribution artifact names : I'd follow the same naming of previous > > > native releases [1] and use tuscany_das_cpp-1.0-incubator-M4-bin.zip > > > I'm also not sure if the native project wants to start using > > > incubating in the name, to follow the same pattern being used in the > > > java releases. > > > > > > > I think its currently "incubating" thats prefered these days, > > "incubator" > > was an older one. > > > > > > > > > > [1] > > > > > > > > http://people.apache.org/dist/incubator/tuscany/cpp/1.0-incubator-M2/win32/ > > > > > > Sorry, I have added a new property on plataform.properties file that > > > defines > > > the distribution file name, I just forgot to set it before pack the > > > distribution files, then it used the default value that is > > > "tuscany_das_cpp". But, I will be using > > > "tuscany_das_cpp-1.0-incubator-M4-<type>.<extension>" > > > naming pattern, following the last sdo and sca cpp release. > > > > > > > > > Release artifact names : Should DLL and other artifacts have > > > incubator/incubating on their names ? So, tuscany_das.dll would become > > > tuscany-das-1.0-incubator-M4.dll > > > > > > I was just following the last cpp bin releases. So, I think I'm not > > the > > > right person to answer that. But for me, it's ok to keep > > "tuscany_das.dll" > > > ; > > > ) > > > > > > > > The things that need to include "incubating" in the name are the > > artiacts > > that will be distributed individually somewhere , so the binary and src > > distributions do as they're on the download page, in Java all the jars > > that > > go in the the maven repository need it which is why all the sca/module > > jars > > have it but the sca/samples don't, so if the .dll's are available > > somewhere > > outside of the binary distribution they need it otherwise probably not. > > > > ...ant > > > >
