Eclipse p2's artifacts.xml/jar and hard-coded paths

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From irc the other day:
  <akurtakov_> artifact.xml is simply unusable because it has paths from
build time in it
  <akurtakov_> and the repo is invalid with only content.xml

I can see that artifacts.xml does contain some build-time filesystem
paths, but I don't really understand the problem, since Eclipse doesn't
seem to care too much.

Are there any old discussions about this that I should be reading,
instead of bothering the list?

I'm interested because I have found that suitably massaged
(optional+non-greedy) P2 metadata can help Eclipse to cope with the
Babel langpacks and the fragment plugins they contain:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=256430

So I would like to include the P2 metadata with eclipse-nls (RPMs for
the Babel langpacks).

1. Does Eclipse in fact care about these paths?  In which case, why does
P2 work (occasionally!) on my machine, with completely different
filesystem paths?
2. Is there a Fedora packaging rule that says build-time paths are not
allowed into packages, perhaps because they make it impossible to
reproduce byte-identical builds?
3. Assuming one of the above is true: Could we sed-patch the
artifacts.xml file to remove/normalise the build path?
4. Alternatively, would it help if we were to use the P2 director to
install eclipse-nls from a local update site, thus installing the
features the P2 way, rather than using dropins?


Thanks

Sean

-- 
Sean Flanigan

Senior Software Engineer
Engineering - Internationalisation
Red Hat

Attachment: signature.asc
Description: OpenPGP digital signature

--
fedora-devel-java-list mailing list
fedora-devel-java-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list

[Index of Archives]     [Red Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux