Articles on Artifact Repository

[Steve Garcia <SG...@qrs.com>]

Does anybody know of any articles I can find on the Internet detailing the
advantages and drawbacks of using an artifact repository (instead of
sticking artifacts in an SCM) for software development?

I want to read more about this style of development - I have some colleagues
who are not convinced that it is a good idea to put artifacts somewhere else
besides a SCM system.  While there is general agreement that a repository is
a good thing (preventing duplicate copies of the same jar) my colleagues
argue that backing the repository with a SCM provides more security (can't
accidently put a patch into a third party jar) and allows anyone to, at any
past point in time, to get a complete, unadulterated snapshot of a project
and build it.  

I think there are good arguments both ways (even though I support the Maven
artifact model.)  

Thanks, Steve


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Articles on Artifact Repository

[Jason van Zyl <jv...@maven.org>]

On Wed, 2004-01-07 at 02:28, Steve Garcia wrote:
> Does anybody know of any articles I can find on the Internet detailing the
> advantages and drawbacks of using an artifact repository (instead of
> sticking artifacts in an SCM) for software development?
> 
> I want to read more about this style of development - 

For Java at least I don't think this was really practiced much before
Maven came along. But for Perl there is CPAN and I believe now an
equivalent for Python. Long ago when I did Perl stuff I always use CPAN
which is definitely where some of the ideas in Maven come from. Even for
Perl modules I made I put them in the local library. I have always found
it stranged putting generated entities into an SCM. I don't like
generated docs in an SCM and I don't like binaries in an SCM (save of
course images and what not).

For local projects that haven't a great number of dependencies which are
external then it probably isn't really a big deal to keep your artifacts
in an SCM.

The benefit of using the repository is that at some point you are going
to want to update some of the components you use: using a repository and
POMs you rely on the knowledge of the project maintainers to track the
dependencies for you. If you decide to upgrade to foo-1.2 from foo-1.1
and it's dependencies change then you can either figure out all the
changes yourself or rely on the people that know about the project,
namely the developers of that project. This of course assumes that we
have all the POMs in the repository which we are moving toward. We don't
have it yet but the design for it is there.

So you can do this maintenance over and over again if you like but it
boils down to the same notion, the most important notion in Maven is
that the project information is stored once by the people who know about
the project. As the repository is populated with POMs transitive
dependencies will be possible and all sorts of cool things will then be
possible. Again I'll come back to the upgrading of components: it's not
impossible that there will be tools that could easily test various
graphs of dependencies to see which ones work with your tests. Maybe you
need a certain feature in an updated component which causes conflicts
elsewhere and Maven could certainly help find a resolution that works.
You could of course do this all yourself but why bother.

I think the real power of Maven is really far from fruition and
transitive dependencies will be a big part of that.

I also hope that in time you will be able to take a POM and reliably
build an entire project with all its dependencies from source so that if
you really wanted to your could build everything from scratch with one
simple command. If you could do that I don't really see much point in
store binary artifacts in an SCM. Of course we need mechanisms like a
much augmented release plugin incorporating the new Maven SCM project
but we will eventually get there.

> I have some colleagues
> who are not convinced that it is a good idea to put artifacts somewhere else
> besides a SCM system.  While there is general agreement that a repository is
> a good thing (preventing duplicate copies of the same jar) my colleagues
> argue that backing the repository with a SCM provides more security (can't
> accidently put a patch into a third party jar) and allows anyone to, at any
> past point in time, to get a complete, unadulterated snapshot of a project
> and build it.  
> 
> I think there are good arguments both ways (even though I support the Maven
> artifact model.)  
> 
> Thanks, Steve
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
-- 
jvz.

Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Articles on Artifact Repository

["J. Matthew Pryor" <jm...@yahoo.com>]

Who says its an either/or proposition?

Oh I know there are discussions about how you shouldn't put jars into an SCM
system, but if you're a paranoid product developer (like me) and you have to
be able to recreate any build of your published product 'as at' any time in
the past, I think you definitely want all dependent jars in SCM (I know I
do)

There is nothing to stop you using the maven repository model, but get to
the repository via an SCM checkin (or both)

How the 3rd party jars get onto ibiblio is one thing, but how 3rd party jars
get into your own remote repository is entirely another.

I am toying with the idea of a 3-tieres remote repository approach. One will
be for published artifacts (i.e. jar:install etc not under SCM otherwise I'd
probably have to monkey with the deploy plugin?). The second will be for 3rd
party libraries (under SCM control) and the 3rd would be ibiblio, probably
just for maven and anything maven directly needs.

I haven't set this up yet so maybe it's a really bad idea

Matthew

> -----Original Message-----
> From: Steve Garcia [mailto:SGarcia@qrs.com] 
> Sent: Wednesday, January 07, 2004 6:28 PM
> To: 'users@maven.apache.org '
> Subject: Articles on Artifact Repository
> 
> Does anybody know of any articles I can find on the Internet 
> detailing the advantages and drawbacks of using an artifact 
> repository (instead of sticking artifacts in an SCM) for 
> software development?
> 
> I want to read more about this style of development - I have 
> some colleagues who are not convinced that it is a good idea 
> to put artifacts somewhere else besides a SCM system.  While 
> there is general agreement that a repository is a good thing 
> (preventing duplicate copies of the same jar) my colleagues 
> argue that backing the repository with a SCM provides more 
> security (can't accidently put a patch into a third party 
> jar) and allows anyone to, at any past point in time, to get 
> a complete, unadulterated snapshot of a project and build it.  
> 
> I think there are good arguments both ways (even though I 
> support the Maven artifact model.)  
> 
> Thanks, Steve
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org