Re: [cross-project-issues-dev] "No location for packed" messages and RC3

[David M Williams <david_williams@xxxxxxxxxx>]

Thanks, Hugues, very helpful. 

The latest build did fail for the same
reasons (except I did disabled SOA-SCA contribution for their previously
mentioned problems). 

I've heard from MTJ (Gorkem) and they'd
tried patching artifacts.xml in the event of a respin. 

I suggest the EGIT/JGIT team do the
same. 

So that leaves SOA-SCA to fix up their
contribution, and remove the enabled="false" attribute (which
would trigger a rebuild for the RC3 repository) if they are able to (and
if they need to, and want to). 

In the meantime, I have promoted what
we have to /releases/staging. I'm not very confident in the repos quality,
since we are basically promoting a "failed build". We we don't
do that often enough to know what it means (I don't think we ever have,
before?). But, if we are lucky, it will have enough content and work well
enough to build EPP packages? (But, Markus, at the first sign of trouble,
I'd just blame it on the repo and we might have to wait for a green build?).


So, please consider the repo "frozen",
until we hear from the SOA-SCA team if they can/want/need to contribute
to RC3? Are any of those SOA-SCA features used in EPP Packages? (I think
not ... but, that's just off the top of my head ... I could easily have
forgotten). 

And, remember, "frozen" also
means to freeze your project-specific repos that a respin might need to
pull back in. 

@Igor, I hope you can reenable pack200
for RC4? Its usually not a strong position to say "we're not going
to do the requirements because of builder limitations" ... 
none of us would ever release anything
if we all did that :) 

Much thanks to everyone for suffering
through this churn, 







From:      
 Hugues Malphettes <hmalphettes@xxxxxxxxxxx>
To:      
 Cross project issues
<cross-project-issues-dev@xxxxxxxxxxx>
Date:      
 06/01/2011 10:21 PM
Subject:    
   Re: [cross-project-issues-dev]
"No location for packed" messages
Sent by:    
   cross-project-issues-dev-bounces@xxxxxxxxxxx

---

This bug is a duplicate of that bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=347591

There is also this bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=347594

Jesse and Dave are reviewing the patch.
If you are in a hurry, I made a 1.0.1.2-SNAPSHOT build of the signing
plugin with this patch, deployed it on

     <pluginRepository>
       <id>intalio-dash-signing-plugin</id>
       <url>http://intalio.org/public/maven2</url>
       <snapshots>
        <enabled>true</enabled>
       </snapshots>
       <releases>
        <enabled>true</enabled>
       </releases>
     </pluginRepository>

Everyone is welcome to use it.
The resulting build for jetty is now contributed to 3.7-RC3 and the
aggregator is fine with it.

You can also update the artifacts.xml by hand.

Cheers,
Hugues


On Thu, Jun 2, 2011 at 10:09 AM, Igor Fedorenko <ifedorenko@xxxxxxxxxxxx>
wrote:
> Pascal and I looked at this last week and I opened 347667 [1] based
on
> our findings. In short, singing maven plugin adds packed artifacts
but
> does not update repository mapping rules, so p2 does not know how
to
> find the packed files.
>
> I plan to implement better/proper signing support in Tycho shortly
after
> Indigo is shipped, so we decided to disable pack200 for m2e for now.
>
>
> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=347667
>
> --
> Regards,
> Igor
>
> On 11-06-01 9:53 PM, David M Williams wrote:
>>
>> Bot MJT and EGIT are failing to aggregate due to failing to find
packed
>> artifacts. For example,
>>
>> org.eclipse.core.runtime.CoreException: Unable to mirror artifact
>> osgi.bundle,org.eclipse.egit.core,1.0.0.201106011211-rc3 from
repository
>> http://download.eclipse.org/egit/updates-1.0:No
location for packed:
>> osgi.bundle,org.eclipse.egit.core,1.0.0.201106011211-rc3.
>>
>> I'm not sure if these teams forgot something ... or some build
utility
>> changed something ... but, thought it worth reminding everyone
that the
>> aggregator has stricter criteria for "correctness" than
simply
>> "installing with p2". I think this is a case of that.
If p2 can not find
>> a packed artifacts, in continues merrily on trying the jar instead.
The
>> b3 aggregator, though, assumes that if your content metadata says
there
>> is a packed artifact there, then it is an error if there is no
packed
>> artifact there.
>> After the fact, some cases like this can be fixed by running
>> p2.process.artifacts on the repo. Then longer term, figure out
why the
>> packed artifacts are not being created?
>>
>> Also, I'm going to try again without soa-sca contribution ...
I know
>> they have (or, are) trying to fix things ... but, since has failed
>> several times, I'll try without.
>>
>> Thanks,
>>
>>
>>
>> _______________________________________________
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev