On 21 Aug 07, at 5:43 PM 21 Aug 07, James William Dumay wrote:
Sorry if I'm missing something but why they can't just publish
everything to their private repo and just mirror things
they want share to the public repository afterwards?
Sure, that could be done, however, this is yet more infrastructure
that
needs to be written and maintained in the build environment.
As being Maven user (I'm from Apache Cocoon) I support Jason's
opinion here. If you have very specific requirements that
could be fulfilled by existing tools (few lines of script) just
use them and don't pollute other tools with your
specific needs.
Why use yet another external tool?
From the maven website itself:
"Maven can manage a project's build, reporting and documentation
from a
central piece of information."
So, is the information for the control of artifact deployment not
within
the scope of the projects mission? Isn't maven supposed to manage my
projects build?
As you know, Maven already does this in a limited sense - you can
deploy
whole projects to one repository or another via specifying a
distribution management information in your pom.
It does this for the purpose of 1) staging, and 2) supporting more
then a release and snapshot repository. We fully support multiple
repositories as normally I recommend a setup with 5 repositories.
Separating the primary and secondary artifacts is a very different
use case, and one we never considered supporting.
The real use case here is giving developers the flexibility to control
what kinds of artifacts go where and subsequently who has access to
specific artifact types.
That's not a use case, that's simply how you would prefer to do this.
For example, at Atlassian, we have a model where customers pay for
a license and
receive our source code. Customers can then use Maven to resolve
dependant artifacts from our public maven repository and build the
entire product.
So why can't it all be in one repository? You have people who buy
your products with a non-source license and you give them access to
binaries from a Maven repository instead of an installer? Or you have
updaters that use a Maven repository so you only need the binaries
for this? This last case I could understand.
For IP reasons, we cannot publish the source and javadoc
artifacts publicly along with the jar artifact of which our internal
development staff and contractors need to use.
For your own artifacts that you are producing why do they need to be
public at all? I ask because I do something similar and I don't
understand what it is you're actually trying to accomplish. This
aside it still doesn't change the fact Maven wasn't designed to have
the primary artifact separated from the secondaries and simply causes
a discontinuity in tooling. This is currently how it works. For
anyone trying to debug their copy of an Atlassian product the Maven
IDE integration wouldn't work.
I think this would be a fairly common use case among other
companies with
similar models and if maven is a build management tool - why can't
it manage the
needs of commercial products too?
Sure, we have no problem supporting commercial products. But it does
not logically follow that because we don't allow the separation of
primary and secondary artifacts that we don't support commercial
products.
In your case would it not be easier to give people read-only access
to the SCM, they build it as you build it and have access to a
password protected repository that contains everything required for
building. I don't understand your need to separate it the binaries
from javadoc and sources.
Thanks
--
James William Dumay <[EMAIL PROTECTED]>
Atlassian Software Systems
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
