Stefano Bagnara wrote:

> Noel J. Bergman wrote:
>>> It contains the commons informations for the James project (website,
>>> repositories, developers, licenses).  Think at it as the AbstractPOM
>>> for our POMs (m2 has many Object Oriented things in its architecture)
>> It seems to me that the site/ structure was being used for that purpose.
>> That is also where the RDF files, KEYS, etc., have been located.

> 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.

> 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.

> 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?

> We have multiple maven2 based products in the James project

Well, that's certainly not my fault.  ;-)

> 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.

> 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?

> 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 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.

> > 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.

> > 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



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to