Re: Staging Repository
Reinhard Poetz wrote:
Jorg Heymans wrote:
Jorg Heymans wrote:
Just agreed on this with Reinhard off-list, i'll make the required
changes.
ok this is done now. I hope i got the permissions right (g+w and o+w on
all dirs involved, including my home dir).
Can someone please give it a spin ?
I'll give it a try tommorrow and let you know whether it works for me.
I tried it and run into the problem[1] that when I refer to the already released
Cocoon parent artifact (org.apache.cocoon:cocoon:1), the old value for the
distribution repository is taken. Because of this I accidently deployed the
batik parent pom (org.apache.cocoon:batik:1) to the official Apache sync repo.
Any ideas how to override the distribution repository from command line or do we
really have to deploy all our pom artifacts just to propagate the new location?
If there is no way we should find the final location of our sync repo as the
current solution /home/jheymans/public_html/cocoon-staging-repository is of
course just a temporary solution. This way we only have to deploy all the pom
artifacts just once again.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Staging Repository
Jorg Heymans wrote:
Jorg Heymans wrote:
Just agreed on this with Reinhard off-list, i'll make the required changes.
ok this is done now. I hope i got the permissions right (g+w and o+w on
all dirs involved, including my home dir).
Can someone please give it a spin ?
Is it on purpose that the cocoon-staging-repository is completly empty?
pwd
/x1/home/jheymans/public_html/cocoon-staging-repository
ls -lsa
total 4
2 drwxrwxrwx 2 jheymans jheymans 512 Aug 8 10:08 .
2 drwxrwxrwx 3 jheymans jheymans 512 Aug 8 10:08 ..
My understanding was that the staging repo is a mirror of everything under
org/apache/cocoon and when we really want to release, we call a script that
copies our changes to the public sync repo or if we want to roll back, we copy
back the changes by copying the content of the sync repo over our staging repo
(we should be able to do this on specific paths, but that's a detail).
Have you already written the necessary scripts?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Staging Repository
Reinhard Poetz wrote: I tried it and run into the problem[1] that when I refer to the already released Cocoon parent artifact (org.apache.cocoon:cocoon:1), the old value for the distribution repository is taken. Because of this I accidently deployed the batik parent pom (org.apache.cocoon:batik:1) to the official Apache sync repo. Yes you should've deployed our new root pom first and waited for the sync to maven central before deploying any child blocks. Any ideas how to override the distribution repository from command line or do we really have to deploy all our pom artifacts just to propagate the new location? mmm interesting problem... deploying a new root pom potentially triggers a cascade of module pom deployments. We could get around this by making all poms extend the root pom directly, instead of passing via their parent module poms. This would work if we don't intend to use the module poms for anything else but to aggregate the module components. I'll need to think about this. Jorg
Re: Staging Repository
Reinhard Poetz wrote: My understanding was that the staging repo is a mirror of everything under org/apache/cocoon and when we really want to release, we call a script that copies our changes to the public sync repo or if we want to roll back, we copy back the changes by copying the content of the sync repo over our staging repo (we should be able to do this on specific paths, but that's a detail). this would work, even though my understanding was that staging-release repo is a one way process. You deploy to staging and after verification you _move_ the files simply to release. If you get it wrong, just zap staging and try again. I just talked with jdcasey on #maven about this, he said that we should be ok with overwriting metadata.xml as the versions element in there is only used for snapshot resolution. Release artifacts are looked up directly. Have you already written the necessary scripts? nope. Jorg
Re: Staging Repository
Jorg Heymans wrote:
Reinhard Poetz wrote:
My understanding was that the staging repo is a mirror of everything
under org/apache/cocoon and when we really want to release, we call a
script that copies our changes to the public sync repo or if we want to
roll back, we copy back the changes by copying the content of the sync
repo over our staging repo (we should be able to do this on specific
paths, but that's a detail).
this would work, even though my understanding was that staging-release
repo is a one way process. You deploy to staging and after verification
you _move_ the files simply to release. If you get it wrong, just zap
staging and try again. I just talked with jdcasey on #maven about this,
he said that we should be ok with overwriting metadata.xml as the
versions element in there is only used for snapshot resolution.
Release artifacts are looked up directly.
ahh, ok. Then there is no need to for keeping our staging repo in sync with the
public sync repo.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Re: Re: Staging Repository
Jorg Heymans wrote: ...The only thing i'm still unsure about is how to do the sync between the zone and people.a.o, rsync might not work too well given the metadata that's involved Note that, IMHO, you shouldn't rsync directly into the people.a.o directories that are rsynced to the final repositories: if you do this and a sync is happening from people.a.o to the final destination at the same time, you might end up with an incomplete set of files at the final destination (hope I'm being clear ;-) I think the safe way is to first rsync from the zone to a temporary location on people.a.o, which is on the same filesystem than the final location, then do a move (mv), which is atomic, to the final location on people.a.o. -Bertrand (I'm not being paranoid, am I?)
Re: Staging Repository
Bertrand Delacretaz wrote: I think the safe way is to first rsync from the zone to a temporary location on people.a.o, which is on the same filesystem than the final location, then do a move (mv), which is atomic, to the final location on people.a.o. -Bertrand (I'm not being paranoid, am I?) not at all :) Just agreed on this with Reinhard off-list, i'll make the required changes. Jorg
Re: Staging Repository
Jorg Heymans wrote: Just agreed on this with Reinhard off-list, i'll make the required changes. ok this is done now. I hope i got the permissions right (g+w and o+w on all dirs involved, including my home dir). Can someone please give it a spin ? Regards Jorg
Re: Staging Repository
Jorg Heymans wrote:
Jorg Heymans wrote:
Just agreed on this with Reinhard off-list, i'll make the required changes.
ok this is done now. I hope i got the permissions right (g+w and o+w on
all dirs involved, including my home dir).
Can someone please give it a spin ?
I'll give it a try tommorrow and let you know whether it works for me.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Staging Repository
Jorg Heymans wrote:
I've setup a staging repo on the zones,
http://cocoon.zones.apache.org/cocoon-staging-release-repository/. It's
configured in the root pom so any release:perform action will be going
there instead of people.a.o.
The idea is that we can verify releases from there *before* we sync to
people.a.o and give the green to [EMAIL PROTECTED] to upload to maven central.
The only thing i'm still unsure about is how to do the sync between the
zone and people.a.o, rsync might not work too well given the metadata
that's involved.
Why do you think so? As long there is no other process that manipulates Cocoon
artifacts in the Apache m2-sync repo *directly* and circumvents the staging
repo, I don't see any problems.
How can we trigger the sync from cocoon.zones.apache.org given that we
shouldn't/mustn't store private ssh keys on this potentially unsecure machine?
Wouldn't it be a better option to have our staging repo on people.apache.org too?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Re: Staging Repository
Reinhard Poetz wrote: The only thing i'm still unsure about is how to do the sync between the zone and people.a.o, rsync might not work too well given the metadata that's involved. Why do you think so? As long there is no other process that manipulates Cocoon artifacts in the Apache m2-sync repo *directly* and circumvents the staging repo, I don't see any problems. OK i see now, it will work if nobody circumvents the staging repo. How can we trigger the sync from cocoon.zones.apache.org given that we shouldn't/mustn't store private ssh keys on this potentially unsecure machine? Wouldn't it be a better option to have our staging repo on people.apache.org too? i didn't know the zone is potentially unsecure. If we are allowed to create people.a.o/repo/cocoon-staging-release-repository then that's ok as well (and probably easier to access for all). Jorg
