You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4php-dev@logging.apache.org by Christian Hammers <ch...@lathspell.de> on 2009/10/30 00:17:39 UTC
Last remarks regarding packages
Hi
The hopefully last discussion about packaging issues :) But I fear the
incubator reviewer would bring them up anyway:
1. The source .tar.gz and .zip contain the site/coverage-report/
directory. While including the generated phpdoc could be considered
useful for people who just want to use log4php and not rebuild it,
the coverage report seems pretty useless to me.
2. Should we distribute the apidocs alongside the .tar.gz even if
they could be generated by the user using maven?
3. The package-config.php and package.php are not included in
the .tar.gz and .zip. IIRC because they are not needed by the
endusers but it just came to my mind that this means that the
user cannot generate the phpdoc using "mvn site" as this would fail
due to the missing files. Ok, maybe phpdoc is generated before the
pear package, I don't remember, but it looks a bit unprofessional if
we distribute the pom.xml but know that it will fail with errors, or?
4. The creation of the superfluous empty .jar will not annoy any of
the reviewers, or? I have no idea how to turn it off and it would
probably require an ant task to simply remove it.
bye,
-christian-
Re: Last remarks regarding packages
Posted by Christian Hammers <ch...@lathspell.de>.
Hallo
Am Sun, 1 Nov 2009 20:22:16 +1000
schrieb "Gavin" <ga...@16degrees.com.au>:
> Hi Guys,
>
> Sorry, been a bit busy of late.
>
> Regarding Pear packaging, your intending to make this available via
> the main PEAR repository? (I investigated our own PEAR distribution
> but is not possible at this time).
I don't think that they will let us in as PEAR has their own licence
and code style policies. In addition they already have their PEAR_Log
and IIRC don't want more than one package for a task.
But we should keep it in mind, maybe they would accept it or we can
make some facade to be compatible.
> Regarding the new mvn targets, do you want me to extend buildbot to
> perform some more tests to include building these targets?
Currently "mvn site assembly:assembly" can be used to build all
packages. Is buildbot able to check if the two -src.tar.gz/zip and the
-pear.tgz have been built and e.g. are at least 50kb big or similar?
> I can, also get it to deploy to snapshots to Nexus repository staging
> area (repository.apache.org) , so you want me to do that?
Sounds like it couldn't hurt. The relevant files are the above mentioned
target/Apache_log4php-2.0.0incubating-pear.tgz
target/apache-log4php-2.0.0-incubating-SNAPSHOT-src.tar.gz
target/apache-log4php-2.0.0-incubating-SNAPSHOT-src.zip
> Anything else I can do?
Of course! Buildbot is still broken due to the problems with
the pdo-sqlite module: https://issues.apache.org/jira/browse/INFRA-2294
If I can be of help, contact me via Jabber: lathspell@jabber.gondor.com
> If we can get something ready for incubator to look at as a
> pre-release snapshot we can perhaps get some early feedback before
> trying it for real.
>
> Note also, that any release whilst under the incubator needs to have
> something like -incubating.snapshot in the name.
The PEAR package has an internal flag stabilit=alpha for snapshots but
I see if I can somehow get the snapshot into the file name as well.
bye,
-christian-
> Gav...
>
>
> > -----Original Message-----
> > From: Christian Hammers [mailto:ch@lathspell.de]
> > Sent: Sunday, 1 November 2009 4:55 AM
> > To: Log4PHP Dev
> > Subject: Re: Last remarks regarding packages
> >
> > Hello
> >
> > The only question left is whether we also put the apidocs into the
> > pear package. I've looked around a bit but judging on the ones I
> > have installed this seems not be usual. It would also be a problem
> > as PEAR is done in the "default:package" and the apidocs in
> > "site:site" goal...
> >
> > bye,
> >
> > -christian-
> >
> >
> > Am Fri, 30 Oct 2009 06:54:37 +0100
> > schrieb Christian Grobmeier <gr...@gmail.com>:
> >
> > > > 1. The source .tar.gz and .zip contain the site/coverage-report/
> > > > directory. While including the generated phpdoc could be
> > > > considered useful for people who just want to use log4php and
> > > > not rebuild it, the coverage report seems pretty useless to me.
> > >
> > > Yes, I think so.
> > >
> > > > 2. Should we distribute the apidocs alongside the .tar.gz even
> > > > if they could be generated by the user using maven?
> > >
> > > I would include API docs because the risk that a user needs em is
> > > quite high.
> > >
> > > > 3. The package-config.php and package.php are not included in
> > > > the .tar.gz and .zip. IIRC because they are not needed by the
> > > > endusers but it just came to my mind that this means that the
> > > > user cannot generate the phpdoc using "mvn site" as this would
> > > > fail due to the missing files. Ok, maybe phpdoc is generated
> > > > before the pear package, I don't remember, but it looks a bit
> > > > unprofessional if we distribute the pom.xml but know that it
> > > > will fail with errors, or?
> > >
> > > I agree again :-) IMHO a user should be able to run tests,
> > > coverage reports etc. all himself.
> > > This also goes for pear packages.
> > >
> > >
> > > > 4. The creation of the superfluous empty .jar will not annoy
> > > > any of the reviewers, or? I have no idea how to turn it off and
> > > > it would probably require an ant task to simply remove it.
> > >
> > > Voting is upon the assemblies itself, not on the creation
> > > process. We will not distribute this jar
> > > nor would we make it available for voting. Means, nobody will be
> > > annoyed of that.
> > > We can change the packaging mode to "dir" maybe and then only a
> > > directory will appear.
> > > If we want something else, we would have to create a custom
> > > lifecycle binding, but I don't think
> > > we need this at the moment.
> > >
> > > Cheers,
> > > Christian
> > >
> > > >
> > > > bye,
> > > >
> > > > -christian-
> > > >
> > No virus found in this incoming message.
> > Checked by AVG - www.avg.com
> > Version: 8.5.423 / Virus Database: 270.14.39/2468 - Release Date:
> > 10/30/09 15:18:00
>
RE: Last remarks regarding packages
Posted by Gavin <ga...@16degrees.com.au>.
Hi Guys,
Sorry, been a bit busy of late.
Regarding Pear packaging, your intending to make this available via the main
PEAR repository? (I investigated our own PEAR distribution but is not
possible at this time).
Regarding the new mvn targets, do you want me to extend buildbot to perform
some more tests to include building these targets?
I can, also get it to deploy to snapshots to Nexus repository staging area
(repository.apache.org) , so you want me to do that?
Anything else I can do?
If we can get something ready for incubator to look at as a pre-release
snapshot we can perhaps get some early feedback before trying it for real.
Note also, that any release whilst under the incubator needs to have
something like -incubating.snapshot in the name.
Gav...
> -----Original Message-----
> From: Christian Hammers [mailto:ch@lathspell.de]
> Sent: Sunday, 1 November 2009 4:55 AM
> To: Log4PHP Dev
> Subject: Re: Last remarks regarding packages
>
> Hello
>
> The only question left is whether we also put the apidocs into the
> pear package. I've looked around a bit but judging on the ones I have
> installed this seems not be usual. It would also be a problem as
> PEAR is done in the "default:package" and the apidocs in "site:site"
> goal...
>
> bye,
>
> -christian-
>
>
> Am Fri, 30 Oct 2009 06:54:37 +0100
> schrieb Christian Grobmeier <gr...@gmail.com>:
>
> > > 1. The source .tar.gz and .zip contain the site/coverage-report/
> > > directory. While including the generated phpdoc could be
> > > considered useful for people who just want to use log4php and not
> > > rebuild it, the coverage report seems pretty useless to me.
> >
> > Yes, I think so.
> >
> > > 2. Should we distribute the apidocs alongside the .tar.gz even if
> > > they could be generated by the user using maven?
> >
> > I would include API docs because the risk that a user needs em is
> > quite high.
> >
> > > 3. The package-config.php and package.php are not included in
> > > the .tar.gz and .zip. IIRC because they are not needed by the
> > > endusers but it just came to my mind that this means that the
> > > user cannot generate the phpdoc using "mvn site" as this would
> > > fail due to the missing files. Ok, maybe phpdoc is generated before
> > > the pear package, I don't remember, but it looks a bit
> > > unprofessional if we distribute the pom.xml but know that it will
> > > fail with errors, or?
> >
> > I agree again :-) IMHO a user should be able to run tests, coverage
> > reports etc. all himself.
> > This also goes for pear packages.
> >
> >
> > > 4. The creation of the superfluous empty .jar will not annoy any of
> > > the reviewers, or? I have no idea how to turn it off and it would
> > > probably require an ant task to simply remove it.
> >
> > Voting is upon the assemblies itself, not on the creation process. We
> > will not distribute this jar
> > nor would we make it available for voting. Means, nobody will be
> > annoyed of that.
> > We can change the packaging mode to "dir" maybe and then only a
> > directory will appear.
> > If we want something else, we would have to create a custom lifecycle
> > binding, but I don't think
> > we need this at the moment.
> >
> > Cheers,
> > Christian
> >
> > >
> > > bye,
> > >
> > > -christian-
> > >
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.423 / Virus Database: 270.14.39/2468 - Release Date: 10/30/09
> 15:18:00
Re: Last remarks regarding packages
Posted by Christian Hammers <ch...@lathspell.de>.
Hello
The only question left is whether we also put the apidocs into the
pear package. I've looked around a bit but judging on the ones I have
installed this seems not be usual. It would also be a problem as
PEAR is done in the "default:package" and the apidocs in "site:site"
goal...
bye,
-christian-
Am Fri, 30 Oct 2009 06:54:37 +0100
schrieb Christian Grobmeier <gr...@gmail.com>:
> > 1. The source .tar.gz and .zip contain the site/coverage-report/
> > directory. While including the generated phpdoc could be
> > considered useful for people who just want to use log4php and not
> > rebuild it, the coverage report seems pretty useless to me.
>
> Yes, I think so.
>
> > 2. Should we distribute the apidocs alongside the .tar.gz even if
> > they could be generated by the user using maven?
>
> I would include API docs because the risk that a user needs em is
> quite high.
>
> > 3. The package-config.php and package.php are not included in
> > the .tar.gz and .zip. IIRC because they are not needed by the
> > endusers but it just came to my mind that this means that the
> > user cannot generate the phpdoc using "mvn site" as this would
> > fail due to the missing files. Ok, maybe phpdoc is generated before
> > the pear package, I don't remember, but it looks a bit
> > unprofessional if we distribute the pom.xml but know that it will
> > fail with errors, or?
>
> I agree again :-) IMHO a user should be able to run tests, coverage
> reports etc. all himself.
> This also goes for pear packages.
>
>
> > 4. The creation of the superfluous empty .jar will not annoy any of
> > the reviewers, or? I have no idea how to turn it off and it would
> > probably require an ant task to simply remove it.
>
> Voting is upon the assemblies itself, not on the creation process. We
> will not distribute this jar
> nor would we make it available for voting. Means, nobody will be
> annoyed of that.
> We can change the packaging mode to "dir" maybe and then only a
> directory will appear.
> If we want something else, we would have to create a custom lifecycle
> binding, but I don't think
> we need this at the moment.
>
> Cheers,
> Christian
>
> >
> > bye,
> >
> > -christian-
> >
Re: Last remarks regarding packages
Posted by Christian Grobmeier <gr...@gmail.com>.
> 1. The source .tar.gz and .zip contain the site/coverage-report/
> directory. While including the generated phpdoc could be considered
> useful for people who just want to use log4php and not rebuild it,
> the coverage report seems pretty useless to me.
Yes, I think so.
> 2. Should we distribute the apidocs alongside the .tar.gz even if
> they could be generated by the user using maven?
I would include API docs because the risk that a user needs em is quite high.
> 3. The package-config.php and package.php are not included in
> the .tar.gz and .zip. IIRC because they are not needed by the
> endusers but it just came to my mind that this means that the
> user cannot generate the phpdoc using "mvn site" as this would fail
> due to the missing files. Ok, maybe phpdoc is generated before the
> pear package, I don't remember, but it looks a bit unprofessional if
> we distribute the pom.xml but know that it will fail with errors, or?
I agree again :-) IMHO a user should be able to run tests, coverage
reports etc. all himself.
This also goes for pear packages.
> 4. The creation of the superfluous empty .jar will not annoy any of
> the reviewers, or? I have no idea how to turn it off and it would
> probably require an ant task to simply remove it.
Voting is upon the assemblies itself, not on the creation process. We
will not distribute this jar
nor would we make it available for voting. Means, nobody will be
annoyed of that.
We can change the packaging mode to "dir" maybe and then only a
directory will appear.
If we want something else, we would have to create a custom lifecycle
binding, but I don't think
we need this at the moment.
Cheers,
Christian
>
> bye,
>
> -christian-
>