[ANN] Artifactory 1.3.0-beta1
|
View:
New views
7 Messages
—
Rating Filter:
Alert me
|
 |
[ANN] Artifactory 1.3.0-beta1
by Yoav Landman
::
Rate this Message:
We are pleased to announce the availability of Artifactory 1.3.0-beta1.
MAJOR FEATURES AND CHANGES INTRODUCED IN THIS RELEASE ------------------------------------------------------ - Anonymous browsing support - Ability to nest virtual repositories - Drop n Run install: simply drop the Artifactory WAR file inside your servlet container to have all the defaults installed automatically under the user home directory - Seamless, robust upgrade path from previous versions (including rc's) of full system data - Incremental backup support: backups can be stored onto the same directory and be utilized by any file system based incremental backup utility - Storing unzipped backups by default for greater performance - Efficient storage: same artifacts are stored only once in the underlying storage, regardless of how many times they have been deployed - Full support for M2Eclipse indexes (Nexus indexes) for local and remote repositories (Artifactory will create one for its cached data if the remote repository does not support an index) - Many stability and speed improvements - The usual bug fixes The complete release notes are available here: http://www.jfrog.org/jira/browse/RTFACT/fixforversion/10240 FULLY UPGRADING FROM VERSION 1.2.2-RC0 THROUGH 1.2.5U1 ------------------------------------------------------- The provided artifactory-update-1.3.0-x.zip contains a bin folder with the artifactoryExport.sh and artifactoryExport.bat executable. You should run these to fully export your old Artifactory database to a format usable by the Full System Import feature in the Artifactory web UI. To run the export use: artifactoryExport.sh $ARTIFACTORY_HOME [oldArtifactoryVersion] \ [--config exportFolder] [--noconvert] The first parameter is mandatory (except when --config is passed) and should point to a copy of your old $ARTIFACTORY_HOME folder. If that folder also contains a webapps subfolder with the old Artifactory war file, the update manager will automatically determine the old version from it. If the update manager cannot determine a valid version an error message will appear with a list of valid versions and you'd need to manually specify the version of your old Artifactory as a second parameter to artifactoryExport.sh. Important information about the update manager: 1) Always work on a copy of the old $ARTIFACTORY_HOME folder (that, even though the export should be a read only process). 2) Running the update creates a tmpExport folder under the current execution directory, and exports the full information from your old Artifactory (repositories, metadata, security etc.). 3) Each run will create a new tmpExport/[timestamp] subfolder. When exporting a large database multiple times the file system will be filled up quickly. Remove old unwanted exports if you re-execute the export multiple times. 4) After a successful export the tmpExport/[timestamp] folder can be used in Artifactory 1.3.0 for full system import via the web UI. Here is a step by step instructions for running the full update process: 1) Stop the old Artifactory. 2) Copy the $ARTIFACTORY_HOME folder to a new location. 3) If you wish the old Artifactory to keep serving requests while performing the export, restart it. 4) Execute the artifactoryExport.sh on the copy of $ARTIFACTORY_HOME. That will generate a tmpExport/[timestamp] folder. 5) Perform a new clean server installation (no data or artifactory.config.xml) of Artifactory 1.3.0. 6) Start Artifactory 1.3.0. Note: If in step 3 you chose to restart your old Artifactory and your installed the Artifactory 1.3.0 on the same machine, you will need to alter the listening port number inside $ARTIFACTORY_HOME/etc/jetty.xml. 7) Logon as admin/password and go to "Export & Import/Full System" page. 8) Enter the tmpExport/[timestamp] path into the "System zip file or directory" field and click the "Import" button. 9) The import will run and may take some time, depending on the size of your database. 10) Once the import process completes successfully you can switch to using Artifactory 1.3.0. You can switch back the port number if you did so in step 6. OTHER IMPORTANT NOTES ---------------------- Please note that since this is only a beta release candidate not all docs have been updated to reflect the latest changes. Below are important notes that will make their way into the final Artifactory 1.3.0 documentation. PLEASE READ THEM CAREFULLY BEFORE UPDATING: (1) In previous versions of Artifactory a direct local repository request (for example: http://host:8081/artifactory/libs-releases/org/jfrog/art/1.0/art-1.0.jar) used to include all remote repositories as well when processing the request, thus forming an implicit virtual repository. That's why if an artifact was not found locally Artifactory would try to download and cache it from any of the remote repositories. While this behavior may be convenient in some situations, it is normally not desired and certainly not needed when having true virtual repositories support. This version eliminates this behavior, so if your builds rely on direct repository access to perform proxying and caching, you'd have to create and use a true virtual repository instead, that includes the local repository and any remote repositories you wish to participate. Running the Artifactory update manager (artifactoryExport.sh) will automatically convert such virtual repositories from all your old local repositories and recreate the local repositories with a suffix of "-local". This enables your users to transit smoothly to using the new Artifactory installation without needing to update anything in their POMs or settings.xml. If you wish this conversion not to take place, run artifactoryExport.sh with --noconvert as the last argument. Running the Artifactory update manager with the --config exportFolder will only activate this automatic conversion of local repository to virtual repository. The exportFolder should be one of previously exported Artifactory dump. The --config will change the artifactory.config.xml and the repositories folder names. (2) To use the new incremental backup feature, specify <retentionPeriodHours>0</retentionPeriodHours> under the backup configuration. This will cause backups to be written into a permanent "current" directory in a format that can be used by any incremental file-system based backup utility (such as rsync). (3) The M2Eclipse indexing service runs by default on all repositories every one hour. The run interval can be controlled via the artifactory.config.xml file, and repositories can be excluded from being indexed (similar to backup service configuration). (4) Artifactory now includes a convenience method for specifying system properties. Instead of having to configure properties in the runtime configuration of the hosting container, you can now edit the $ARTIFACTORY_HOME/etc/artifactory.properties and restart the container. As this has effect over the whole container VM it is recommended to use this feature to specify Artifactory related properties only (such as repository ids substitution, etc.). (5) If you are running Artifactory under JDK 1.6 you MUST use JDK 1.6u4 and above due to incompatibilities with older JAXB versions embedded in previous JDK 1.6 releases. JDK 1.5 users are not affected by this. Artifactory is available for download here: http://sourceforge.net/project/showfiles.php?group_id=175347 Enjoy! The Artifactory Team ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Artifactory-users mailing list Artifactory-users@... https://lists.sourceforge.net/lists/listinfo/artifactory-users |
|
|
Re: [ANN] Artifactory 1.3.0-beta1
by da Costa Oliveira, Pedro Manuel
::
Rate this Message:
Hi,
Is the "artifact cleanup based on popularity" going to make
it into 1.3.0?
How will it work? Can we define some sort of timeout, so
that after some period the artifact is automatically
deleted?
Thanks,
Pedro From: artifactory-users-bounces@... [mailto:artifactory-users-bounces@...] On Behalf Of Yoav Landman Sent: lundi, 16. juin 2008 23:38 To: Artifactors Users Subject: [Artifactory-users] [ANN] Artifactory 1.3.0-beta1 MAJOR FEATURES AND CHANGES INTRODUCED IN THIS RELEASE ------------------------------------------------------ - Anonymous browsing support - Ability to nest virtual repositories - Drop n Run install: simply drop the Artifactory WAR file inside your servlet container to have all the defaults installed automatically under the user home directory - Seamless, robust upgrade path from previous versions (including rc's) of full system data - Incremental backup support: backups can be stored onto the same directory and be utilized by any file system based incremental backup utility - Storing unzipped backups by default for greater performance - Efficient storage: same artifacts are stored only once in the underlying storage, regardless of how many times they have been deployed - Full support for M2Eclipse indexes (Nexus indexes) for local and remote repositories (Artifactory will create one for its cached data if the remote repository does not support an index) - Many stability and speed improvements - The usual bug fixes The complete release notes are available here: http://www.jfrog.org/jira/browse/RTFACT/fixforversion/10240 FULLY UPGRADING FROM VERSION 1.2.2-RC0 THROUGH 1.2.5U1 ------------------------------------------------------- The provided artifactory-update-1.3.0-x.zip contains a bin folder with the artifactoryExport.sh and artifactoryExport.bat executable. You should run these to fully export your old Artifactory database to a format usable by the Full System Import feature in the Artifactory web UI. To run the export use: artifactoryExport.sh $ARTIFACTORY_HOME [oldArtifactoryVersion] \ [--config exportFolder] [--noconvert] The first parameter is mandatory (except when --config is passed) and should point to a copy of your old $ARTIFACTORY_HOME folder. If that folder also contains a webapps subfolder with the old Artifactory war file, the update manager will automatically determine the old version from it. If the update manager cannot determine a valid version an error message will appear with a list of valid versions and you'd need to manually specify the version of your old Artifactory as a second parameter to artifactoryExport.sh. Important information about the update manager: 1) Always work on a copy of the old $ARTIFACTORY_HOME folder (that, even though the export should be a read only process). 2) Running the update creates a tmpExport folder under the current execution directory, and exports the full information from your old Artifactory (repositories, metadata, security etc.). 3) Each run will create a new tmpExport/[timestamp] subfolder. When exporting a large database multiple times the file system will be filled up quickly. Remove old unwanted exports if you re-execute the export multiple times. 4) After a successful export the tmpExport/[timestamp] folder can be used in Artifactory 1.3.0 for full system import via the web UI. Here is a step by step instructions for running the full update process: 1) Stop the old Artifactory. 2) Copy the $ARTIFACTORY_HOME folder to a new location. 3) If you wish the old Artifactory to keep serving requests while performing the export, restart it. 4) Execute the artifactoryExport.sh on the copy of $ARTIFACTORY_HOME. That will generate a tmpExport/[timestamp] folder. 5) Perform a new clean server installation (no data or artifactory.config.xml) of Artifactory 1.3.0. 6) Start Artifactory 1.3.0. Note: If in step 3 you chose to restart your old Artifactory and your installed the Artifactory 1.3.0 on the same machine, you will need to alter the listening port number inside $ARTIFACTORY_HOME/etc/jetty.xml. 7) Logon as admin/password and go to "Export & Import/Full System" page. 8) Enter the tmpExport/[timestamp] path into the "System zip file or directory" field and click the "Import" button. 9) The import will run and may take some time, depending on the size of your database. 10) Once the import process completes successfully you can switch to using Artifactory 1.3.0. You can switch back the port number if you did so in step 6. OTHER IMPORTANT NOTES ---------------------- Please note that since this is only a beta release candidate not all docs have been updated to reflect the latest changes. Below are important notes that will make their way into the final Artifactory 1.3.0 documentation. PLEASE READ THEM CAREFULLY BEFORE UPDATING: (1) In previous versions of Artifactory a direct local repository request (for example: http://host:8081/artifactory/libs-releases/org/jfrog/art/1.0/art-1.0.jar) used to include all remote repositories as well when processing the request, thus forming an implicit virtual repository. That's why if an artifact was not found locally Artifactory would try to download and cache it from any of the remote repositories. While this behavior may be convenient in some situations, it is normally not desired and certainly not needed when having true virtual repositories support. This version eliminates this behavior, so if your builds rely on direct repository access to perform proxying and caching, you'd have to create and use a true virtual repository instead, that includes the local repository and any remote repositories you wish to participate. Running the Artifactory update manager (artifactoryExport.sh) will automatically convert such virtual repositories from all your old local repositories and recreate the local repositories with a suffix of "-local". This enables your users to transit smoothly to using the new Artifactory installation without needing to update anything in their POMs or settings.xml. If you wish this conversion not to take place, run artifactoryExport.sh with --noconvert as the last argument. Running the Artifactory update manager with the --config exportFolder will only activate this automatic conversion of local repository to virtual repository. The exportFolder should be one of previously exported Artifactory dump. The --config will change the artifactory.config.xml and the repositories folder names. (2) To use the new incremental backup feature, specify <retentionPeriodHours>0</retentionPeriodHours> under the backup configuration. This will cause backups to be written into a permanent "current" directory in a format that can be used by any incremental file-system based backup utility (such as rsync). (3) The M2Eclipse indexing service runs by default on all repositories every one hour. The run interval can be controlled via the artifactory.config.xml file, and repositories can be excluded from being indexed (similar to backup service configuration). (4) Artifactory now includes a convenience method for specifying system properties. Instead of having to configure properties in the runtime configuration of the hosting container, you can now edit the $ARTIFACTORY_HOME/etc/artifactory.properties and restart the container. As this has effect over the whole container VM it is recommended to use this feature to specify Artifactory related properties only (such as repository ids substitution, etc.). (5) If you are running Artifactory under JDK 1.6 you MUST use JDK 1.6u4 and above due to incompatibilities with older JAXB versions embedded in previous JDK 1.6 releases. JDK 1.5 users are not affected by this. Artifactory is available for download here: http://sourceforge.net/project/showfiles.php?group_id=175347 Enjoy! The Artifactory Team ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Artifactory-users mailing list Artifactory-users@... https://lists.sourceforge.net/lists/listinfo/artifactory-users |
|
|
Re: [ANN] Artifactory 1.3.0-beta1
by Yoav Landman
::
Rate this Message:
Yes, it will. It will work just they way you described it - if an artifact has not been downloaded for a certain period of time it will automatically become candidate for removal.
On Tue, Jun 24, 2008 at 12:14 PM, da Costa Oliveira, Pedro Manuel <PedroManuel.daCostaOliveira@...> wrote:
------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Artifactory-users mailing list Artifactory-users@... https://lists.sourceforge.net/lists/listinfo/artifactory-users |
|
|
Re: [ANN] Artifactory 1.3.0-beta1
by da Costa Oliveira, Pedro Manuel
::
Rate this Message:
Hi,
How can I configure it? Can I do it per
repository?
I tried to look in artifactory.config.xml, but couldn't
find it.
Thanks,
Pedro From: artifactory-users-bounces@... [mailto:artifactory-users-bounces@...] On Behalf Of Yoav Landman Sent: mardi, 24. juin 2008 13:24 To: artifactory-users@... Subject: Re: [Artifactory-users] [ANN] Artifactory 1.3.0-beta1 On Tue, Jun 24, 2008 at 12:14 PM, da Costa Oliveira,
Pedro Manuel <PedroManuel.daCostaOliveira@...>
wrote:
|
