https://bugs.eclipse.org/bugs/show_bug.cgi?id=357130
this deals with this issue somewhat, at least there are supposed to be
some p2 tooling for this
if your working on the tooling for tycho to be able to do this then I
can hold off on this sort of integration for the hackish signing
plugin projec
Thanks, I now feel that I have the picture.
On Thu, Sep 8, 2011 at 1:45 PM, Igor Fedorenko wrote:
> The whole point of this discussion is to find a good way to eliminate
> artifacts.xml "fixup" step at the end.
>
> Also note that Eclipse.org is not the only
> organization that needs to produce p2
The whole point of this discussion is to find a good way to eliminate
artifacts.xml "fixup" step at the end.
Also note that Eclipse.org is not the only
organization that needs to produce p2 repositories with signed jars, so
sign step has to be pluggable to work with at least generic
jarsigner-plu
and the actual process is
pack
sign (currently can only be done on build.eclipse.org)
repack
then fix checksums and insert some extra metadata in the
artifact.xml/artifact.jar file
cheers,
jesse
--
jesse mcconnell
jesse.mcconn...@gmail.com
On Thu, Sep 8, 2011 at 12:30, Igor Fedorenko wrote:
artifacts.xml contains md5 checksums of the artifact files. Signing or
pack200 conditioning changes file contents and thus invalidates the
checksums. In other words, artifacts.xml can only be generated after
final signed/packed version of the files has been created.
--
Regards,
Igor
On 11-09-08
Igor,
> 1. neither pack nor sign
> package jar
> generate p2 metadata
I'm looking at a P2 site from Tycho, and the only P2 stuff I see is
the XML files at the top level. Is there anything that actually goes
into the jar?
--benson
On Mon, Sep 5, 2011 at 2:32 PM, Igor Fedorenko wrote:
> Introducing tycho-specific lifecycles is not practically feasible.
That's not what I was suggesting. I was suggesting the use of a
convention on execution id's as a way of allowing order control.
I also was musing about signed-eclipse-plugi
Introducing tycho-specific lifecycles is not practically feasible. All
lifecycle phase names must be globally unit across all lifecycles, which
means we'd have to invent "tycho-compile", "tycho-validate" and so on.
This means we'd have to explain these new names to Tycho users. Many
standard maven
On Sun, Sep 4, 2011 at 10:48 PM, Igor Fedorenko wrote:
> I agree that adding new phase (or phases) does not look like a scalable
> solution. For example, in addition to signing,
Tycho could add more lifecycles. Since those are selected by
'packaging', however, and not variable by profile, it woul
I agree that adding new phase (or phases) does not look like a scalable
solution. For example, in addition to signing, Eclipse projects are
encouraged to pack200 their artifacts, but neither signing nor pack200
are mandatory. So we need to be able add both sign and pack200 steps to
the lifecycle a
On 05/09/2011, at 10:37 AM, Benson Margulies wrote:
> On Sun, Sep 4, 2011 at 7:10 PM, Brett Porter wrote:
>>
>> On 05/09/2011, at 3:49 AM, Benson Margulies wrote:
>>
>>> I'm trying to be slightly helpful to the Tycho project. They have a
>>> problem: they need to define a lifecycle that adds a
On Sun, Sep 4, 2011 at 7:10 PM, Brett Porter wrote:
>
> On 05/09/2011, at 3:49 AM, Benson Margulies wrote:
>
>> I'm trying to be slightly helpful to the Tycho project. They have a
>> problem: they need to define a lifecycle that adds a plugin to a phase
>> *not at the end* of the plugins in the st
On 05/09/2011, at 3:49 AM, Benson Margulies wrote:
> I'm trying to be slightly helpful to the Tycho project. They have a
> problem: they need to define a lifecycle that adds a plugin to a phase
> *not at the end* of the plugins in the standard lifecycle.
>
> Has anyone else thought about this?
I'm trying to be slightly helpful to the Tycho project. They have a
problem: they need to define a lifecycle that adds a plugin to a phase
*not at the end* of the plugins in the standard lifecycle.
Has anyone else thought about this?
---
14 matches
Mail list logo