Noel J. Bergman wrote:
Stefano Bagnara wrote:
Noel J. Bergman wrote:
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.
Spanning a single versionable entity across more than one {ttb} structure is
rather odd, but it is possible preferable to svn:external.
Sorry, maybe I have not been clear.
Project will be an indipendent releasable/versionable entity, and our
products will depend on specific versions of this entity. It is like a
standard jar depenency, but is a pom.
We now use "-SNAPSHOT" versions for all of them, but to be able to make
a non SNAPSHOT release of jspf maven will require that every dependency
is not SNAPSHOT, also, so we'll have to release also james-project and
maven-skin.
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).
Which words? What did you read from any of the folks on repository@, when
they spoke against using the download mechanism and said to use local,
file-based, repositories because of problems with Maven-driven traffic and
security issues that was different?
I'm not sure I fully understant the maven-driven traffic.
A developer that download sources from the repository will create the
same traffic because it does not change things if he download it via SVN
or if the jars are downloaded by maven.
We probably have only to make sure that our source and binary
distributions will not contain references to that repository but will
contain local copy (in the zip/tar.gz) of the dependencies, right?
Yes, project has now a ttb structure and we'll need to release it when
we'll be ready to release jspf and mime4j.
Release it as what? As PART OF something else, e.g., jSPF?
Release it as a shared dependency for our product. This will not be used
by our users but we (developers) need it.
This is a dependency like jspf for server: before to release next-server
we'll have to release jspf beacuse next-server depends on it.
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).
OK, so still a local, file-based, repository? How does this substantively
differ from what Dims et al suggested? Perhaps they didn't notice anything
different enough upon which to comment?
The main difference is that it is "local" once you checked out the
source tree, because it is include in the source tree for the product.
Otherwise developers will have to manually search the internet and
verify each artifact.
Putting them in the source tree in a local "maven1 style" (aka legacy)
repository is much more similar to what we did with ant (and the lib
folder).
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.
That's OK. Such libraries are being so discouraged that I doubt that you
will see much of them anymore.
I hope so!
My only doubt is junit: can you confirm that we can legally include it
in the repository? I understand that CPL is compatible, but I don't know
why I seem to remember that junit was not good for inclusion...
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.
That's fine, with the caveat that we should make sure that no one is
complaining about our driving downloads to ASF servers.
--- Noel
So I have to check out if it is possible to create a source package that
does not include the original pom.xml repositories, but include every
dependency in the final package.
This way it would be really similar to what we did with ant, right?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
