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
products.
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
self-contained.
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
one.
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
redistribute.
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,
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
