maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <>
Subject RE: Setting up Maven-New
Date Tue, 03 Jun 2003 17:41:33 GMT
On Tue, 2003-06-03 at 08:33, wrote:
> > The layout in repository was intentionally fixed. There are good reasons
> for
> > that.
> > I think that support for other protocols than file:// and http://  can be
> > considered
> > if there will be more users demanding it.
> > If you want to use ftp:// you can rise an issue in JIRA.
> > 
> > I personally think that it is easier to set up own web server then ftp
> > server.
> > And FTP protocol is much more limited that HTTP/WebDav and etc. So I don't
> > see a reason
> > to use it.
> No doubt there is a good reason for fixing the repository layout and for
> using http and file protocols, but what about company policies? 

There are interfaces for all the components that control the layout.
Inside maven-new everything is a component so you are in fact free to do
whatever you like. But custom layouts will not be supported and you are
basically on your own if you have problems. If you need time to switch
and migrate then you can roll whatever you need to with what Michal has

Maybe you should think about what your company policy is. What is your
company policy on the use of software components? Do you use your own
standard or something like a J2EE or Avalon standard? I think in most
cases people gravitate toward a standard. As developers we demand
standards: APIs, interfaces, components. Only recently, with Maven, has
there been any movement toward standardizing building, artifact
location, documentation production and many other aspects of
development. If your policy is to roll your own, that's cool. If you
follow standards then why not move that way with your development

Ultimately I think any form of innovation will come to play at the
application level, I think most are sick of farting around with build
systems. All most people want is an easy way to build projects and
disseminate project information. 

We have tried to make maven-new flexible so that you can do whatever you
like it's just vigourously discouraged.

>  Should
> developers that are obliged to use a proprietary repository structure not be
> able to benefit from Maven?  

See above.

> If they can use Maven by providing another
> ArtifactDownloader implementation, why would that be a bad thing to do?  

It's not a bad thing to do. Write another ArtifactDownloader if you need

> It
> is not breaking the structure, it does not interfere with the rest of Maven.
> If it is a bad idea to have a custom implementation for those components,
> what is the reason then for having interfaces for those components?

Having a different repository layout is technically not a problem. It's
a problem from a standards POV. If you make your own layout with
completely different artifact handling rules then you've just lost out
on all the experienced gained by other Maven users. The interfaces are
there so anyone can write a different implemetation of a component. We
use this internally so we can try different implementations. So can you.
It's just something that isn't actively encouraged. With maven-new you
can roll your own if you like, the question is why would you.

Would you continue not to use J2EE components just because you haven't
in the past. Is deciding on a standard component API really that much of
a different decision than deciding on a standard development process. To
me it's not, but if you disagree you are free to do what you like with

> > I don't think that one project should produce more than one "heavy"
> artifact
> > like jar, war ejb etc.
> > But it's/ will be completely perfect for the project to publish multiple
> > artifacts like: jar, javadoc, src, pom
> > Usage patterns for both scenarios were frequently discussed on this list
> and
> > are supported
> > by Maven old.
> I agree that in most cases, one heavy jar is enough.  But take Log4J as an
> example.  Isn't there a log4j-core.jar and a log4j.jar?  How would you
> handle that?

Been discussed many times: breaking up your project into discrete
coherent builds and using the reactor to process them all.

> Gino. 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Jason van Zyl

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:
For additional commands, e-mail:

View raw message