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 Serge Knystautas <sk...@gmail.com> on 2006/05/26 20:19:26 UTC
Different code bases terminology
I've noticed we have/are rapidly added/ing many "subprojects" to
James. The term "subproject" is something of a loaded term at Apache,
so wanted to a) have group discuss how they see these as related and
b) be intentional in the term we're using.
1. How these code bases are related
My 2 cents... these are code bases with separate code bases, separate
(but hopefully similar) build processes, separate (but visually
similar) websites. For me, the most important issue is that we have
only one committer base across all these. i.e., we're not going to
add someone exclusively to mime4j or postage.
2. Intentional with terms we're using
Here are some sample terms...
subproject - jakarta terminology
project - xml.apache.org's terminology
plugin - maven.apache.org's terminology
module - ?
codebase - ?
Others?
What do you think?
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Different code bases terminology
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann wrote:
> Stefano Bagnara wrote:
>> Imho the better name would be project. Under the James "TLP" Umbrella
>> we produce the following projects:
> [...]
> I like Noel's 'products' better.
I like both project (+1) and product (+0.8).
I don't have problems with subproject (+0.5)
I'm -0 to module or plugin because it is not our case.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Different code bases terminology
Posted by Bernd Fondermann <bf...@brainlounge.de>.
Stefano Bagnara wrote:
> Imho the better name would be project. Under the James "TLP" Umbrella we
> produce the following projects:
> - Server: SMTP/POP3/NNTP daemon
> - jSieve: SIEVE library in java
> - Mime4j: MIME library in java
> - jSPF: SPF library in java
> - Postage: SMTP/POP3 stress test tool in java
I like Noel's 'products' better.
On the Apache Homepage James and all the other TDLs are already called
'projects'.
So Apache James is a project with a unified committer base releasing
different products for different needs. 'Subprojects' would suggest that
there is also a 'subcommunity' which we want to avoid.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Different code bases terminology
Posted by Stefano Bagnara <ap...@bago.org>.
Serge Knystautas wrote:
> I've noticed we have/are rapidly added/ing many "subprojects" to
> James. The term "subproject" is something of a loaded term at Apache,
> so wanted to a) have group discuss how they see these as related and
> b) be intentional in the term we're using.
>
> 1. How these code bases are related
> My 2 cents... these are code bases with separate code bases, separate
> (but hopefully similar) build processes, separate (but visually
> similar) websites. For me, the most important issue is that we have
> only one committer base across all these. i.e., we're not going to
> add someone exclusively to mime4j or postage.
Already posted my +1 to the shared committer base in the previour reply.
I would also add more informations on the relations between James, jSPF
and the newly proposed Postage.
jSPF is a standalone library.
Norman already worked to add an SPFHandler to james, using this library.
I hope (I will propose this) we will bundle jspf by default in James
2.4/3.0. So jSPF could be a dependency for James.
Postage will be a standalone tool having dependencies on few parts of
James. So James does not depend on Postage, even if we could plan
integration tests for James using Postage. So maybe a set of James tests
will depend on Postage in future.
jSieve and Mime4j are standalone libraries: I would also like to see
future efforts to integrate jSieve and Mime4j with James. If I
understood it right jSieve integration would become much more appealing
when we finally will introduce IMAP support.
> 2. Intentional with terms we're using
> Here are some sample terms...
>
> subproject - jakarta terminology
> project - xml.apache.org's terminology
> plugin - maven.apache.org's terminology
> module - ?
> codebase - ?
>
> Others?
>
> What do you think?
Imho the better name would be project. Under the James "TLP" Umbrella we
produce the following projects:
- Server: SMTP/POP3/NNTP daemon
- jSieve: SIEVE library in java
- Mime4j: MIME library in java
- jSPF: SPF library in java
- Postage: SMTP/POP3 stress test tool in java
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Different code bases terminology
Posted by Norman Maurer <nm...@byteaction.de>.
Am Samstag, den 27.05.2006, 13:06 +0200 schrieb Stefano Bagnara:
> Serge Knystautas wrote:
> > I've noticed we have/are rapidly added/ing many "subprojects" to
> > James. The term "subproject" is something of a loaded term at Apache,
> > so wanted to a) have group discuss how they see these as related and
> > b) be intentional in the term we're using.
> >
> > 1. How these code bases are related
> > My 2 cents... these are code bases with separate code bases, separate
> > (but hopefully similar) build processes, separate (but visually
> > similar) websites. For me, the most important issue is that we have
> > only one committer base across all these. i.e., we're not going to
> > add someone exclusively to mime4j or postage.
>
> Already posted my +1 to the shared committer base in the previour reply.
> I would also add more informations on the relations between James, jSPF
> and the newly proposed Postage.
>
> jSPF is a standalone library.
> Norman already worked to add an SPFHandler to james, using this library.
> I hope (I will propose this) we will bundle jspf by default in James
> 2.4/3.0. So jSPF could be a dependency for James.
I hope this too.. But the current SPFHandler is not well integrated by
now. This will be better done when we refactor the SMTPHandler chain to
support "pluggable" features.
>
> Postage will be a standalone tool having dependencies on few parts of
> James. So James does not depend on Postage, even if we could plan
> integration tests for James using Postage. So maybe a set of James tests
> will depend on Postage in future.
>
> jSieve and Mime4j are standalone libraries: I would also like to see
> future efforts to integrate jSieve and Mime4j with James. If I
> understood it right jSieve integration would become much more appealing
> when we finally will introduce IMAP support.
>
You are right.
> > 2. Intentional with terms we're using
> > Here are some sample terms...
> >
> > subproject - jakarta terminology
> > project - xml.apache.org's terminology
> > plugin - maven.apache.org's terminology
> > module - ?
> > codebase - ?
> >
> > Others?
> >
> > What do you think?
>
> Imho the better name would be project. Under the James "TLP" Umbrella we
> produce the following projects:
> - Server: SMTP/POP3/NNTP daemon
> - jSieve: SIEVE library in java
> - Mime4j: MIME library in java
> - jSPF: SPF library in java
> - Postage: SMTP/POP3 stress test tool in java
>
> Stefano
>
Fully agree.
bye
Norman
Re: Different code bases terminology (and jSPF IP)
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
> Serge,
>
>> The term "subproject" is something of a loaded term at Apache
>
> Thanks for posting this. I'd started and stopped the same e-mail about
> three times. Primarily, because I want to doublecheck to make sure that the
> IP for jSPF and then Postage is handled properly. We should file IP
> Clearance forms for each of them.
I already tried to explain the exact path we followed writing jSPF and
the third party code involved.
I don't have enough knowledge of the IP and copyright notices law and I
hoped you could help with this.
We started from spfjava submitted "with grants for inclusion" by the
author (Roger Fullertone).
We rewrote from scratch the whole parsing and the whole "business"
processing algorythm. The only code we now have from spfjava (to be
confirmed by Norman) are a few utilities and costant classes and the
"MacroExpansion" code. I don't know how much we did change that.
We furthermore added unittests based on tests definition files (txt)
found at http://www.schlitt.net/spf/tests/tests_v2.1/test.txt (I wrote
this to the pmc list 20 days ago ;-) ).
We then added this tasks to JIRA to track this issues:
http://issues.apache.org/jira/browse/JSPF-5
http://issues.apache.org/jira/browse/JSPF-12
Norman, talking to an SPF developer in IRC found out that the tests were
also distributed as part of libspf2 (http://www.libspf2.org/), licensed
under the "LGPL or 2-clause BSD".
jSPF currently depends on dnsjava and log4j for the core library and
junit for the unit tests.
We would really be happy if you can help with this issues.
Furthermore we are ready for an 1.0b1 release. Norman closed one of the
few blocking issues for 1.0 (the website) today. I hope you can help
with the release steps, too!
SPF specifications we implement are described here:
http://www.ietf.org/rfc/rfc4408.txt
>> For me, the most important issue is that we have only one
>> committer base across all these. i.e., we're not going to
>> add someone exclusively to mime4j or postage.
>
> +1
+1
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Different code bases terminology (and jSPF IP)
Posted by Norman Maurer <nm...@byteaction.de>.
Am Samstag, den 27.05.2006, 12:56 +0200 schrieb Stefano Bagnara:
> Noel J. Bergman wrote:
> > Serge,
> >
> >> The term "subproject" is something of a loaded term at Apache
> >
> > Thanks for posting this. I'd started and stopped the same e-mail about
> > three times. Primarily, because I want to doublecheck to make sure that the
> > IP for jSPF and then Postage is handled properly. We should file IP
> > Clearance forms for each of them.
>
> I already tried to explain the exact path we followed writing jSPF and
> the third party code involved.
> I don't have enough knowledge of the IP and copyright notices law and I
> hoped you could help with this.
>
> We started from spfjava submitted "with grants for inclusion" by the
> author (Roger Fullertone).
>
> We rewrote from scratch the whole parsing and the whole "business"
> processing algorythm. The only code we now have from spfjava (to be
> confirmed by Norman) are a few utilities and costant classes and the
> "MacroExpansion" code. I don't know how much we did change that.
You are right the only think we keep are a few methods in IPAddr, and
the MacroExpand class ( we also change stuff there(.
>
> We furthermore added unittests based on tests definition files (txt)
> found at http://www.schlitt.net/spf/tests/tests_v2.1/test.txt (I wrote
> this to the pmc list 20 days ago ;-) ).
> We then added this tasks to JIRA to track this issues:
> http://issues.apache.org/jira/browse/JSPF-5
> http://issues.apache.org/jira/browse/JSPF-12
>
> Norman, talking to an SPF developer in IRC found out that the tests were
> also distributed as part of libspf2 (http://www.libspf2.org/), licensed
> under the "LGPL or 2-clause BSD".
>
> jSPF currently depends on dnsjava and log4j for the core library and
> junit for the unit tests.
>
> We would really be happy if you can help with this issues.
>
> Furthermore we are ready for an 1.0b1 release. Norman closed one of the
> few blocking issues for 1.0 (the website) today. I hope you can help
> with the release steps, too!
Im not close it ;-) There are still a few things todo. I whould like to
copy the contributor page content of james. Any problems with that ?
>
> SPF specifications we implement are described here:
> http://www.ietf.org/rfc/rfc4408.txt
>
> >> For me, the most important issue is that we have only one
> >> committer base across all these. i.e., we're not going to
> >> add someone exclusively to mime4j or postage.
> >
> > +1
>
> +1
>
> Stefano
>
+1
Norman
RE: Different code bases terminology
Posted by "Noel J. Bergman" <no...@devtech.com>.
Serge,
> The term "subproject" is something of a loaded term at Apache
Thanks for posting this. I'd started and stopped the same e-mail about
three times. Primarily, because I want to doublecheck to make sure that the
IP for jSPF and then Postage is handled properly. We should file IP
Clearance forms for each of them.
> For me, the most important issue is that we have only one
> committer base across all these. i.e., we're not going to
> add someone exclusively to mime4j or postage.
+1
As for terms, they are separately releasable packages. Other than that, who
cares? If they weren't separately releasable packages, we wouldn't be
having the discussion. :-)
I'd call them a product, in normal circumstances.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org