You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Brett Porter <br...@apache.org> on 2008/07/04 17:29:16 UTC

Re: MARTIFACT-25 was: releasing maven artifact 3.0 alpha 1

On 04/07/2008, at 3:40 AM, John Casey wrote:

> Not to distract from the higher-level discussion, but I'd like to  
> get into the nuts and bolts of MARTIFACT-25 a bit...in case someone  
> beats me to it.
>
> We introduced a properties file that tracks resolution attempts for  
> artifacts that weren't found on the remote repository, and I'd like  
> to see if we can reuse that file/concept/code to handle artifacts  
> that don't have accompanying POMs on the remote repo. It's a similar  
> concept, so the two should dovetail relatively well, and require  
> little code to accomplish the fix.

This makes sense to me. So continue to expand on the update check  
manager to handle this case?

The other alternative - which at one point we were doing - is to write  
out the stub POM into the local repository and retain that. It would  
simplify the code, but muddies the local repo content.

I believe these have the same net effect, in that the artifact is  
never resolved a second time. Is that correct?


>
>
> The way I see it, the biggest hurdle for this issue is creating a  
> [set of] good tests to circumscribe the issue and make sure it  
> doesn't regress later.

I don't think there's too many variations - the problem is only with  
missing POM files, right?

Cheers,
Brett


>
>
> My $0.02.
>
> -john
>
> Brett Porter wrote:
>> Hi all,
>>
>> As I indicated a couple of weeks back, moving towards a 2.1 alpha  
>> release, I was looking at releasing an alpha of maven-artifact.  
>> Brian was able to locate the issue he was referring to a couple of  
>> weeks back about re-resolving (now MARTIFACT-25), so I've postponed.
>>
>> Once that's fixed, I think there should be no reason not to proceed  
>> with a release based on the thread we had back then.
>>
>> Are there any other issues that anyone sees as blocking moving  
>> forward with a release?
>>
>> I've done all the testing I was planning to already. Oleg, did you  
>> want to take this release, or shall I go ahead after that issue is  
>> sorted?
>>
>> Cheers,
>> Brett
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> -- 
> John Casey
> Developer, PMC Member - Apache Maven (http://maven.apache.org)
> Blog: http://www.ejlife.net/blogs/buildchimp/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/


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


Re: MARTIFACT-25 was: releasing maven artifact 3.0 alpha 1

Posted by Brett Porter <br...@apache.org>.
On 05/07/2008, at 1:44 AM, Jason van Zyl wrote:

> Are you dropping new files into the local repository or integrating  
> this as part of the metadata? Do these files only work locally?

The current impl, from what I've seen of it, drops properties files  
into the local repository only, and doesn't alter the metadata files  
that should match the remote repository. My question to John was  
whether he was saying that was the best place to put it, or to simply  
write out a POM that matches the internally used stub model as we used  
to do.

>
>
> Also in the case of 2.1 we should also consider just not allowing  
> the state where there is no POM. Consider the artifact not complete  
> without a POM.

Since Igor, John and Brian felt this was serious enough to delay a  
release because it was slow, I don't think they'd be particularly  
happy with it failing instead :)

In principle I agree, but I think we need to do more to push this to  
happen such that it is unlikely to affect a large number of builds - I  
don't think that'd be the case today. More ominous deprecation  
warnings perhaps. The problem here may be that it is still not easy  
enough for non-M2 projects (both Maven 1 and Ant/other) to make their  
artifacts available to Maven repositories properly (as we've seen in  
some blogs very recently). But that's a separate discussion.

Cheers,
Brett

>
>
> On 4-Jul-08, at 11:29 AM, Brett Porter wrote:
>
>>
>> On 04/07/2008, at 3:40 AM, John Casey wrote:
>>
>>> Not to distract from the higher-level discussion, but I'd like to  
>>> get into the nuts and bolts of MARTIFACT-25 a bit...in case  
>>> someone beats me to it.
>>>
>>> We introduced a properties file that tracks resolution attempts  
>>> for artifacts that weren't found on the remote repository, and I'd  
>>> like to see if we can reuse that file/concept/code to handle  
>>> artifacts that don't have accompanying POMs on the remote repo.  
>>> It's a similar concept, so the two should dovetail relatively  
>>> well, and require little code to accomplish the fix.
>>
>> This makes sense to me. So continue to expand on the update check  
>> manager to handle this case?
>>
>> The other alternative - which at one point we were doing - is to  
>> write out the stub POM into the local repository and retain that.  
>> It would simplify the code, but muddies the local repo content.
>>
>> I believe these have the same net effect, in that the artifact is  
>> never resolved a second time. Is that correct?
>>
>>
>>>
>>>
>>> The way I see it, the biggest hurdle for this issue is creating a  
>>> [set of] good tests to circumscribe the issue and make sure it  
>>> doesn't regress later.
>>
>> I don't think there's too many variations - the problem is only  
>> with missing POM files, right?
>>
>> Cheers,
>> Brett
>>
>>
>>>
>>>
>>> My $0.02.
>>>
>>> -john
>>>
>>> Brett Porter wrote:
>>>> Hi all,
>>>>
>>>> As I indicated a couple of weeks back, moving towards a 2.1 alpha  
>>>> release, I was looking at releasing an alpha of maven-artifact.  
>>>> Brian was able to locate the issue he was referring to a couple  
>>>> of weeks back about re-resolving (now MARTIFACT-25), so I've  
>>>> postponed.
>>>>
>>>> Once that's fixed, I think there should be no reason not to  
>>>> proceed with a release based on the thread we had back then.
>>>>
>>>> Are there any other issues that anyone sees as blocking moving  
>>>> forward with a release?
>>>>
>>>> I've done all the testing I was planning to already. Oleg, did  
>>>> you want to take this release, or shall I go ahead after that  
>>>> issue is sorted?
>>>>
>>>> Cheers,
>>>> Brett
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> -- 
>>> John Casey
>>> Developer, PMC Member - Apache Maven (http://maven.apache.org)
>>> Blog: http://www.ejlife.net/blogs/buildchimp/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> You are never dedicated to something you have complete confidence in.
> No one is fanatically shouting that the sun is going to rise tomorrow.
> They know it is going to rise tomorrow. When people are fanatically
> dedicated to political or religious faiths or any other kind of
> dogmas or goals, it's always because these dogmas or
> goals are in doubt.
>
>  -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/


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


Re: MARTIFACT-25 was: releasing maven artifact 3.0 alpha 1

Posted by Jason van Zyl <ja...@maven.org>.
Are you dropping new files into the local repository or integrating  
this as part of the metadata? Do these files only work locally?

Also in the case of 2.1 we should also consider just not allowing the  
state where there is no POM. Consider the artifact not complete  
without a POM.

On 4-Jul-08, at 11:29 AM, Brett Porter wrote:

>
> On 04/07/2008, at 3:40 AM, John Casey wrote:
>
>> Not to distract from the higher-level discussion, but I'd like to  
>> get into the nuts and bolts of MARTIFACT-25 a bit...in case someone  
>> beats me to it.
>>
>> We introduced a properties file that tracks resolution attempts for  
>> artifacts that weren't found on the remote repository, and I'd like  
>> to see if we can reuse that file/concept/code to handle artifacts  
>> that don't have accompanying POMs on the remote repo. It's a  
>> similar concept, so the two should dovetail relatively well, and  
>> require little code to accomplish the fix.
>
> This makes sense to me. So continue to expand on the update check  
> manager to handle this case?
>
> The other alternative - which at one point we were doing - is to  
> write out the stub POM into the local repository and retain that. It  
> would simplify the code, but muddies the local repo content.
>
> I believe these have the same net effect, in that the artifact is  
> never resolved a second time. Is that correct?
>
>
>>
>>
>> The way I see it, the biggest hurdle for this issue is creating a  
>> [set of] good tests to circumscribe the issue and make sure it  
>> doesn't regress later.
>
> I don't think there's too many variations - the problem is only with  
> missing POM files, right?
>
> Cheers,
> Brett
>
>
>>
>>
>> My $0.02.
>>
>> -john
>>
>> Brett Porter wrote:
>>> Hi all,
>>>
>>> As I indicated a couple of weeks back, moving towards a 2.1 alpha  
>>> release, I was looking at releasing an alpha of maven-artifact.  
>>> Brian was able to locate the issue he was referring to a couple of  
>>> weeks back about re-resolving (now MARTIFACT-25), so I've postponed.
>>>
>>> Once that's fixed, I think there should be no reason not to  
>>> proceed with a release based on the thread we had back then.
>>>
>>> Are there any other issues that anyone sees as blocking moving  
>>> forward with a release?
>>>
>>> I've done all the testing I was planning to already. Oleg, did you  
>>> want to take this release, or shall I go ahead after that issue is  
>>> sorted?
>>>
>>> Cheers,
>>> Brett
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> -- 
>> John Casey
>> Developer, PMC Member - Apache Maven (http://maven.apache.org)
>> Blog: http://www.ejlife.net/blogs/buildchimp/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
----------------------------------------------------------

You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of
dogmas or goals, it's always because these dogmas or
goals are in doubt.

   -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance


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


Re: MARTIFACT-25 was: releasing maven artifact 3.0 alpha 1

Posted by Jason van Zyl <ja...@maven.org>.
Igor just found another problem, in the Wagon manager downloading  
things repeatedly. We're going to take a look at that.

On 7-Jul-08, at 1:08 PM, Brett Porter wrote:

> Hi Oleg,
>
> I think you are good to go now for the release. I've fixed the  
> additional issues that I'd found.
>
> I'm just running the integration tests again locally to confirm, but  
> I'd say go for it whenever you're ready. All the instructions are on  
> the site for setting up settings, signatures, etc. if you need it,  
> though I'm sure you have it covered :)
>
> Cheers,
> Brett
>
> On 07/07/2008, at 4:50 AM, Brett Porter wrote:
>
>>
>> On 05/07/2008, at 1:51 AM, Oleg Gusakov wrote:
>>
>>> John - are you looking into this? Need it resolved for MNG-3185
>>
>> I've done it in the way John was suggesting - it's not the perfect  
>> solution but it's the best one available I think.
>>
>> I stumbled upon an API regression that breaks one of servicemix's  
>> plugins in the process (MARTIFACT-27). I'm not going to make it to  
>> the end of this tennis match, so I'm going to bed for now :)
>>
>> If there aren't any other takers on this I can take a look  
>> tomorrow. I think it'd be worth running clirr on this too - but  
>> it'll require some fiddling since the artifact has changed and been  
>> merged.
>>
>> Cheers,
>> Brett
>>
>>>
>>>
>>> Thanks,
>>> Oleg
>>>
>>> Brett Porter wrote:
>>>>
>>>> On 04/07/2008, at 3:40 AM, John Casey wrote:
>>>>
>>>>> Not to distract from the higher-level discussion, but I'd like  
>>>>> to get into the nuts and bolts of MARTIFACT-25 a bit...in case  
>>>>> someone beats me to it.
>>>>>
>>>>> We introduced a properties file that tracks resolution attempts  
>>>>> for artifacts that weren't found on the remote repository, and  
>>>>> I'd like to see if we can reuse that file/concept/code to handle  
>>>>> artifacts that don't have accompanying POMs on the remote repo.  
>>>>> It's a similar concept, so the two should dovetail relatively  
>>>>> well, and require little code to accomplish the fix.
>>>>
>>>> This makes sense to me. So continue to expand on the update check  
>>>> manager to handle this case?
>>>>
>>>> The other alternative - which at one point we were doing - is to  
>>>> write out the stub POM into the local repository and retain that.  
>>>> It would simplify the code, but muddies the local repo content.
>>>>
>>>> I believe these have the same net effect, in that the artifact is  
>>>> never resolved a second time. Is that correct?
>>>>
>>>>
>>>>>
>>>>>
>>>>> The way I see it, the biggest hurdle for this issue is creating  
>>>>> a [set of] good tests to circumscribe the issue and make sure it  
>>>>> doesn't regress later.
>>>>
>>>> I don't think there's too many variations - the problem is only  
>>>> with missing POM files, right?
>>>>
>>>> Cheers,
>>>> Brett
>>>>
>>>>
>>>>>
>>>>>
>>>>> My $0.02.
>>>>>
>>>>> -john
>>>>>
>>>>> Brett Porter wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> As I indicated a couple of weeks back, moving towards a 2.1  
>>>>>> alpha release, I was looking at releasing an alpha of maven- 
>>>>>> artifact. Brian was able to locate the issue he was referring  
>>>>>> to a couple of weeks back about re-resolving (now  
>>>>>> MARTIFACT-25), so I've postponed.
>>>>>>
>>>>>> Once that's fixed, I think there should be no reason not to  
>>>>>> proceed with a release based on the thread we had back then.
>>>>>>
>>>>>> Are there any other issues that anyone sees as blocking moving  
>>>>>> forward with a release?
>>>>>>
>>>>>> I've done all the testing I was planning to already. Oleg, did  
>>>>>> you want to take this release, or shall I go ahead after that  
>>>>>> issue is sorted?
>>>>>>
>>>>>> Cheers,
>>>>>> Brett
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>> -- 
>>>>> John Casey
>>>>> Developer, PMC Member - Apache Maven (http://maven.apache.org)
>>>>> Blog: http://www.ejlife.net/blogs/buildchimp/
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> -- 
>>>> Brett Porter
>>>> brett@apache.org
>>>> http://blogs.exist.com/bporter/
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
----------------------------------------------------------

Simplex sigillum veri. (Simplicity is the seal of truth.)


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


Re: MARTIFACT-25 was: releasing maven artifact 3.0 alpha 1

Posted by Brett Porter <br...@apache.org>.
On 08/07/2008, at 3:28 AM, Igor Fedorenko wrote:

> Brett,
>
> Out of curiosity. It seems that your fix for MARTIFACT-25 only  
> caches missing pom.xml lookup. Where is the logic that will prevent  
> maven from repeatedly hitting remote repositories for actual  
> artifacts?

I'd looked at the linked issues which referred to servicemix and  
missing POMs, and I thought that was what John was referring to as well.

I hadn't originally thought of the case of optional dependencies  
possibly not being resolvable - that's not what I meant for optional  
to mean :) Regardless, they should only be requested once in a  
resolution cycle for artifacts.

So I'm not quite sure how you're getting this. Can you reopen the  
issue, and attach a test project that illustrates multiple resolution  
failures?

At this point, I don't believe that caching this in the artifact  
resolver is the right place. The simple potential for failure such as  
the following concerns me:
- request a:1.1 (404)
- deploy a:1.1
- request a:1.1 (fails, despite being present)
Even doing this for POMs is somewhat questionable, but I figured an  
acceptable trade-off given the common existence of artifacts without  
POMs vs the likelihood of this happening (and ease of correcting it  
with -U).

HTH,
Brett

>
>
> Brett Porter wrote:
>> Hi Oleg,
>> I think you are good to go now for the release. I've fixed the  
>> additional issues that I'd found.
>> I'm just running the integration tests again locally to confirm,  
>> but I'd say go for it whenever you're ready. All the instructions  
>> are on the site for setting up settings, signatures, etc. if you  
>> need it, though I'm sure you have it covered :)
>> Cheers,
>> Brett
>> On 07/07/2008, at 4:50 AM, Brett Porter wrote:
>>>
>>> On 05/07/2008, at 1:51 AM, Oleg Gusakov wrote:
>>>
>>>> John - are you looking into this? Need it resolved for MNG-3185
>>>
>>> I've done it in the way John was suggesting - it's not the perfect  
>>> solution but it's the best one available I think.
>>>
>>> I stumbled upon an API regression that breaks one of servicemix's  
>>> plugins in the process (MARTIFACT-27). I'm not going to make it to  
>>> the end of this tennis match, so I'm going to bed for now :)
>>>
>>> If there aren't any other takers on this I can take a look  
>>> tomorrow. I think it'd be worth running clirr on this too - but  
>>> it'll require some fiddling since the artifact has changed and  
>>> been merged.
>>>
>>> Cheers,
>>> Brett
>>>
>>>>
>>>>
>>>> Thanks,
>>>> Oleg
>>>>
>>>> Brett Porter wrote:
>>>>>
>>>>> On 04/07/2008, at 3:40 AM, John Casey wrote:
>>>>>
>>>>>> Not to distract from the higher-level discussion, but I'd like  
>>>>>> to get into the nuts and bolts of MARTIFACT-25 a bit...in case  
>>>>>> someone beats me to it.
>>>>>>
>>>>>> We introduced a properties file that tracks resolution attempts  
>>>>>> for artifacts that weren't found on the remote repository, and  
>>>>>> I'd like to see if we can reuse that file/concept/code to  
>>>>>> handle artifacts that don't have accompanying POMs on the  
>>>>>> remote repo. It's a similar concept, so the two should dovetail  
>>>>>> relatively well, and require little code to accomplish the fix.
>>>>>
>>>>> This makes sense to me. So continue to expand on the update  
>>>>> check manager to handle this case?
>>>>>
>>>>> The other alternative - which at one point we were doing - is to  
>>>>> write out the stub POM into the local repository and retain  
>>>>> that. It would simplify the code, but muddies the local repo  
>>>>> content.
>>>>>
>>>>> I believe these have the same net effect, in that the artifact  
>>>>> is never resolved a second time. Is that correct?
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> The way I see it, the biggest hurdle for this issue is creating  
>>>>>> a [set of] good tests to circumscribe the issue and make sure  
>>>>>> it doesn't regress later.
>>>>>
>>>>> I don't think there's too many variations - the problem is only  
>>>>> with missing POM files, right?
>>>>>
>>>>> Cheers,
>>>>> Brett
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> My $0.02.
>>>>>>
>>>>>> -john
>>>>>>
>>>>>> Brett Porter wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> As I indicated a couple of weeks back, moving towards a 2.1  
>>>>>>> alpha release, I was looking at releasing an alpha of maven- 
>>>>>>> artifact. Brian was able to locate the issue he was referring  
>>>>>>> to a couple of weeks back about re-resolving (now  
>>>>>>> MARTIFACT-25), so I've postponed.
>>>>>>>
>>>>>>> Once that's fixed, I think there should be no reason not to  
>>>>>>> proceed with a release based on the thread we had back then.
>>>>>>>
>>>>>>> Are there any other issues that anyone sees as blocking moving  
>>>>>>> forward with a release?
>>>>>>>
>>>>>>> I've done all the testing I was planning to already. Oleg, did  
>>>>>>> you want to take this release, or shall I go ahead after that  
>>>>>>> issue is sorted?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Brett
>>>>>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/


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


Re: MARTIFACT-25 was: releasing maven artifact 3.0 alpha 1

Posted by Igor Fedorenko <ig...@ifedorenko.com>.
Brett,

Out of curiosity. It seems that your fix for MARTIFACT-25 only caches 
missing pom.xml lookup. Where is the logic that will prevent maven from 
repeatedly hitting remote repositories for actual artifacts?

Brett Porter wrote:
> Hi Oleg,
> 
> I think you are good to go now for the release. I've fixed the 
> additional issues that I'd found.
> 
> I'm just running the integration tests again locally to confirm, but I'd 
> say go for it whenever you're ready. All the instructions are on the 
> site for setting up settings, signatures, etc. if you need it, though 
> I'm sure you have it covered :)
> 
> Cheers,
> Brett
> 
> On 07/07/2008, at 4:50 AM, Brett Porter wrote:
> 
>>
>> On 05/07/2008, at 1:51 AM, Oleg Gusakov wrote:
>>
>>> John - are you looking into this? Need it resolved for MNG-3185
>>
>> I've done it in the way John was suggesting - it's not the perfect 
>> solution but it's the best one available I think.
>>
>> I stumbled upon an API regression that breaks one of servicemix's 
>> plugins in the process (MARTIFACT-27). I'm not going to make it to the 
>> end of this tennis match, so I'm going to bed for now :)
>>
>> If there aren't any other takers on this I can take a look tomorrow. I 
>> think it'd be worth running clirr on this too - but it'll require some 
>> fiddling since the artifact has changed and been merged.
>>
>> Cheers,
>> Brett
>>
>>>
>>>
>>> Thanks,
>>> Oleg
>>>
>>> Brett Porter wrote:
>>>>
>>>> On 04/07/2008, at 3:40 AM, John Casey wrote:
>>>>
>>>>> Not to distract from the higher-level discussion, but I'd like to 
>>>>> get into the nuts and bolts of MARTIFACT-25 a bit...in case someone 
>>>>> beats me to it.
>>>>>
>>>>> We introduced a properties file that tracks resolution attempts for 
>>>>> artifacts that weren't found on the remote repository, and I'd like 
>>>>> to see if we can reuse that file/concept/code to handle artifacts 
>>>>> that don't have accompanying POMs on the remote repo. It's a 
>>>>> similar concept, so the two should dovetail relatively well, and 
>>>>> require little code to accomplish the fix.
>>>>
>>>> This makes sense to me. So continue to expand on the update check 
>>>> manager to handle this case?
>>>>
>>>> The other alternative - which at one point we were doing - is to 
>>>> write out the stub POM into the local repository and retain that. It 
>>>> would simplify the code, but muddies the local repo content.
>>>>
>>>> I believe these have the same net effect, in that the artifact is 
>>>> never resolved a second time. Is that correct?
>>>>
>>>>
>>>>>
>>>>>
>>>>> The way I see it, the biggest hurdle for this issue is creating a 
>>>>> [set of] good tests to circumscribe the issue and make sure it 
>>>>> doesn't regress later.
>>>>
>>>> I don't think there's too many variations - the problem is only with 
>>>> missing POM files, right?
>>>>
>>>> Cheers,
>>>> Brett
>>>>
>>>>
>>>>>
>>>>>
>>>>> My $0.02.
>>>>>
>>>>> -john
>>>>>
>>>>> Brett Porter wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> As I indicated a couple of weeks back, moving towards a 2.1 alpha 
>>>>>> release, I was looking at releasing an alpha of maven-artifact. 
>>>>>> Brian was able to locate the issue he was referring to a couple of 
>>>>>> weeks back about re-resolving (now MARTIFACT-25), so I've postponed.
>>>>>>
>>>>>> Once that's fixed, I think there should be no reason not to 
>>>>>> proceed with a release based on the thread we had back then.
>>>>>>
>>>>>> Are there any other issues that anyone sees as blocking moving 
>>>>>> forward with a release?
>>>>>>
>>>>>> I've done all the testing I was planning to already. Oleg, did you 
>>>>>> want to take this release, or shall I go ahead after that issue is 
>>>>>> sorted?
>>>>>>
>>>>>> Cheers,
>>>>>> Brett
>>>>>>


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


Re: MARTIFACT-25 was: releasing maven artifact 3.0 alpha 1

Posted by Brett Porter <br...@apache.org>.
Hi Oleg,

I think you are good to go now for the release. I've fixed the  
additional issues that I'd found.

I'm just running the integration tests again locally to confirm, but  
I'd say go for it whenever you're ready. All the instructions are on  
the site for setting up settings, signatures, etc. if you need it,  
though I'm sure you have it covered :)

Cheers,
Brett

On 07/07/2008, at 4:50 AM, Brett Porter wrote:

>
> On 05/07/2008, at 1:51 AM, Oleg Gusakov wrote:
>
>> John - are you looking into this? Need it resolved for MNG-3185
>
> I've done it in the way John was suggesting - it's not the perfect  
> solution but it's the best one available I think.
>
> I stumbled upon an API regression that breaks one of servicemix's  
> plugins in the process (MARTIFACT-27). I'm not going to make it to  
> the end of this tennis match, so I'm going to bed for now :)
>
> If there aren't any other takers on this I can take a look tomorrow.  
> I think it'd be worth running clirr on this too - but it'll require  
> some fiddling since the artifact has changed and been merged.
>
> Cheers,
> Brett
>
>>
>>
>> Thanks,
>> Oleg
>>
>> Brett Porter wrote:
>>>
>>> On 04/07/2008, at 3:40 AM, John Casey wrote:
>>>
>>>> Not to distract from the higher-level discussion, but I'd like to  
>>>> get into the nuts and bolts of MARTIFACT-25 a bit...in case  
>>>> someone beats me to it.
>>>>
>>>> We introduced a properties file that tracks resolution attempts  
>>>> for artifacts that weren't found on the remote repository, and  
>>>> I'd like to see if we can reuse that file/concept/code to handle  
>>>> artifacts that don't have accompanying POMs on the remote repo.  
>>>> It's a similar concept, so the two should dovetail relatively  
>>>> well, and require little code to accomplish the fix.
>>>
>>> This makes sense to me. So continue to expand on the update check  
>>> manager to handle this case?
>>>
>>> The other alternative - which at one point we were doing - is to  
>>> write out the stub POM into the local repository and retain that.  
>>> It would simplify the code, but muddies the local repo content.
>>>
>>> I believe these have the same net effect, in that the artifact is  
>>> never resolved a second time. Is that correct?
>>>
>>>
>>>>
>>>>
>>>> The way I see it, the biggest hurdle for this issue is creating a  
>>>> [set of] good tests to circumscribe the issue and make sure it  
>>>> doesn't regress later.
>>>
>>> I don't think there's too many variations - the problem is only  
>>> with missing POM files, right?
>>>
>>> Cheers,
>>> Brett
>>>
>>>
>>>>
>>>>
>>>> My $0.02.
>>>>
>>>> -john
>>>>
>>>> Brett Porter wrote:
>>>>> Hi all,
>>>>>
>>>>> As I indicated a couple of weeks back, moving towards a 2.1  
>>>>> alpha release, I was looking at releasing an alpha of maven- 
>>>>> artifact. Brian was able to locate the issue he was referring to  
>>>>> a couple of weeks back about re-resolving (now MARTIFACT-25), so  
>>>>> I've postponed.
>>>>>
>>>>> Once that's fixed, I think there should be no reason not to  
>>>>> proceed with a release based on the thread we had back then.
>>>>>
>>>>> Are there any other issues that anyone sees as blocking moving  
>>>>> forward with a release?
>>>>>
>>>>> I've done all the testing I was planning to already. Oleg, did  
>>>>> you want to take this release, or shall I go ahead after that  
>>>>> issue is sorted?
>>>>>
>>>>> Cheers,
>>>>> Brett
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> -- 
>>>> John Casey
>>>> Developer, PMC Member - Apache Maven (http://maven.apache.org)
>>>> Blog: http://www.ejlife.net/blogs/buildchimp/
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> -- 
>>> Brett Porter
>>> brett@apache.org
>>> http://blogs.exist.com/bporter/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/


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


Re: MARTIFACT-25 was: releasing maven artifact 3.0 alpha 1

Posted by Brett Porter <br...@apache.org>.
On 05/07/2008, at 1:51 AM, Oleg Gusakov wrote:

> John - are you looking into this? Need it resolved for MNG-3185

I've done it in the way John was suggesting - it's not the perfect  
solution but it's the best one available I think.

I stumbled upon an API regression that breaks one of servicemix's  
plugins in the process (MARTIFACT-27). I'm not going to make it to the  
end of this tennis match, so I'm going to bed for now :)

If there aren't any other takers on this I can take a look tomorrow. I  
think it'd be worth running clirr on this too - but it'll require some  
fiddling since the artifact has changed and been merged.

Cheers,
Brett

>
>
> Thanks,
> Oleg
>
> Brett Porter wrote:
>>
>> On 04/07/2008, at 3:40 AM, John Casey wrote:
>>
>>> Not to distract from the higher-level discussion, but I'd like to  
>>> get into the nuts and bolts of MARTIFACT-25 a bit...in case  
>>> someone beats me to it.
>>>
>>> We introduced a properties file that tracks resolution attempts  
>>> for artifacts that weren't found on the remote repository, and I'd  
>>> like to see if we can reuse that file/concept/code to handle  
>>> artifacts that don't have accompanying POMs on the remote repo.  
>>> It's a similar concept, so the two should dovetail relatively  
>>> well, and require little code to accomplish the fix.
>>
>> This makes sense to me. So continue to expand on the update check  
>> manager to handle this case?
>>
>> The other alternative - which at one point we were doing - is to  
>> write out the stub POM into the local repository and retain that.  
>> It would simplify the code, but muddies the local repo content.
>>
>> I believe these have the same net effect, in that the artifact is  
>> never resolved a second time. Is that correct?
>>
>>
>>>
>>>
>>> The way I see it, the biggest hurdle for this issue is creating a  
>>> [set of] good tests to circumscribe the issue and make sure it  
>>> doesn't regress later.
>>
>> I don't think there's too many variations - the problem is only  
>> with missing POM files, right?
>>
>> Cheers,
>> Brett
>>
>>
>>>
>>>
>>> My $0.02.
>>>
>>> -john
>>>
>>> Brett Porter wrote:
>>>> Hi all,
>>>>
>>>> As I indicated a couple of weeks back, moving towards a 2.1 alpha  
>>>> release, I was looking at releasing an alpha of maven-artifact.  
>>>> Brian was able to locate the issue he was referring to a couple  
>>>> of weeks back about re-resolving (now MARTIFACT-25), so I've  
>>>> postponed.
>>>>
>>>> Once that's fixed, I think there should be no reason not to  
>>>> proceed with a release based on the thread we had back then.
>>>>
>>>> Are there any other issues that anyone sees as blocking moving  
>>>> forward with a release?
>>>>
>>>> I've done all the testing I was planning to already. Oleg, did  
>>>> you want to take this release, or shall I go ahead after that  
>>>> issue is sorted?
>>>>
>>>> Cheers,
>>>> Brett
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> -- 
>>> John Casey
>>> Developer, PMC Member - Apache Maven (http://maven.apache.org)
>>> Blog: http://www.ejlife.net/blogs/buildchimp/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> -- 
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/


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


Re: MARTIFACT-25 was: releasing maven artifact 3.0 alpha 1

Posted by Oleg Gusakov <ol...@gmail.com>.
John - are you looking into this? Need it resolved for MNG-3185

Thanks,
Oleg

Brett Porter wrote:
>
> On 04/07/2008, at 3:40 AM, John Casey wrote:
>
>> Not to distract from the higher-level discussion, but I'd like to get 
>> into the nuts and bolts of MARTIFACT-25 a bit...in case someone beats 
>> me to it.
>>
>> We introduced a properties file that tracks resolution attempts for 
>> artifacts that weren't found on the remote repository, and I'd like 
>> to see if we can reuse that file/concept/code to handle artifacts 
>> that don't have accompanying POMs on the remote repo. It's a similar 
>> concept, so the two should dovetail relatively well, and require 
>> little code to accomplish the fix.
>
> This makes sense to me. So continue to expand on the update check 
> manager to handle this case?
>
> The other alternative - which at one point we were doing - is to write 
> out the stub POM into the local repository and retain that. It would 
> simplify the code, but muddies the local repo content.
>
> I believe these have the same net effect, in that the artifact is 
> never resolved a second time. Is that correct?
>
>
>>
>>
>> The way I see it, the biggest hurdle for this issue is creating a 
>> [set of] good tests to circumscribe the issue and make sure it 
>> doesn't regress later.
>
> I don't think there's too many variations - the problem is only with 
> missing POM files, right?
>
> Cheers,
> Brett
>
>
>>
>>
>> My $0.02.
>>
>> -john
>>
>> Brett Porter wrote:
>>> Hi all,
>>>
>>> As I indicated a couple of weeks back, moving towards a 2.1 alpha 
>>> release, I was looking at releasing an alpha of maven-artifact. 
>>> Brian was able to locate the issue he was referring to a couple of 
>>> weeks back about re-resolving (now MARTIFACT-25), so I've postponed.
>>>
>>> Once that's fixed, I think there should be no reason not to proceed 
>>> with a release based on the thread we had back then.
>>>
>>> Are there any other issues that anyone sees as blocking moving 
>>> forward with a release?
>>>
>>> I've done all the testing I was planning to already. Oleg, did you 
>>> want to take this release, or shall I go ahead after that issue is 
>>> sorted?
>>>
>>> Cheers,
>>> Brett
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> -- 
>> John Casey
>> Developer, PMC Member - Apache Maven (http://maven.apache.org)
>> Blog: http://www.ejlife.net/blogs/buildchimp/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> -- 
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

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