You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Stefano Bagnara <ap...@bago.org> on 2008/08/04 13:34:16 UTC
[postage] refresh
Hi all,
I checked out postage to revamp the build and make sure it is self
contained and build like every other product we have in the repository.
I locally updated both the ant and the m2 descriptors and updated the
code to build against server trunk (of course this only changes how
postage receive mails and not what server it can test).
I'd like to remove java 1.4 support because it is a bit of a PITA to
support conditional build because of missing JMX support.
We are in 2008 and this is not a library but a tester tool, so I think
requiring java 5 is really ok in this case.
Summary of changes:
1) add a stage folder with every jar needed to build/run the project (so
to not have a JAMES_HOME folder to setup)
2) remove java 1.4 support / conditional build.
Please speak early if you are against this.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [postage] refresh
Posted by Stefano Bagnara <ap...@bago.org>.
I committed my change to postage. Now hudson pass both ant and maven builds.
I also update NOTICE and other docs according to tree content.
Please review and feel free to propose improvement.
Now Postage requires java 5 and its acceptor smtpserver is based on
server trunk snapshots (from a week ago).
I tested it against james 2.3.1 and it works like expected.
Bernd, if you still think (after my explanation) that basing postage
smtpserver on server-trunk is bad I will see what I can do to downgrade
it to james 2.3.1.
Stefano
Stefano Bagnara ha scritto:
> Bernd Fondermann ha scritto:
>> On Mon, Aug 4, 2008 at 13:34, Stefano Bagnara <ap...@bago.org> wrote:
>>> Hi all,
>>>
>>> I checked out postage to revamp the build and make sure it is self
>>> contained
>>> and build like every other product we have in the repository.
>>
>> :-) Great, thanks.
>>
>>> I locally updated both the ant and the m2 descriptors and updated the
>>> code
>>> to build against server trunk (of course this only changes how postage
>>> receive mails and not what server it can test).
>>
>> I'm not sure I like that. My initial goal was to make Postage work
>> against the latest released (i.e. reasonably stable) server codebase.
>> This means it cannot break if something changes in TRUNK. I would
>> still opt for this goal unless there are good reasons not to.
>
> The technical issue is that we already have good jars/poms for
> dependencies in james-server-trunk while this is not the same in james
> 2.3.1 so it would take much more time for me to make a "stage" for the
> v2.3 dependencies (because we don't have one, while we have one for trunk).
>
> If you plan to make a release then it worth building against something
> stable, otherwise IMHO it is good to build our products against some dev
> version, so we better understand the relationships and how to improve
> binding between projects.
>
> So, if you can leave with this being against trunk I will take care of
> downgrading it in case of a release attempt, otherwise I'll see how much
> it takes to do it and I'll decide if it works for me.
>
>>> I'd like to remove java 1.4 support because it is a bit of a PITA to
>>> support
>>> conditional build because of missing JMX support.
>>
>> :-)
>>
>>> We are in 2008 and this is not a library but a tester tool, so I think
>>> requiring java 5 is really ok in this case.
>>
>> +1
>>
>> ... which means Postage is again in the technological front-row of all
>> our products. ;-)
>>
>>> Summary of changes:
>>> 1) add a stage folder with every jar needed to build/run the project
>>> (so to
>>> not have a JAMES_HOME folder to setup)
>>
>> I would like to know what that would mean, also in the light of my
>> comments some paragraphs upwards.
>> (Short explanations are welcome ;-) )
>
> Sorry I given the "stage" folder process we use in every other product
> as "known", my bad.
>
> For ant the stage folder is nothing more than a structured lib folder.
> It contains any depednency jar for compiling and for running the project.
>
> In this specific case we had a lib folder having "some" dependencies:
> junit and jars from server was excluded, so I simply added each
> dependencies until I was able to run "ant compile" successfully and then
> I added more dependencies until I was able to run "ant run".
>
> After that I refactored the lib folder to a stage folder where every
> artifact are in the following format:
> stage/<groupId>/jars/<artifactId>-<artifactVersion>.jar
> groupId and artifactId are the names used by our m2 descriptors (in case
> of JAMES dependencies) or names used to deploy the jars to maven central
> repository in the case of other dependencies.
>
> Then I also added poms (ASF ones in case of ASF dependencies, written by
> myself in case of junit) because this make this "stage" folder usable
> from the maven descriptor in order to build the project and create the
> website.
>
> Hope I answered your question, please feel free to make more questions
> or to reiterate them if my english was meaningless ;-)
> I'm happy to explain why I do/did things and why I don't/didn't do other
> things.
>
> Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [postage] refresh
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann ha scritto:
> On Mon, Aug 4, 2008 at 13:34, Stefano Bagnara <ap...@bago.org> wrote:
>> Hi all,
>>
>> I checked out postage to revamp the build and make sure it is self contained
>> and build like every other product we have in the repository.
>
> :-) Great, thanks.
>
>> I locally updated both the ant and the m2 descriptors and updated the code
>> to build against server trunk (of course this only changes how postage
>> receive mails and not what server it can test).
>
> I'm not sure I like that. My initial goal was to make Postage work
> against the latest released (i.e. reasonably stable) server codebase.
> This means it cannot break if something changes in TRUNK. I would
> still opt for this goal unless there are good reasons not to.
The technical issue is that we already have good jars/poms for
dependencies in james-server-trunk while this is not the same in james
2.3.1 so it would take much more time for me to make a "stage" for the
v2.3 dependencies (because we don't have one, while we have one for trunk).
If you plan to make a release then it worth building against something
stable, otherwise IMHO it is good to build our products against some dev
version, so we better understand the relationships and how to improve
binding between projects.
So, if you can leave with this being against trunk I will take care of
downgrading it in case of a release attempt, otherwise I'll see how much
it takes to do it and I'll decide if it works for me.
>> I'd like to remove java 1.4 support because it is a bit of a PITA to support
>> conditional build because of missing JMX support.
>
> :-)
>
>> We are in 2008 and this is not a library but a tester tool, so I think
>> requiring java 5 is really ok in this case.
>
> +1
>
> ... which means Postage is again in the technological front-row of all
> our products. ;-)
>
>> Summary of changes:
>> 1) add a stage folder with every jar needed to build/run the project (so to
>> not have a JAMES_HOME folder to setup)
>
> I would like to know what that would mean, also in the light of my
> comments some paragraphs upwards.
> (Short explanations are welcome ;-) )
Sorry I given the "stage" folder process we use in every other product
as "known", my bad.
For ant the stage folder is nothing more than a structured lib folder.
It contains any depednency jar for compiling and for running the project.
In this specific case we had a lib folder having "some" dependencies:
junit and jars from server was excluded, so I simply added each
dependencies until I was able to run "ant compile" successfully and then
I added more dependencies until I was able to run "ant run".
After that I refactored the lib folder to a stage folder where every
artifact are in the following format:
stage/<groupId>/jars/<artifactId>-<artifactVersion>.jar
groupId and artifactId are the names used by our m2 descriptors (in case
of JAMES dependencies) or names used to deploy the jars to maven central
repository in the case of other dependencies.
Then I also added poms (ASF ones in case of ASF dependencies, written by
myself in case of junit) because this make this "stage" folder usable
from the maven descriptor in order to build the project and create the
website.
Hope I answered your question, please feel free to make more questions
or to reiterate them if my english was meaningless ;-)
I'm happy to explain why I do/did things and why I don't/didn't do other
things.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [postage] refresh
Posted by Bernd Fondermann <be...@googlemail.com>.
On Mon, Aug 4, 2008 at 13:34, Stefano Bagnara <ap...@bago.org> wrote:
> Hi all,
>
> I checked out postage to revamp the build and make sure it is self contained
> and build like every other product we have in the repository.
:-) Great, thanks.
> I locally updated both the ant and the m2 descriptors and updated the code
> to build against server trunk (of course this only changes how postage
> receive mails and not what server it can test).
I'm not sure I like that. My initial goal was to make Postage work
against the latest released (i.e. reasonably stable) server codebase.
This means it cannot break if something changes in TRUNK. I would
still opt for this goal unless there are good reasons not to.
> I'd like to remove java 1.4 support because it is a bit of a PITA to support
> conditional build because of missing JMX support.
:-)
> We are in 2008 and this is not a library but a tester tool, so I think
> requiring java 5 is really ok in this case.
+1
... which means Postage is again in the technological front-row of all
our products. ;-)
> Summary of changes:
> 1) add a stage folder with every jar needed to build/run the project (so to
> not have a JAMES_HOME folder to setup)
I would like to know what that would mean, also in the light of my
comments some paragraphs upwards.
(Short explanations are welcome ;-) )
> 2) remove java 1.4 support / conditional build.
+1
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org