Community
Participate
Working Groups
3.5M6 The director application should provide a "local" mode that only contacts the repository given on the command line for the IU to be installed. Context: Our build process uses the p2 director application to set-up the base build (against which we compile) and to install build artifacts in order to create a product build. Currently, these install tasks take a long time because the director application queries remote repositories (typically download.eclipse.org). I am not sure whether the queried repositories are - defined in the director application's installation - defined by features being installed, or - defined by the installation being installed into However, during build I clearly know that all I want is to install some artifacts from a given repository into a given installation. The "local" mode would do this without querying additional repositories.
I agree though would characterize this as "just use what I say" regardless of whether it is local or remote or ...
I'm not sure we need a special option for this. The current problem stems from the fact that the director 'remembers' things from it's own environment. It really shouldn't (see bug 268138) . Instead: If the director installs into a non-existing location, then there should be no other repositories involved other than the ones provided on the command line. If the director installs into an existing location, the director should use repositories known to this install + repositories provided on the command line. An option could be provided to disable/remove known repositories in a target, but I don't think that would be needed to solve Toms problem since when provisioning a product, you usually start empty.
I completely agree with comment 1. Fixing bug 268138 would already help a lot, but I would also need the option suggested in comment 2 to "to disable/remove known repositories in a target". My use case: I create a product based on the Eclipse Platform, which will contain pre-configured repositories for our own and possibly eclipse update sites. While building, I don't want to wait for these, as I know exactly what I am doing. Should we treat this bug report as request for such an option?
I thought we already did something here, see bug 241430
You're right, bug 241430 describes exactly my problem. The question is why I was seeing this with 3.5M5 and 3.5M6. Hm, it seems that my content.xml contained references to the repositories defined by features included in my project. Perhaps these references were resolved by the director...? I am now clearing out these repository references from the content.xml and the director seems to no longer go to the web. Please close as dup as you see fit.
In bug 241430 it says that the app removes the repositories after the install is complete. Should that really be the default behavior? I can understand that this is the case when they end up in the repository manager of the caller of the app, but if not, I would expect them to remain in the target until removed explicitly. I think that's also the behavior of the installer. Perhaps this behavior should be controlled by an option? -volatileRepositories or similar?
Andrew, What happens when a feature lists an update site? Are these sites contacted? Also, what about referenced sites? If you say install from http://example.com and nowhere else, what if example.com is actually a composite repo? Tom, this could be why you are still seeing other repos being contacted.
The code in the Director application is already performing the filtering required. In line 424 of the Application class it creates a ProvisioningContext object that will cause only the repositories listed on teh command line to be considered. Nothing more should be needed. Remembering or not previous repository should not come into consideration. Thomas could you please see if a regression has been introduced? Thx.
I would like to fix this bug by changing the current behavior of the new director app so that: 1. It uses all repositories that are active in the target profile. 2. Repositories used when installing are added to the target profile. 3. Options exists for repositories management: -listRepositories (-listArtifactRepositories -listMetadataRepositories) -disableRepository (-disableArtifactRepository -disableMetadataRepository) <repoURI> -enableRepository (-enableArtifactRepository -enableMetadataRepository) <repoURI> -dropRepository (-dropArtifactRepository -dropMetadataRepository) <repoURI> The syntax of the listing would be: A http://... (artifact repository specific URI) M http://... (meta-data repository specific URI) http://... (co-located repository) Regarding 'local mode'; I don't belive that is a director application concern. It has to be supported by P2 in general (you should be able to benefit from this in the IDE too).
do the various arg take a list of repo URLs?
(In reply to comment #10) > do the various arg take a list of repo URLs? > Yes, I think we need that to be consistent with the current options.
This sounds like a good direction. Not for 3.5.
*** Bug 280954 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > I would like to fix this bug by changing the current behavior of the new > director app so that: > > 1. It uses all repositories that are active in the target profile. > 2. Repositories used when installing are added to the target profile. > 3. Options exists for repositories management: > -listRepositories (-listArtifactRepositories -listMetadataRepositories) > -disableRepository (-disableArtifactRepository -disableMetadataRepository) > <repoURI> > -enableRepository (-enableArtifactRepository -enableMetadataRepository) > <repoURI> > -dropRepository (-dropArtifactRepository -dropMetadataRepository) <repoURI> > > The syntax of the listing would be: > A http://... (artifact repository specific URI) > M http://... (meta-data repository specific URI) > http://... (co-located repository) > > Regarding 'local mode'; I don't belive that is a director application concern. > It has to be supported by P2 in general (you should be able to benefit from > this in the IDE too). > Hi Thomas, In terms of the syntax of the listing, can I use file:/... to point to the local repository? since our installer installs our product from a temporary local repository, after installation we want to invoke p2 director with "-dropRepository" option to remove this temporary repository. thanks, Jack
(In reply to comment #14) > In terms of the syntax of the listing, can I use file:/... to point to the > local repository? Yes, I cannot see why not.
(In reply to comment #15) > (In reply to comment #14) > > In terms of the syntax of the listing, can I use file:/... to point to the > > local repository? > Yes, I cannot see why not. > Thanks for your confirmation. Do you have any plan to release the new director app? thanks, Jack
(In reply to comment #16) > Do you have any plan to release the new director app? > The new director app is released in 3.5. The old one is still there but deprecated. The support for repository management discussed in this bugzilla is of course not part of the that release. It has yet to be implemented.
(In reply to comment #17) > (In reply to comment #16) > > Do you have any plan to release the new director app? > > > The new director app is released in 3.5. The old one is still there but > deprecated. > > The support for repository management discussed in this bugzilla is of course > not part of the that release. It has yet to be implemented. > Thanks, waiting for the implementation of repository management Jack
Thomas, interested in addressing this for 3.6?
I can look at this but reading the bugzilla I think the requirements are a bit fuzzy. 1. What repositories should be considered when you do an install? a) Only the ones given at the command line. At least one must be given b) Only the ones given at the command line or, if none given, the remembered ones c) The ones given at the command line + the remembered ones If the answer is 1.a, then there's no point remembering anything. 2. Is the rest (all except #1) ok in comment 9 ?
Closing as wontfix for now.
