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 "Noel J. Bergman" <no...@devtech.com> on 2007/03/10 04:07:33 UTC
RE: All clear
robert burrell donkin wrote:
> http://svn.apache.org/repos/asf/james/server/trunk/ has been moved to
> http://svn.apache.org/repos/asf/james/server/trunk/pheonix-deployment/
HUH?! If it is trunk it should be called trunk. If it is some branch it
does NOT belong under trunk. The SVN conventions are trunk, tags and
branches. trunk is just that, and nothing else.
This is also mis-spelled: pheonix-deployment should be phoenix-deployment.
I'm sorry that I haven't been around to vet this stuff before now, but can
we please fix both of these things in SVN?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: All clear
Posted by Danny Angus <da...@apache.org>.
On 3/11/07, robert burrell donkin <ro...@gmail.com> wrote:
> are in the directory org.apache.james. good enough?
Yes, until I get my a*** in gear and do the mailet move.
BTW Sorry that's late in coming, I've been up to here ^ with all kinds of stuff.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: All clear
Posted by robert burrell donkin <ro...@gmail.com>.
On 3/10/07, Noel J. Bergman <no...@devtech.com> wrote:
> robert burrell donkin wrote:
>
> > > The automated build processes only use dist/james-${version}/downloads,
> > > which holds the various release packages. The rest of the directory
> > > structure is an unpackaged build for phoenix.
>
> > i always found that structure a little confusing but maybe that's just me
> :-/
>
> Which structure? The only part I really need is the one directory listed
> above.
having the release artifacts in dist/james-${version}/downloads. the
exploded pheonix directory feels to me like something that should live
in target, not dist. but this is just a comment, not an issue.
> > in the medium term perhaps we might think about putting the master
> > distributions directly into dist/james-${version}
>
> Eliminating the download/ directory? That's not a problem, except that I
> will need to modify my scripts to have a different set for the working
> branches and the new trunk.
let's leave it for now
> > BTW i'm not sure that i like the name 'stage' and think that perhaps
> > 'lib' would be better. opinions?
>
> Yes, lib/ is probably better than stage (referring to earlier topic). We
> might want to distinguish between our own components and external
> dependencies.
the directory uses the maven standard layout. so all james artifacts
are in the directory org.apache.james. good enough?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: All clear
Posted by Danny Angus <da...@apache.org>.
On 3/10/07, Noel J. Bergman <no...@devtech.com> wrote:
> Yes, I really like subant. Perhaps we can get back to using it, and
> eliminate the Maven ... er ... "stuff" ... that has crept into JAMES.
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: All clear
Posted by "Noel J. Bergman" <no...@devtech.com>.
robert burrell donkin wrote:
> > The automated build processes only use dist/james-${version}/downloads,
> > which holds the various release packages. The rest of the directory
> > structure is an unpackaged build for phoenix.
> i always found that structure a little confusing but maybe that's just me
:-/
Which structure? The only part I really need is the one directory listed
above.
> in the medium term perhaps we might think about putting the master
> distributions directly into dist/james-${version}
Eliminating the download/ directory? That's not a problem, except that I
will need to modify my scripts to have a different set for the working
branches and the new trunk.
> > Are you planning to build all of the components first, and then
> > stage the phoenix assembly underneath the phoenix-distribution
> > directory structure?
> unless anyone suggestions something better :-)
No, that's fine.
> subant allows me to build in sequence (apis, libraries, functions,
> deployments) calling standard targets. the component builds (apis,
> libraries, functions) create jars in stage/org.apache.james/jars. the
> deployment build picks these up and uses then to create the final
> deployment.
Yes, I really like subant. Perhaps we can get back to using it, and
eliminate the Maven ... er ... "stuff" ... that has crept into JAMES.
> BTW i'm not sure that i like the name 'stage' and think that perhaps
> 'lib' would be better. opinions?
Yes, lib/ is probably better than stage (referring to earlier topic). We
might want to distinguish between our own components and external
dependencies.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: All clear
Posted by robert burrell donkin <ro...@gmail.com>.
On 3/10/07, Noel J. Bergman <no...@devtech.com> wrote:
> robert burrell donkin wrote:
<snip>
> > the plan is for a gradual breaking out to reduce impact on development
>
> That's fine. So long as `ant ${target}` works from the root of trunk, and
> the dist/ directory is populated with the packaged release, we're fine.
cool
> > unless there are any objections, i'll alter the pheonix-deployment
> > module to use a first level directory for distributions
>
> The automated build processes only use dist/james-${version}/downloads,
> which holds the various release packages. The rest of the directory
> structure is an unpackaged build for phoenix.
i always found that structure a little confusing but maybe that's just me :-/
in the medium term perhaps we might think about putting the master
distributions directly into dist/james-${version}
> Are you planning to build all
> of the components first, and then stage the phoenix assembly underneath the
> phoenix-distribution directory structure?
unless anyone suggestions something better :-)
subant allows me to build in sequence (apis, libraries, functions,
deployments) calling standard targets. the component builds (apis,
libraries, functions) create jars in stage/org.apache.james/jars. the
deployment build picks these up and uses then to create the final
deployment.
BTW i'm not sure that i like the name 'stage' and think that perhaps
'lib' would be better. opinions?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: All clear
Posted by robert burrell donkin <ro...@gmail.com>.
On 3/10/07, Stefano Bagnara <ap...@bago.org> wrote:
> Stefano Bagnara ha scritto:
> > robert burrell donkin ha scritto:
> >> unless there are any objections, i'll alter the pheonix-deployment
> >> module to use a first level directory for distributions
> >>
> >> - robert
> >
> > I don't understand the last sentence: can you explain?
>
> Ok, Noel answer to the same message gave me an hint and I think I
> understood now!
>
> I'm fine with the solution: maybe the best thing is that the
> phoenix-deployment create the dist in an internal folder and the main
> build take a set of configured artifacts and place them in a first level
> directory (this is just an idea, I have no problem with any other solution).
sounds good but i prefer to delegate the copy to the module script.
this gives the module build more flexibility and keeps the master
build simple.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: All clear
Posted by Stefano Bagnara <ap...@bago.org>.
Stefano Bagnara ha scritto:
> robert burrell donkin ha scritto:
>> unless there are any objections, i'll alter the pheonix-deployment
>> module to use a first level directory for distributions
>>
>> - robert
>
> I don't understand the last sentence: can you explain?
Ok, Noel answer to the same message gave me an hint and I think I
understood now!
I'm fine with the solution: maybe the best thing is that the
phoenix-deployment create the dist in an internal folder and the main
build take a set of configured artifacts and place them in a first level
directory (this is just an idea, I have no problem with any other solution).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: All clear
Posted by Stefano Bagnara <ap...@bago.org>.
robert burrell donkin ha scritto:
> the plan is for a gradual breaking out to reduce impact on development
>
> unless there are any objections, i'll alter the pheonix-deployment
> module to use a first level directory for distributions
>
> - robert
I don't understand the last sentence: can you explain?
Thank you,
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: All clear
Posted by "Noel J. Bergman" <no...@devtech.com>.
robert burrell donkin wrote:
> the issue only arose because that i wasn't well enough to review and
> commit my changes in a timely fashion
Fair enough.
> the plan is for a gradual breaking out to reduce impact on development
That's fine. So long as `ant ${target}` works from the root of trunk, and
the dist/ directory is populated with the packaged release, we're fine.
> unless there are any objections, i'll alter the pheonix-deployment
> module to use a first level directory for distributions
The automated build processes only use dist/james-${version}/downloads,
which holds the various release packages. The rest of the directory
structure is an unpackaged build for phoenix. Are you planning to build all
of the components first, and then stage the phoenix assembly underneath the
phoenix-distribution directory structure?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: All clear
Posted by robert burrell donkin <ro...@gmail.com>.
On 3/10/07, Noel J. Bergman <no...@devtech.com> wrote:
> robert burrell donkin wrote:
> > Stefano wrote:
<snip>
> > > The current move from trunk to trunk/phoenix-deployment (if I understood
> > > him correctly) is only a temporary move
>
> Should have been done in a branch to minimize impact during the re-org, but
> since no one seems to be committing code or otherwise working on JAMES, no
> harm done.
the issue only arose because that i wasn't well enough to review and
commit my changes in a timely fashion
> > > in the end we'll have something similar to:
> > > server/trunk/build.xml (to build server and all its modules)
> > > server/trunk/phoenix-deployment
> > > server/trunk/pop3server
> > > server/trunk/smtpserver
> > > ...
>
> If we had done this from the outset, I wouldn't have posted my note, which
> complained specifically about trunk no longer being (in) the right place.
the plan is for a gradual breaking out to reduce impact on development
unless there are any objections, i'll alter the pheonix-deployment
module to use a first level directory for distributions
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: All clear
Posted by "Noel J. Bergman" <no...@devtech.com>.
robert burrell donkin wrote:
> Stefano wrote:
> > I agree on mime4j, server, jsieve, postage, jspf needing a ttb structure
> +1
OK, so let's move past this, since we all agree, and focus on the actual
discussion.
> > I think Robert proposed to change only the server folder to split its
> > content into multiple subprojects.
Perhaps, but that's not what he did, nor what his instruction implied, at
the time he made the change.
> > The current move from trunk to trunk/phoenix-deployment (if I understood
> > him correctly) is only a temporary move
Should have been done in a branch to minimize impact during the re-org, but
since no one seems to be committing code or otherwise working on JAMES, no
harm done.
> > in the end we'll have something similar to:
> > server/trunk/build.xml (to build server and all its modules)
> > server/trunk/phoenix-deployment
> > server/trunk/pop3server
> > server/trunk/smtpserver
> > ...
If we had done this from the outset, I wouldn't have posted my note, which
complained specifically about trunk no longer being (in) the right place.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: All clear
Posted by robert burrell donkin <ro...@gmail.com>.
On 3/10/07, Stefano Bagnara <ap...@bago.org> wrote:
> I agree on mime4j, server, jsieve, postage, jspf needing a ttb structure
> as they follow totally separate workflows, they use different build
> mechanisms and they are standalone libraries/products.
+1
> I think Robert proposed to change only the server folder to split its
> content into multiple subprojects.
+1
one server sub-project with one version but the code split up into
modular sub-components
> The current move from trunk to trunk/phoenix-deployment (if I understood
> him correctly) is only a temporary move: in the end we'll have something
> similar to:
>
> jspf/trunk
> mime4j/trunk
> server/trunk/build.xml (to build server and all its modules)
> server/trunk/phoenix-deployment
> server/trunk/pop3server
> server/trunk/smtpserver
> server/trunk/mailrepository
> server/trunk/fetchmail
> server/trunk/spoolmanager
>
> This is only a subset of a possible final solution. In the old threads
> you can find a list of modules we discussed about.
>
> Robert probably made a copy&paste to wiki:
> http://wiki.apache.org/james/Development/Modularisation#head-6070ae830fffd3aa5273d9b50262e904a72f2721
yep
just trying to record ideas discussed on list
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: All clear
Posted by Stefano Bagnara <ap...@bago.org>.
I agree on mime4j, server, jsieve, postage, jspf needing a ttb structure
as they follow totally separate workflows, they use different build
mechanisms and they are standalone libraries/products.
I think Robert proposed to change only the server folder to split its
content into multiple subprojects.
The current move from trunk to trunk/phoenix-deployment (if I understood
him correctly) is only a temporary move: in the end we'll have something
similar to:
jspf/trunk
mime4j/trunk
server/trunk/build.xml (to build server and all its modules)
server/trunk/phoenix-deployment
server/trunk/pop3server
server/trunk/smtpserver
server/trunk/mailrepository
server/trunk/fetchmail
server/trunk/spoolmanager
This is only a subset of a possible final solution. In the old threads
you can find a list of modules we discussed about.
Robert probably made a copy&paste to wiki:
http://wiki.apache.org/james/Development/Modularisation#head-6070ae830fffd3aa5273d9b50262e904a72f2721
Stefano
Noel J. Bergman ha scritto:
> Stefano Bagnara wrote:
>
>> Noel J. Bergman ha scritto:
>>> robert burrell donkin wrote:
>>>> http://svn.apache.org/repos/asf/james/server/trunk/ has been moved to
>>>> http://svn.apache.org/repos/asf/james/server/trunk/pheonix-deployment/
>>> HUH?! If it is trunk it should be called trunk. If it is some branch it
>>> does NOT belong under trunk. The SVN conventions are trunk, tags and
>>> branches. trunk is just that, and nothing else.
>> I think that this is almost standard for multimodule/granular projects.
>
>> This is a list of ASF projects I know follows the same approach:
>> activemq, cayenne, cocoon, apacheds, geronimo, mina, maven-archiva,
>> continuum, maven-components, jackrabbit...
>
> I'd have to review each to see what each is actually doing. A various
> points in time, some projects had totally screwed up SVN structure. But to
> focus on the real issue ...
>
>> Are you proposing to have a trunk/branches/tags structure for each
>> submodule? I'm against this, but I'm open to discussion or to a vote.
>
> It is very simple. If something is a separately releasable/versionable
> component, it gets a {ttb} structure. Else it does not.
>
> Having something like:
>
> trunk/
> mime4j/
> server/
> jsieve/
> ...
>
> is the WRONG approach. The right approach is what we are supposed to have:
>
> mime4/{ttb}
> server/{ttb}
> jsieve/{ttb}
> ...
>
> My objection is that Robert introduced a level under trunk and at least
> temporarily required that people switch to checking out that new level as
> trunk.
>
> --- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: All clear
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano Bagnara wrote:
> Noel J. Bergman ha scritto:
>> robert burrell donkin wrote:
>>> http://svn.apache.org/repos/asf/james/server/trunk/ has been moved to
>>> http://svn.apache.org/repos/asf/james/server/trunk/pheonix-deployment/
>> HUH?! If it is trunk it should be called trunk. If it is some branch it
>> does NOT belong under trunk. The SVN conventions are trunk, tags and
>> branches. trunk is just that, and nothing else.
> I think that this is almost standard for multimodule/granular projects.
> This is a list of ASF projects I know follows the same approach:
> activemq, cayenne, cocoon, apacheds, geronimo, mina, maven-archiva,
> continuum, maven-components, jackrabbit...
I'd have to review each to see what each is actually doing. A various
points in time, some projects had totally screwed up SVN structure. But to
focus on the real issue ...
> Are you proposing to have a trunk/branches/tags structure for each
> submodule? I'm against this, but I'm open to discussion or to a vote.
It is very simple. If something is a separately releasable/versionable
component, it gets a {ttb} structure. Else it does not.
Having something like:
trunk/
mime4j/
server/
jsieve/
...
is the WRONG approach. The right approach is what we are supposed to have:
mime4/{ttb}
server/{ttb}
jsieve/{ttb}
...
My objection is that Robert introduced a level under trunk and at least
temporarily required that people switch to checking out that new level as
trunk.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: All clear
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman ha scritto:
> robert burrell donkin wrote:
>
>> http://svn.apache.org/repos/asf/james/server/trunk/ has been moved to
>> http://svn.apache.org/repos/asf/james/server/trunk/pheonix-deployment/
>
> HUH?! If it is trunk it should be called trunk. If it is some branch it
> does NOT belong under trunk. The SVN conventions are trunk, tags and
> branches. trunk is just that, and nothing else.
I think that this is almost standard for multimodule/granular projects.
This is a list of ASF projects I know follows the same approach:
activemq, cayenne, cocoon, apacheds, geronimo, mina, maven-archiva,
continuum, maven-components, jackrabbit...
Are you proposing to have a trunk/branches/tags structure for each
submodule? I'm against this, but I'm open to discussion or to a vote.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: All clear
Posted by "Noel J. Bergman" <no...@devtech.com>.
robert burrell donkin wrote:
> > > http://svn.apache.org/repos/asf/james/server/trunk/ has been moved to
> > > http://svn.apache.org/repos/asf/james/server/trunk/pheonix-deployment/
>
> Needless to say, the nightly builds reflect nothing that's been done since
> this was done to trunk.
> judging by the report, the build seems to be executing
It is simply running the ant target in trunk, and expecting dist to be
exactly where and how it was. That no longer works, as seen by
http://people.apache.org/builds/james/nightly/.
If we are trying to modularize, fine, but trunk should still be the root.
No one should have to switch to trunk/something-else to actually have trunk,
which was your earlier instruction. Looking at
http://svn.apache.org/viewvc/james/server/trunk/
that should not have been necessary, except that the main build doesn't do
what is necessary. The main build should populate the dist/ directory off
the project root (trunk) with whatever artifacts make up the distribution.
And from what I can see of your work today, trunk really should be trunk,
and no one should have switched to the lower level directory, except for the
as yet incomplete top level build.
Personally, this reorg should have been done in a branch, and then moved
over when done, but that's moot if you're almost ready to complete it.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: All clear
Posted by robert burrell donkin <ro...@gmail.com>.
On 3/10/07, Noel J. Bergman <no...@devtech.com> wrote:
> > > http://svn.apache.org/repos/asf/james/server/trunk/ has been moved to
> > > http://svn.apache.org/repos/asf/james/server/trunk/pheonix-deployment/
>
> Needless to say, the nightly builds reflect nothing that's been done since
> this was done to trunk.
should be easy enough for me to fix
judging by the report, the build seems to be executing
am i correct in guessing that the nightly runs an ant target and then
processes the results?
if so, which artifacts are picked up by the nightly build scripts?
(i had planned on discussing distributions first but might be better
to code a straw man)
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: All clear
Posted by Stefano Bagnara <ap...@bago.org>.
robert burrell donkin ha scritto:
> the idea is that the new modules are generated by the task including
> build files. the build.xml in each generated module will import the
> general macros and targets from standard builds in build. it should be
> minimal.
>
> builds should have reasonable document and defaults
>
> for example:
>
> $ cd build-tools
> $ ant
> Buildfile: build.xml
> [...]
> $ ant -DMODULE=whatever generate-api-module
> [...]
> (had intended to post an example before now. hope that this is enough
> to get you started)
Thank you Robert, I think this is all I need!
It was easy enough I should have found it without asking, but now I'm
sure about what to do :-)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: All clear
Posted by robert burrell donkin <ro...@gmail.com>.
On 3/21/07, Stefano Bagnara <ap...@bago.org> wrote:
> robert burrell donkin ha scritto:
> > this is the first step towards modularisation of the server code. the
> > plan is to split the current code base into a number of modules in
> > subdirectories.
> >
> > the modular build scripts are mostly done. should be able to tidy them
> > up and commit them this weekend.
>
> I just fixed the deployment build.xml to generate correct artifacts, but
> I have problems understanding what to do to create api/function modules
> in this "ant build". Can you at least isolate the "mailet-api" and
> "mailet" modules (that was already creating separate jars) so I ca
> understand what I have to do to split our source tree in modules?
yes :-)
i was just about to propose that i take this on this weekend
(been busy trying to generate sieve filters so that i can run fetchpop
to avoid issues i now having with my ISP :-/ should have them finished
tomorrow)
> I tried to create folders and make copied of build-tools/*-build.xml to
> each folders but I keep getting errors likes this one:
> ----
> module-build.xml:33: Error: Module name must be set
> The 'name.module' property must be specified by the module build
> ----
the idea is that the new modules are generated by the task including
build files. the build.xml in each generated module will import the
general macros and targets from standard builds in build. it should be
minimal.
builds should have reasonable document and defaults
for example:
$ cd build-tools
$ ant
Buildfile: build.xml
usage:
[echo] Execute 'ant -projecthelp' to list recommended targets
[echo] Execute 'ant -help' to learn how to run these targets
BUILD SUCCESSFUL
Total time: 0 seconds
$ ant -projecthelp
Buildfile: build.xml
Build utilities and builds for tools. Generation of new modules.
Main targets:
generate-api-module Generates API module outline. Usage: ant
-DMODULE=<modulename> generate-api-module.
generate-deployment-module Generates deployment module outline.
Usage: ant -DMODULE=<modulename> generate-deployment-module.
generate-function-module Generates function module outline. Usage:
ant -DMODULE=<modulename> generate-function-module.
generate-library-module Generates library module outline. Usage:
ant -DMODULE=<modulename> generate-library-module.
Default target: usage
so if you want to generate an api module (say) called whatever
$ ant -DMODULE=whatever generate-api-module
Buildfile: build.xml
generate-api-module:
[echo] Creating module at ../whatever-api
[mkdir] Created dir: /opt/development/james-workspace/whatever-api
[mkdir] Created dir:
/opt/development/james-workspace/whatever-api/src/main/java
[mkdir] Created dir:
/opt/development/james-workspace/whatever-api/src/main/resources
[mkdir] Created dir:
/opt/development/james-workspace/whatever-api/src/main/config
[mkdir] Created dir:
/opt/development/james-workspace/whatever-api/src/test/java
[mkdir] Created dir:
/opt/development/james-workspace/whatever-api/src/test/resources
[copy] Copying 1 file to /opt/development/james-workspace/whatever-api
[echo]
[echo] The contents of NOTICE.txt may need appropriate editing to
accurately
[echo] reflect the contents of this module.
[echo]
BUILD SUCCESSFUL
Total time: 1 second
$ ls -la ../whatever-api/
total 32
drwxr-xr-x 3 rob users 4096 Mar 21 21:46 .
drwxr-xr-x 9 rob users 4096 Mar 21 21:46 ..
-rw-r--r-- 1 rob users 11468 Mar 21 21:46 LICENSE.txt
-rw-r--r-- 1 rob users 398 Mar 21 21:46 NOTICE.txt
-rw-r--r-- 1 rob users 293 Mar 21 21:46 build.xml
drwxr-xr-x 4 rob users 4096 Mar 21 21:46 src
(had intended to post an example before now. hope that this is enough
to get you started)
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: All clear
Posted by Stefano Bagnara <ap...@bago.org>.
robert burrell donkin ha scritto:
> this is the first step towards modularisation of the server code. the
> plan is to split the current code base into a number of modules in
> subdirectories.
>
> the modular build scripts are mostly done. should be able to tidy them
> up and commit them this weekend.
I just fixed the deployment build.xml to generate correct artifacts, but
I have problems understanding what to do to create api/function modules
in this "ant build". Can you at least isolate the "mailet-api" and
"mailet" modules (that was already creating separate jars) so I ca
understand what I have to do to split our source tree in modules?
I tried to create folders and make copied of build-tools/*-build.xml to
each folders but I keep getting errors likes this one:
----
module-build.xml:33: Error: Module name must be set
The 'name.module' property must be specified by the module build.
----
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: All clear
Posted by robert burrell donkin <ro...@gmail.com>.
On 3/10/07, Noel J. Bergman <no...@devtech.com> wrote:
> robert burrell donkin wrote:
>
> > http://svn.apache.org/repos/asf/james/server/trunk/ has been moved to
> > http://svn.apache.org/repos/asf/james/server/trunk/pheonix-deployment/
>
> HUH?! If it is trunk it should be called trunk. If it is some branch it
> does NOT belong under trunk. The SVN conventions are trunk, tags and
> branches. trunk is just that, and nothing else.
this is the first step towards modularisation of the server code. the
plan is to split the current code base into a number of modules in
subdirectories.
the modular build scripts are mostly done. should be able to tidy them
up and commit them this weekend.
> This is also mis-spelled: pheonix-deployment should be phoenix-deployment.
doh!
good catch thanks
i'll fix this and put it in with the scripts
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: All clear
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > http://svn.apache.org/repos/asf/james/server/trunk/ has been moved to
> > http://svn.apache.org/repos/asf/james/server/trunk/pheonix-deployment/
Needless to say, the nightly builds reflect nothing that's been done since
this was done to trunk.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org