Nacho G. Mac Dowell wrote:

> Brett Porter wrote:
>
>> I've already started planning to build this in to Maven 2.x. I haven't
>> thought it right through yet, but if it works out I'm thinking this
>> makes sense.
>>
>>  
>>
> Do you think this will go in the model or just the project? I mean,
> will we define the hierarchy in xml or via properties? I was thinking
> that as a transition, it would probably be better to just do it via a
> property that gives us the sub-pom's. This way only Project.java would
> have to be tackled. I can provide a patch for both cases, although it
> would probably be better to have some discussion before.

In Maven 2, the "model" refers to the Project Object Model (ie
project.xml). There is are no properties files - its all in the POM.

>>
> I wasn't sure if this proposal would be welcome, but still I would
> like to use it in my project. Maven expects a Project object for most
> of its work. If I was allowed to specify the implementation of the
> Project class I want to use it would not be a drawback if it wasn't
> welcome. I'd just use my own implementation of Project (that
> implements the IProject interface or whatever) and I'd have the
> functionality i like without needing to hack maven and jar it with my
> changes. This would give Maven much more flexibility.

I don't think you want an interface for the Project, I think you want an
interface for the project loader. They are separate and remain that way
I'm reluctant to expose that in Maven 1.x as things would start falling
apart. I'd expect you'd be able to do this in m2.

Regardless, I think you're on the right track and given enough thought
you can probably expect to see the multiple project feature turn up soon.

Thanks,
Brett

>
> Say you have a property maven.project.impl which if not specified
> defaults to org.apache.maven.project.Project. We'd need a default
> constructor and a method read(Reader in) (or whatever) in Project.
> We'd then need that getProject(...) from MavenUtils chooses the right
> implementation. I can provide a patch if requested.
>
>>  
>>
>>> After quite a big headache trying to implement this new behaviour, I
>>> found there are not too many places that should be changed.   
>>
>>
>> Right. The reactor and multiproject approach works for now, but it
>> certainly can be improved, and that is planned for the rewrite.
>>
>> - Brett
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>  
>>
> regards,
>
> Nacho
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to