james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: Maven 2 and repositories, redux
Date Sun, 01 Oct 2006 16:32:17 GMT
Noel J. Bergman wrote:
>> If we use site as a backup/tracker for our website content we shouldn't
>> use the same folder for root poms and other sources.
> Remember that these are root directories.  For another example, the RDF
> files don't belong on the web site.  They are meta-data published only via
> SVN for the ASF's internal use.  So site/ was the site related content, not
> just the site.  It was what we had factored out from the code trees.

Yes, and this is why james-project doesn't belong to site: it is used to 
build our maven2 based products, so it is part of the source code of our 

>> I think we need a project folder and I wrote this in the vote, so we
>> could have discussed in that vote
> Discuss first, then vote.  Votes are to acknowledge a consensus.

It is clear that we don't have a consensus here... and it seems to me 
that is something more religious than technical, so a vote would 
simplify things.

 From your words it seems to me that ASF has much restrictive 
requirement for James and that this requirements do not apply to 
jakarta, directory,  maven and other maven based tlp projects, but I 
can't find documentation on the apache site with regard to this issue 
(or difference).

>> Imho the pom things was polluting the folder and it was mixing 2 things
>> that had almost nothing to share.
> So projects/ is purely mavenization?  Since each releasable component,
> jsieve, jspf, server, site, etc., are supposed to have self-contained trees,
> with the common site related information factored out, what does projects/
> do for us?  It has a {ttb} structure, so what is project/ as a separately
> versioned entity?

Postage already depends on james-server: so we already have this 
dependency between products in our repositories and products are not 

Yes, project has now a ttb structure and we'll need to release it when 
we'll be ready to release jspf and mime4j.

>> We have multiple maven2 based products in the James project
> Well, that's certainly not my fault.  ;-)

Of course, I did it. Otherwise we would not have a jspf product and 
mime4j would be still on maven1. If you want to write *WORKING* ant 
scripts that give us what maven is givin us and keep them updated I will 
be happy to dismiss maven and have more free time to work on the code.

>> they have common informations, and that informations in maven
>> (that is Object Oriented) is shared in a "superclass": our
>> james-project.
> So this is shared Maven stuff, very similar to how site is shared content.

Yes, shared data for our products. Our "super"/"abstract" product.

>> I found a solution that allow us to make a m2 release without using
>> ibiblio dependencies and without adding repositories. I added the
>> "repo/third-party-m1" as a customized library folder for each product
>> that need this. I proposed this to the repository list but they never
>> replied with considerations on this because they started talking again
>> of repositories security and the fact that they are waiting for your
>> considerations about the security changes proposal for maven2.
> Mine?  LOL  /me goes to look at that list now, too.  Ok, well Brett was
> wrong.  I didn't even know about his proposal until you just mentioned the
> topic.  I'll reply to him there.  And I see that Robert has already done his
> usually excellent job of review, along with a few others.  :-)
> However, with respect to:
>> I added the "repo/third-party-m1" as a customized library folder for
>> each product that need this. I proposed this to the repository list
>> but they never replied with considerations
> Dims, Steve and Henri did reply to you with very consistent responses.  As I
> understood the suggestion, it is the same as Norman uses, or at least
> similar: define a local, file-based, repository.  Dims, Steve and Henri each
> explained why that was a good idea, including Henri's comment to you that
> "[The Infrastructure Team] might be against the idea of putting build
> dependables on a project's website", and all of them explaining various
> security concerns.  And you replied to Dims that you liked the idea!  :-)
> Was there something else from them that you needed?

In my reply I also raised a few problems with that idea and proposed a 
different solution (evolution of that idea) where we didn't need a 
shared repository but we simply include the per-project jars in the 
source tree for that project like we do for ant-based projects (simply 
using a different convention for the lib folder structure).
This is how jspf and mime4j currenlty builds and it is working. On 
repository they didn't reply about this solution.
I think this is the best from both world and much more similar to how we 
do things using ant.

We are lucky because we don't have license restricted dependencies and 
we can include all of them. My solution would not apply to projects 
depending on restricted libraries.

>> On the repository list Henri Yandell say different things from you and
>> say that creating a folder in svn adding there 3rd party libraries that
>> are compatible with the ASF license is something we can do.
> I've read everyone's replies, including Henri's, and if you think that we
> said different things, you misunderstood one of us.  The ability to have
> third party jars in SVN, so long as they are license compatible, is not a
> problem and as clarified again during the licensing discussions.  However,
> having an SVN directory and using it as a Maven repository are not the same
> thing.  Just ask how upset people can get when they see XML schema
> downloaded directly from ASF infrastructure by tools.  This is one reason
> why we have talked about having an ASF-hosted repository for them, but there
> are outstanding issues to make sure that it can be done securely and
> efficiently.  In the meantime ...

I don't want to talk about this again: of course I don't agree, but I 
think I already provided a lot of information against this arguments and 
now I moved to a different proposal that does not include the creation 
of a james repository so it does not make sense to discuss again of this 

>> I just need a solution to be able to release our m2 based products
>> (mime4j and jspf first of all).
> So what's the problem?  People download the binaries and use them.  For
> people working from source, follow the pattern recommended on repository@:
> self-contained projects with local, file-based, repositories.  Just forget
> that Maven can download anything.  It is a bad idea, anyway, at least for
> now.  If I understood him correctly, Norman tells me that he downloads all
> dependents, himself, and never has Maven download anything ever.  That
> sounds like the best strategy until the ASF has its own repository, and
> Maven can authenticate downloads.

With the current setup jspf and mime4j have a file based repository that 
is downloaded with the source tree for 3rd party libraries and only uses 
networking to download jars from official ASF repositories.
Plugins are still downloaded from ibiblio if you don't have them.
All of other ASF products releasing on m2 do the same: we already are 
one step beyond because we don't use ibiblio for dependencies we 

>>> the lack of an answer doesn't mean that you should simply bypass ASF
> policy
>> I think I never bypassed the policy
> To be clear, I am complaining about one thing in specific: svn commits when
> you know that there are no commit notices.  That is the specific issue.  You
> should have understood this from when Bernd accidentally committed without
> notices: notices are considered essential to our oversight process.  So
> essential that we even have a tool for re-running the notices if they've
> gotten lost, but it is rather not fun to use.

Notices have been done MANUALLY: so we HAD notices: and the fact that 
everyone was aware of this manual notices prove they worked. You was not 
aware of this, but you also missed 6 mails in 2 weeks window were I 
asked you to add the notifications, so maybe you have been to busy to 
give the needed oversight on this project.

>>> In any event, I talking with infrastructure to make sure of the correct
>>> changes to have changes at the james/ level notify general@, and
> everything
>>> else that isn't specifically defined notify server-dev.
> With a bit of luck, I've got the notices in place and didn't break the
> mailer doing it.  Unfortunately, I'm going to be off-line for the 36 hours
> or so, so if anything IS wrong, please notify the infrastructure team
> directly, or see if Serge can fix it.
> 	--- Noel

Sure, thank you,

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message