Re: Customizing Maven

[Brett Porter <br...@apache.org>]

Hi John,

Sorry to top reply almost two months later, but I had this one  
flagged. Reading through this, I think the end solution might be too  
much. Exposing plexus internals to the maven users is not a great idea.

I'd go more with controlling via POM customisations. That way the POM  
continues to control all of the other facets you pointed out, but on  
a project per-project basis you can do things as specified. A good  
example is the versioning discussion. A lot of the same stuff applies.

The difficulty does come when loading it from the repository, as you  
can get chicken and egg scenarios, but this is a complication we need  
to deal with in the dependency handling for a variety of scenarios  
where customisation can be made.

This  use case was the intent of the build extensions I think. So,  
you'd add an extension for the new component so that Plexus can find  
it (eg a new wagon), then you configure the use of that via the pom  
(using a url prefix). So we'd follow the same pattern. It may be for  
the example you give below that adding the extension would be enough  
- it would be registered then the resolution would just behave that  
way for any project with the extension. There are some limitations to  
the build extensions right now but I think that's the way to go forward.

- Brett

On 24/10/2006, at 10:27 AM, John Casey wrote:

> Hi all,
>
> I wanted to start talking about a new feature for Maven 2.1 that I  
> think
> will prove to be very powerful. I'd like Maven 2.1 to allow  
> customization of
> the components used in any particular role of the build. it would  
> allow
> developers to specify which ArtifactResolver implementation(s) they  
> wanted
> to use when building their project, for example.
>
> So, if you were building Eclipse applications, you might have a  
> stack of
> resolvers that implemented the following artifact resolution strategy:
>
> 1. Check the Maven local repository
> 2. Check the local Eclipse instance for a matching installed plugin
> 3. Check the Maven remote repositories specified in the project
> 4. Check the Eclipse update-sites specified in the project
> 5. Fail
>
> As another concrete example, custom components could be used to build
> MavenProject instances for a multimodule build directly from Eclipse
> .project and .classpath files by swapping in an alternative
> MavenProjectBuilder. Or, by swapping in a MavenProjectBuilder  
> instance that
> allowed stacking similar to the above resolution example, you could:
>
> 1. Try building from a POM
> 2. Try building from Eclipse .project/.classpath
> 3. Try building from Netbeans project files
>
> etc. etc.
>
> I think it's important that projects are able to specify this sort of
> customization, and if so, that they are able to specify it in a  
> portable
> way. Having said that, per-project customization raises some sticky
> questions:
>
> * If you build a multimodule project, and two or more of those modules
> specify custom components, which one wins?
> * Do we provide a "clean" Maven environment for each project  
> building in a
> multimodule build instead of the above? This could be expensive.
> * When we resolve dependencies, do we detect and engage their own
> customizations when we're resolving transitive dependencies? What  
> about
> other aspects of the build that might allow customization?
>
> These are definitely hard problems to solve (and more importantly,  
> to solve
> intuitively). Nevertheless, I think we could make a start by  
> limiting the
> use of customizations in multimodule builds, in parent-child  
> hierarchies,
> and in terms of the types of customizations are allowed...at least
> initially. We already have a prototypical implementation of this in  
> Maven
> 2.0.4 by way of build extensions - the trouble is, they don't allow
> replacement of components which have a long lifecycle and are already
> initialized when the project instance is loaded. Determining when this
> limitation comes into effect can be pretty daunting and unpredictable,
> leaving the feature nearly useless except in simple cases.
>
> I've been thinking about it in the back of my head for a long time  
> now, and
> the best I've come up with - without modifying the POM syntax,  
> which may be
> necessary in the end - is to attach a plexus application.xml to the  
> project
> artifact when it's installed or deployed...then, lock down any  
> possibility
> for inconsistency by aggressively detecting multiple  
> application.xml files
> in a single build. Based on detection of duplicate application.xml  
> files, we
> could provide an option like we do for checksums: warn or fail. If  
> we warn,
> then we would ignore any but the first application.xml we encounter.
>
> One of the things that makes this so difficult is the same thing  
> that makes
> so much of Maven complex and difficult - the fact that we have to  
> analyze
> multiple layers/dimensions of influence whenever we talk about POMs or
> projects.
>
> 1. The current POM
> 2. The ancestry
> 3. The other POMs in the reactor
> 4. Dependency POMs
> 5. Plugin POMs
>
> It is complex to calculate the effects of component customization  
> when it
> could come from basically any of these POM/project sources, just  
> the same
> way it's complex to calculate the influence and activation of build
> profiles, for example. So, if we could generalize a pattern for  
> dealing with
> this sort of thing, or even better, implement some strategy for  
> factoring in
> their respective influences, that would be excellent as well.
>
>
> Does anyone have any thoughts on any of this?
>
> Cheers,
>
> John

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