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 20:37:11 GMT
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message