(Pear) Packaging

[Christian Grobmeier <gr...@gmail.com>]

Hi all,

@Christian: i think the packaging is working for me now. I got your
points with the pear packaging problem... I am thinking that the only
benefit of this pear package command is the validation and we could
leave it off by doing it ourselves. But lets leave it the way you
solved the issue.

Ok, so the complete build would be:

mvn package -> creates the sourcecode only based pear package
mvn site -> creates the site
mvn assembly:assembly -> creates the assemblies for distribution

I can live with just three commands - any other objections?

If no, we should take care about svn copy, deploy plugin and others.
Commons does have good stuff over there, but I do not know if we can
use the tools without pain :-)

Christian

Re: (Pear) Packaging

[Christian Grobmeier <gr...@gmail.com>]

> The benefit of the pear package command is that it generates the package.xml
> which pear needs. As this package.xml also contains a classification which
> file should be regarded as php, data or doc I fear we cannot replace this
> with the maven-assembly-plugin :-(

No, I think this file is generated with the package.php file - not
with "pear package".
If you comment the pear command out, you can see it

But I agree that we should not overcomplex this - as it is now is good for me

>> mvn package -> creates the sourcecode only based pear package
>> mvn site -> creates the site
>> mvn assembly:assembly -> creates the assemblies for distribution
>
> The first one is not neccessary, assembly:assembly calls "package":

Oh true, thanks! Even more easy :-)


> Hm, using plugins for this would be nice and I also have the maven-release-plugin
> in mind which automatically tags the current working copy, changes the version
> in pom.xml and builts a release from a checkout copy of the tagged version etc...

Yes, and I think there is a similar plugin in commons world - but if
release plugin does the job, lets do it with this one.

> But shouldn't we focus on making the release somewhen *really* soon now?
> If you ack the LOG4PHP-84 changes then there is no bug with the 2.0 tag left and
> I have the bad feeling that the whole voting and incubating process that we have
> to pass will tax my patience enough and we shouldn't prolong it any more :-)

Well, we actually are in the mid of the  release process :-)
I think we should configure out all tools we need for releasing and
create a proper release plan. It's the first time we release and you
can expect tons of comments from expierenced committers outside this
project, so better expect quite a while until its out :-) With all the
tools in place we have a good chance to keep this time as short as
possible.

So, lets go on with code siginin, tagging and scp'ing stuff - after
that we should be fine.

BTW, we need to review the wiki page with the latest pom changes,

Thanks!
christian

Re: (Pear) Packaging

[Christian Hammers <ch...@lathspell.de>]

Hi

On Thu, 29 Oct 2009 08:15:57 +0100
Christian Grobmeier <gr...@gmail.com> wrote:

> Hi all,
> 
> @Christian: i think the packaging is working for me now. I got your
> points with the pear packaging problem... I am thinking that the only
> benefit of this pear package command is the validation and we could
> leave it off by doing it ourselves. But lets leave it the way you
> solved the issue.

The benefit of the pear package command is that it generates the package.xml
which pear needs. As this package.xml also contains a classification which
file should be regarded as php, data or doc I fear we cannot replace this
with the maven-assembly-plugin :-(

> Ok, so the complete build would be:
> 
> mvn package -> creates the sourcecode only based pear package
> mvn site -> creates the site
> mvn assembly:assembly -> creates the assemblies for distribution

The first one is not neccessary, assembly:assembly calls "package":

$ mvn help:describe -Dcmd=assembly:assembly -Ddetail
...
  Before this mojo executes, it will call:
    Phase: 'package'

> 
> I can live with just three commands - any other objections?
> 
> If no, we should take care about svn copy, deploy plugin and others.
> Commons does have good stuff over there, but I do not know if we can
> use the tools without pain :-)

Hm, using plugins for this would be nice and I also have the maven-release-plugin
in mind which automatically tags the current working copy, changes the version
in pom.xml and builts a release from a checkout copy of the tagged version etc...

But shouldn't we focus on making the release somewhen *really* soon now? 
If you ack the LOG4PHP-84 changes then there is no bug with the 2.0 tag left and 
I have the bad feeling that the whole voting and incubating process that we have
to pass will tax my patience enough and we shouldn't prolong it any more :-)

bye,

-christian-