Re: [tycho-user] tycho 0.11.0 always downloading content.xml and artifac

["Sievers, Jan" <jan.sievers@xxxxxxx>]

I think the scenario of starting off by developing against a local eclipse installation and only later configuring the headless build to be machine-independent is rather common.

As proposed in [1], when we remove -Dtycho.targetPlatform, we should come up with a migration path which makes it easier for users to switch from local target platform to the p2-based resolver. An easy-to-use CLI of the FeatureAndBundlesPublisher mojo could be one option.
As Eric said, at the same time this could make it easier to evaluate 3rd party bundles not available in a p2 repo.

The protocol of the p2 URL used (http/file/...) is a different story IMHO and I don't think we should dictate not to use file URLs if p2 allows this.
Even if we think it's not a good practice, users may have reasons to do so. E.g. you don't want to pay the full price of getting your 3rd party bundles into p2 right from the start if you just want to play around/evaluate.

Regards,
Jan


[1] https://issues.sonatype.org/browse/TYCHO-527?focusedCommentId=121074&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_121074 

-----Original Message-----
From: tycho-user-bounces@xxxxxxxxxxx [mailto:tycho-user-bounces@xxxxxxxxxxx] On Behalf Of Eric Jain
Sent: Donnerstag, 5. Mai 2011 21:32
To: Tycho user list
Subject: Re: [tycho-user] tycho 0.11.0 always downloading content.xml and artifacts.xml from local p2 helios mirror

On Thu, May 5, 2011 at 06:54, Igor Fedorenko <ifedorenko@xxxxxxxxxxxx> wrote:
> Ultimately, we want to run Tycho builds without any local setup, i.e.
> any developer or CI system should be able to clone (or checkout) source
> code and immediately do "mvn clean install". Use of *remote* p2
> repositories is part of solution of this problem and existing
> -Dtycho.targetPlatform support makes implementation mode difficult.

Use of remote p2 repositories allows for a simple checkout and "mvn
clean install" -- as long as all the remote repositories are
accessible and not inside some intranet.

Use of local repositories allows for a simple checkout and "mvn clean
install" -- as long as the local repositories are part of the
checkout.

Having at least one local (p2, or even better, non-p2) repository
makes it trivial for a developer to test new third-party bundles (that
aren't already available from a maven or p2 repository). If only
remote repositories are allowed, it seems the developer would first
have to get that bundle deployed to one of the shared p2 repositories
(undesirable e.g. if you're evaluating several libraries and intend to
keep at most one), or else create a fake remote repository by setting
up a local web server, creating a temporary p2 repository for the new
bundles, and editing the target definition...

Seems quite tedious for someone who works on a project that uses a lot
of such third-party bundles and updates them often. But perhaps I am
missing something?
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tycho-user