Re: Maven 2.1.0 GA Plan

> I am OK with this.
>
> You may or may not have noticed but I created branch maven-2.1.x-
> MNG-624 last night. It contains the fix for MNG-624. I have created  
> integration tests but haven't committed them yet. I will soon.  
> Before committing these to the 2.1.x branch I'd really like folks to  
> try it out.
>
> This change will have a minor impact on existing projects. If you  
> don't specify the artifact's groupId or versionId (i.e. it is  
> inherited from the parent) then a new pom.xml should get created in  
> the target directory that has those fields filled in. That file will  
> be the one that is installed or deployed.
>
> I'm only trying to resolve the parent version. I could try to  
> resolve the parent groupId and artifactId and some of the problem  
> reports mention those but I just couldn't think of a reason why they  
> shouldn't be specified or why someone would want them in a variable.
>
> The version is obtained by
> 1. Resolving any variables provided via system properties (variables  
> from parents won't be found since the parent isn't known.
> 2. Looking in the file cache for the resolved parent project using  
> the relative location as the key.
> 3. Looking for the parent at the relative path on disk.
> a. The target directory at the relative path is inspected for a  
> modified pom.
> b. The project at the relative path is used.
> If at the end of this a resolved parent version is not located throw  
> an Exception. Do not try to recurse to further parents.
>
> You'll notice the comment about looking for the modified pom in the  
> target directory. As part of this fix the parent version, and the  
> project's artifactId, groupId and version are all interpolated. If  
> any of those fields were missing or had variables in them in the  
> original pom then the pom is modified and written to the target  
> directory. Thus, any pom that is installed or deployed will always  
> have these fields resolved.
>
> In looking through the plugins it looked to me that the Eclipse and  
> Invoker plugins are trying to locate the base directory by calling  
> project.getFile().getParentFile(). These will need to be changed to  
> project.getBasedir() since the location of the pom might now be in a  
> different place and project.getFile().getParentFile() might return  
> the target directory instead of the base directory.
>
> As we agreed Maven 2.1 will require Java 5. The pom has been changed  
> to reflect that and quite a bit of the new code uses it.
>
> Please test and provide feedback.
>
> Ralph
>
> John Casey wrote:
>> Hi everyone,
>>
>> So, it seems that we're all in agreement about the rough outline  
>> for 2.1.x and beyond. I've renamed the current RC branch to be  
>> 2.1.0-M1-RC to make this the first milestone toward some as-yet-
>> undetermined feature list for 2.1.0.
>>
>> So, let's talk about that feature list. From earlier comments, I've  
>> gathered that the following may be good targets to include for 2.1.0:
>>
>> - Dan's reactor changes
>> - Parallel downloads
>> - PGP stuff
>> - MNG-624 and related issues/feature enhancements (parent  
>> versioning, right?)
>>
>> What I don't know is what state of maturity each of these is in,  
>> and on what timeline they can be stabilized. Do the relevant  
>> developers have enough time to finish implementing, testing, and  
>> documenting each feature, so we could get a 2.1.0 GA out in, say 6  
>> weeks or so? Maybe a better approach would be to try for a new  
>> milestone release that contains the final result of each new  
>> feature (with latent parts of the rest, as we work on them), such  
>> that the 2.1.0 GA will contain all the new features in their  
>> complete forms, with any regressions identified fixed and  
>> incorporated?
>>
>> I haven't found the pertinent Confluence pages describing the above  
>> features yet...maybe they don't exist or maybe I haven't looked  
>> hard enough yet, but we'll need to collect the list somewhere that  
>> we can make it public going forward, and then publish that release  
>> plan URL on the Maven site.
>>
>> Are there other things that we can fit into this sort of timeframe?  
>> Is this too much? It's my strong preference that we try to cap this  
>> release cycle at two months, so I guess this means taking the list  
>> of "nearly there" features and determining whether we'll have the  
>> time to stabilize them for inclusion, given our current availability.
>>
>> Of course, once we settle the 2.1.0 release plan, we can start  
>> talking about what we're going to do for 2.2, 2.3, etc. As long as  
>> we keep things rolling, there's no reason anyone needs to feel  
>> overly rushed about getting a particular feature in a particular  
>> release...it should NOT be your only chance. :-)
>>
>> What does anyone else think?
>>
>> -john
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>