Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
Message-ID: <8D3680004D2FD5118B510002B32C0FBEEE47C6@bebr3mx1.corp.emc.com>
From: Marckx_Gino@emc.com
To: dev@maven.apache.org
Subject: RE: Setting up Maven-New
Date: Wed, 4 Jun 2003 02:45:56 -0400 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

> > > 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 implemented.
> 
> 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
> environment.
> 
> 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.


I completely agree that standards are so much better then custom made
solutions.  That is the reason why we are investigating the use of Maven
in the first place.  But we simply have got no choice but to use a
completely custom repository structure on an FTP server.
I know that we cannot use tools that depend on the standard layout, but
hey, if we could use Maven already, for us it is quite a progress!
If we can first convince the decision makers that using Maven is a good
thing, maybe aiming at a standard repository layout can be our next
goal ;-)

 
> > 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 to
> 
> > 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
> maven-new.
> 
> > > 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.


Ok, fair point.  I feel a little bit uncomfortable though because
semantically the same project is going to be broken into several pieces,
in which you might have to duplicate a great deal of the project.xml file...
But then again, there is inheritance to the rescue, right?  Ok, fair point.

Gino.

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