Releases In the Trash!?
|
View:
New views
13 Messages
—
Rating Filter:
Alert me
|
 |
Releases In the Trash!?
by jrduncans
::
Rate this Message:
Running Nexus version 1.3.3. I noticed yesterday that, in my companies Nexus install, all our old releases were missing. It turns out that on Saturday, May 30th, they were put in the trash folder.
I have several scheduled tasks, but I did not understand any of them to ever delete released jars. 1) What all do I have to do to get those releases back from the trash into the releases? 2) What should I look for in terms of things that could have caused this? What log files should I look at? -- Stephen Duncan Jr www.stephenduncanjr.com |
|
|
Re: Releases In the Trash!?
by Brian Fox
::
Rate this Message:
For a hosted release repository, none of the tasks should touch a release repo. Check the system changes feed to see what actions have occured around the time where the artifacts went missing.
To restore them, on the server simply copy/move the contents from the trash back to the storage folder. You would then want to run a reindex.
On Tue, Jun 2, 2009 at 10:42 AM, Stephen Duncan Jr <stephen.duncan@...> wrote: Running Nexus version 1.3.3. I noticed yesterday that, in my companies Nexus install, all our old releases were missing. It turns out that on Saturday, May 30th, they were put in the trash folder. |
|
|
Re: Releases In the Trash!?
by jrduncans
::
Rate this Message:
On Tue, Jun 2, 2009 at 1:49 PM, Brian Fox <brianf@...> wrote: For a hosted release repository, none of the tasks should touch a release repo. Check the system changes feed to see what actions have occured around the time where the artifacts went missing. For Satuday (which is the timestamp on almost all of the directories in trash/releases/our/groupid), what I have in the System Change feed: Removing snapshots from repository Snapshots Emptying Trash Downloading indexes for repository group public Evicting unused proxied items for all registered proxy repositories During that last one, I did see an exception in the log: 2009-05-30 12:03:13 WARN [pool-1-thread-2] - o.s.n.p.r.ShadowRep~:m2-m1-s~ - Could not sync shadow repository because of exception org.sonatype.nexus.proxy.ItemNotFoundException: Item not found on UID central-m1:/com.google.gwt/poms/gwt-servlet-1.4.62.pom in repository central-m1 -- Stephen Duncan Jr www.stephenduncanjr.com |
|
|
Re: Releases In the Trash!?
by Brian Fox
::
Rate this Message:
We think the purge unused artifacts task might be the culprit but the code in question hasn't changed in over a year. We're still evaluating it, but make sure you have selected only proxy repos in the task config until we confirm.
On Tue, Jun 2, 2009 at 11:24 AM, Stephen Duncan Jr <stephen.duncan@...> wrote:
|
|
|
Re: Releases In the Trash!?
by jrduncans
::
Rate this Message:
I'm more paranoid than that; for now I have all tasks disabled. :)
It was set to All Repositories, because I want it set to all proxy-repos, but there's no multi-select, and I certainly didn't want to schedule each proxy-repo individually... On Tue, Jun 2, 2009 at 2:49 PM, Brian Fox <brianf@...> wrote: We think the purge unused artifacts task might be the culprit but the code in question hasn't changed in over a year. We're still evaluating it, but make sure you have selected only proxy repos in the task config until we confirm. -- Stephen Duncan Jr www.stephenduncanjr.com |
|
|
Re: Releases In the Trash!?
by Brian Fox
::
Rate this Message:
We confirmed that it is the evict task and apparently has been broken for a while. See my other thread for the url.
On Tue, Jun 2, 2009 at 11:56 AM, Stephen Duncan Jr <stephen.duncan@...> wrote: I'm more paranoid than that; for now I have all tasks disabled. :) |
|
|
Re: Releases In the Trash!?
by MALICE
::
Rate this Message:
Just wondering here... Could this be used as a feature? In my company this
would be great behavior on our 'fix' repository... Here we upload libraries and/or plugins that had some bugs and we fixed ourselves. Until they are released by the respective owners, we use them, after official release, we should delete them. However, if they are automatically deleted when not requested, we can be sure they are deleted if we forget! Just my thoughts on this. If it is left in, it should of course be documented and be used with caution... > We confirmed that it is the evict task and apparently has been broken for > a > while. See my other thread for the url. > > On Tue, Jun 2, 2009 at 11:56 AM, Stephen Duncan Jr > <stephen.duncan@... >> wrote: > >> I'm more paranoid than that; for now I have all tasks disabled. :) >> >> It was set to All Repositories, because I want it set to all >> proxy-repos, >> but there's no multi-select, and I certainly didn't want to schedule >> each >> proxy-repo individually... >> >> On Tue, Jun 2, 2009 at 2:49 PM, Brian Fox <brianf@...> wrote: >> >>> We think the purge unused artifacts task might be the culprit but the >>> code >>> in question hasn't changed in over a year. We're still evaluating it, >>> but >>> make sure you have selected only proxy repos in the task config until >>> we >>> confirm. >>> >>> >> >> -- >> Stephen Duncan Jr >> www.stephenduncanjr.com >> > --------------------------------------------------------------------- To unsubscribe, e-mail: nexus-user-unsubscribe@... For additional commands, e-mail: nexus-user-help@... |
|
|
Re: Releases In the Trash!?
by Brian Fox
::
Rate this Message:
You shouldn't use the same version as they would to avoid potential conflicts, thus you would want to maintain your internal release in case you need to rebuild a tag. I have some thoughts on that here:
On Tue, Jun 2, 2009 at 5:54 PM, Roland Asmann <Roland.Asmann@...> wrote: Just wondering here... Could this be used as a feature? In my company this |
|
|
Re: Releases In the Trash!?
by MALICE
::
Rate this Message:
I'm not using the same version as they are. For instance my colleague has
been developing the maven-eclipse-plugin and we would deploy our internal versions as "2.3-CFC-<date>". Then when his changes were merged into the new release, we would update our POMs to use 2.4 instead of 2.3-CFC-<date>. So, there would be no conflicts and no SNAPSHOT dependencies... Roland > You shouldn't use the same version as they would to avoid potential > conflicts, thus you would want to maintain your internal release in case > you > need to rebuild a tag. I have some thoughts on that here: > http://www.sonatype.com/people/2009/01/best-practices-for-releasing-with-3rd-party-snapshot-dependencies/ > > > On Tue, Jun 2, 2009 at 5:54 PM, Roland Asmann <Roland.Asmann@...> > wrote: > >> Just wondering here... Could this be used as a feature? In my company >> this >> would be great behavior on our 'fix' repository... Here we upload >> libraries and/or plugins that had some bugs and we fixed ourselves. >> Until >> they are released by the respective owners, we use them, after official >> release, we should delete them. However, if they are automatically >> deleted >> when not requested, we can be sure they are deleted if we forget! >> >> Just my thoughts on this. If it is left in, it should of course be >> documented and be used with caution... >> >> >> > We confirmed that it is the evict task and apparently has been broken >> for >> > a >> > while. See my other thread for the url. >> > >> > On Tue, Jun 2, 2009 at 11:56 AM, Stephen Duncan Jr >> > <stephen.duncan@... >> >> wrote: >> > >> >> I'm more paranoid than that; for now I have all tasks disabled. :) >> >> >> >> It was set to All Repositories, because I want it set to all >> >> proxy-repos, >> >> but there's no multi-select, and I certainly didn't want to schedule >> >> each >> >> proxy-repo individually... >> >> >> >> On Tue, Jun 2, 2009 at 2:49 PM, Brian Fox <brianf@...> >> wrote: >> >> >> >>> We think the purge unused artifacts task might be the culprit but >> the >> >>> code >> >>> in question hasn't changed in over a year. We're still evaluating >> it, >> >>> but >> >>> make sure you have selected only proxy repos in the task config >> until >> >>> we >> >>> confirm. >> >>> >> >>> >> >> >> >> -- >> >> Stephen Duncan Jr >> >> www.stephenduncanjr.com >> >> >> > >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: nexus-user-unsubscribe@... >> For additional commands, e-mail: nexus-user-help@... >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: nexus-user-unsubscribe@... For additional commands, e-mail: nexus-user-help@... |
|
|
Re: Releases In the Trash!?
by Brian Fox
::
Rate this Message:
On Wed, Jun 3, 2009 at 2:12 AM, Roland Asmann <Roland.Asmann@...> wrote: I'm not using the same version as they are. For instance my colleague has Right, but presumably some code you have tagged as a release depends on this version. If it magically went away, you wouldn't be able to reproduce it.
|
|
|
Re: Releases In the Trash!?
by MALICE
::
Rate this Message:
On Wednesday 03 June 2009 16:52, Brian Fox wrote:
> On Wed, Jun 3, 2009 at 2:12 AM, Roland Asmann <Roland.Asmann@...> wrote: > > I'm not using the same version as they are. For instance my colleague has > > been developing the maven-eclipse-plugin and we would deploy our internal > > versions as "2.3-CFC-<date>". Then when his changes were merged into the > > new release, we would update our POMs to use 2.4 instead of > > 2.3-CFC-<date>. > > > > So, there would be no conflicts and no SNAPSHOT dependencies... > > Right, but presumably some code you have tagged as a release depends on > this version. If it magically went away, you wouldn't be able to reproduce > it. You've got a point there... Maybe I should rethink this a little bit, I was sure it was a great idea, until you burst my bubble just now... :-) > > > Roland > > > > > You shouldn't use the same version as they would to avoid potential > > > conflicts, thus you would want to maintain your internal release in > > > case you > > > need to rebuild a tag. I have some thoughts on that here: > > > > http://www.sonatype.com/people/2009/01/best-practices-for-releasing-with- > >3rd-party-snapshot-dependencies/ > > > > > On Tue, Jun 2, 2009 at 5:54 PM, Roland Asmann <Roland.Asmann@...> > > > > > > wrote: > > >> Just wondering here... Could this be used as a feature? In my company > > >> this > > >> would be great behavior on our 'fix' repository... Here we upload > > >> libraries and/or plugins that had some bugs and we fixed ourselves. > > >> Until > > >> they are released by the respective owners, we use them, after > > >> official release, we should delete them. However, if they are > > >> automatically deleted > > >> when not requested, we can be sure they are deleted if we forget! > > >> > > >> Just my thoughts on this. If it is left in, it should of course be > > >> documented and be used with caution... > > >> > > >> > We confirmed that it is the evict task and apparently has been > > >> > broken > > >> > > >> for > > >> > > >> > a > > >> > while. See my other thread for the url. > > >> > > > >> > On Tue, Jun 2, 2009 at 11:56 AM, Stephen Duncan Jr > > >> > <stephen.duncan@... > > >> > > > >> >> wrote: > > >> >> > > >> >> I'm more paranoid than that; for now I have all tasks disabled. :) > > >> >> > > >> >> It was set to All Repositories, because I want it set to all > > >> >> proxy-repos, > > >> >> but there's no multi-select, and I certainly didn't want to > > >> >> schedule each > > >> >> proxy-repo individually... > > >> >> > > >> >> On Tue, Jun 2, 2009 at 2:49 PM, Brian Fox <brianf@...> > > >> > > >> wrote: > > >> >>> We think the purge unused artifacts task might be the culprit but > > >> > > >> the > > >> > > >> >>> code > > >> >>> in question hasn't changed in over a year. We're still evaluating > > >> > > >> it, > > >> > > >> >>> but > > >> >>> make sure you have selected only proxy repos in the task config > > >> > > >> until > > >> > > >> >>> we > > >> >>> confirm. > > >> >> > > >> >> -- > > >> >> Stephen Duncan Jr > > >> >> www.stephenduncanjr.com > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: nexus-user-unsubscribe@... > > >> For additional commands, e-mail: nexus-user-help@... > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: nexus-user-unsubscribe@... > > For additional commands, e-mail: nexus-user-help@... -- Roland Asmann CFC Informationssysteme Entwicklungsgesellschaft m.b.H Bäckerstrasse 1/2/7 A-1010 Wien FN 266155f, Handelsgericht Wien Tel.: +43/1/513 88 77 - 27 Fax.: +43/1/513 88 62 Email: Roland.Asmann@... Web: www.cfc.at --------------------------------------------------------------------- To unsubscribe, e-mail: nexus-user-unsubscribe@... For additional commands, e-mail: nexus-user-help@... |
|
|
Re: Releases In the Trash!?
by MALICE
::
Rate this Message:
> On Wednesday 03 June 2009 16:52, Brian Fox wrote:
>> On Wed, Jun 3, 2009 at 2:12 AM, Roland Asmann <Roland.Asmann@...> >> wrote: >> > I'm not using the same version as they are. For instance my colleague >> has >> > been developing the maven-eclipse-plugin and we would deploy our >> internal >> > versions as "2.3-CFC-<date>". Then when his changes were merged into >> the >> > new release, we would update our POMs to use 2.4 instead of >> > 2.3-CFC-<date>. >> > >> > So, there would be no conflicts and no SNAPSHOT dependencies... >> >> Right, but presumably some code you have tagged as a release depends on >> this version. If it magically went away, you wouldn't be able to >> reproduce >> it. > > You've got a point there... Maybe I should rethink this a little bit, I > was > sure it was a great idea, until you burst my bubble just now... :-) OK, so I thought about it... Quite some time as you may have noticed! ;-) But without joking around, I think this can still be used, you just have to be *VERY* careful with it. I saw it was fixed now, but I was wondering if it could be changed so that when you schedule this task on a hosted repository it *WILL* run? As I've pointed out, this way I can keep our internal repository nice and clean. I have tests running for all our projects, so I will be completely sure that nothing will be deleted that's still needed. And if it might happen, isn't the power of Maven the ability to reproduce the same artifact over and over again? Point is, we've got lots of alpha's and beta's flying around and since they are *NOT* snapshots, they will not get deleted when the final release is deployed. I was just browsing through our repository, which currently is around 2GB in size. I suspect we use no more than 100MB of this for our current projects. So, to get to the point again, should I open an issue for this, or is the current implementation for the fix already able to do this? Thanks, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: nexus-user-unsubscribe@... For additional commands, e-mail: nexus-user-help@... |
|
|
Re: Releases In the Trash!?
by Brian Fox
::
Rate this Message:
>
> So, to get to the point again, should I open an issue for this, or is the > current implementation for the fix already able to do this? > I've since done training at a few places where this does make sense...where the end product is either a website or an internal process tool where older versions truly are meaningless. Because of the potential for disaster in more traditional "shipped software" houses, I would prefer to handle this as a special scheduled task instead. Please file an issue and we'll get it scheduled. It could also be implemented as a plugin. --------------------------------------------------------------------- To unsubscribe, e-mail: nexus-user-unsubscribe@... For additional commands, e-mail: nexus-user-help@... |
| Free embeddable forum powered by Nabble | Forum Help |
