Mailing-List: contact m2-dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <DF7EC83D7AFBD411965B0008C7596EC501384721@imtfexchange.imtf.ch>
From: Maczka Michal <michal.maczka@imtf.ch>
To: m2-dev@maven.apache.org
Subject: RE: m1 and m2 co-existing
Date: Fri, 4 Jun 2004 14:52:55 +0200 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"


> -----Original Message-----
> From: Rafal Krzewski [mailto:Rafal.Krzewski@caltha.pl]
> Sent: Friday, June 04, 2004 10:00 AM
> To: m2-dev@maven.apache.org
> Subject: Re: m1 and m2 co-existing
> 
> 
> Jason van Zyl wrote:
> > Howdy,
> > 
> > One of the things that I would like to work very well is 
> the ability for
> > m1 and m2 to run side by side with zero difficulty and for 
> the most part
> > things work fairly well but I wanted to throw some more ideas.
> > 
> > The name of the POM xml file:
> > 
> > m1: project.xml
> > m2: pom.xml
> > 
> > This I would like to do first so that people can try 
> experimenting with
> > the v4 POM without having to touch the m1 project.xml. I 
> also think the
> > name pom.xml is more fitting, more mavenesque. It will also allow a
> > clear separation between m1 and m2 so for example if m2 is 
> run and no
> > pom.xml exists but a project.xml does then it can be 
> converted on the
> > fly or the user can be asked if they would like to create a 
> pom.xml from
> > the project.xml.
> > 
> > The name of properties file with parameters:
> > 
> > We are definitely going unify the m1 notion of 
> project.properties into
> > the POM itself for m2 but there will still be a need to have a
> > properties file for parameters. For this I was thinking that
> > maven.properties would be an appropriate name and again 
> this will allow
> > an m1 build to sit along side an m2 build.
> > 

For which parameters?
Do you mean here that we are going to collapse project.xml and
project.properties into pom.xml
and maven.properties will replace build.properties?


The main use case which we have to support is to have a possibility of
fetching poms from the remote repository.
this means that most likely whatever the pom is it should be a single file. 

I think that we might consider treating the pom as the conglomerate of three
files: pom.xml + pom.properties  + maven.xml (can be named differently)
and deploy to remote repository a jar file containing those three files
inside. Somehow I dislike this idea but that's the only solution
I see which will allow to have a single file in remote repository if
project.properties  file will still exists.

Other thing which we must think of is how the project inheritance will work
and how does it relates to reactor. 
Maybe during reactor powered builds parsed poms (Project beans) should be
accessed via reactor and not from local repository.
I mean that if given project needs to access other project's pom (for
inheritance or transitive dependencies) and both referencing and referenced
project 
are being built by the same reactor maybe we don't have to use local
repository for accessing poms.


Michal

P.S

By mistake I sent a copy of this letter to private accout of Rafal...