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
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
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
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
Thanks, I now feel that I have the picture.
On Thu, Sep 8, 2011 at 1:45 PM, Igor Fedorenko i...@ifedorenko.com 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
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
On Sun, Sep 4, 2011 at 10:48 PM, Igor Fedorenko i...@ifedorenko.com 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
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 Mon, Sep 5, 2011 at 2:32 PM, Igor Fedorenko i...@ifedorenko.com 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
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?
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?
On Sun, Sep 4, 2011 at 7:10 PM, Brett Porter br...@apache.org 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
On 05/09/2011, at 10:37 AM, Benson Margulies wrote:
On Sun, Sep 4, 2011 at 7:10 PM, Brett Porter br...@apache.org 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
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
14 matches
Mail list logo
