Documentation links and content "out of date"
|
|
|
||||||||
|
Hi,
I think that this is because the machine that builds and uploads the snapshots was offline for the last couple of months. I got that partially back up and running last week, and hope to get the snapshots uploading again later this week. -Patrick On Jul 15, 2008, at 5:30 PM, Kevin Sutter wrote: > Hi, > I just noticed that our links for the "latest" OpenJPA documentation > is out > of date (http://cwiki.apache.org/openjpa/documentation.html). I would > expect that our "latest" link should point at some version of > documentation > associated with trunk. But, it's currently pointing at some version > based > on the 1.1.0 build. I was going to go ahead and clean this up, but > it looks > like I don't have proper authority to the /www/ > openjpa.apache.org/docs/latest directory. It looks like Patrick is > the only > one with enough authority. > > This "latest" directory is currently linked to this: latest -> > ../builds/1.1.0/apache-openjpa-1.1.0/docs/ > > So, I'm thinking a few things need to be done: > > o It would be great to post our current nightly drivers and > documentation > out on people.apache.org from our TC system. (BTW, it looks like our > nightly drivers page is still pointing at the 1.1.0 SNAPSHOT builds, > so we > have some clean up there as well.) I'm not sure on the status of > Patrick's > TC system and whether we are able to get something like this setup > or not. > > o If we can post our nightly drivers and documentation, then we could > change this "latest" directory link to our upload location for the > drivers. > > o If this type of clean up and setup of nightly drivers is going to > take > some time, then at a minimum, it would be good to change the > permissions on > this "latest" directory so that we could do some manual (pardon the > pun) > cleanup. > > BTW, all of this came about because I had pointed a user at our > "latest" > manual to find out how to turn on the Query SQL Cache support > (knowing it > was part of the 1.2.0 trunk release). But, I soon discovered that our > "latest" manual is quite out of date... :-) > > Thanks, > Kevin Patrick Linskey 202 669 5907 |
||||||||
smime.p7s (3K) |
|
|
||||||||
|
|
Hi,
I'm trying to get the snapshot process working as closely to the new release process as possible. From what I can tell, mvn release:prepare is really oriented towards releases, not towards snapshots. Does anyone know of an equivalent snapshot target that we could use? -Patrick On Jul 16, 2008, at 7:06 AM, Kevin Sutter wrote: > Sounds good, Patrick. So, in the mean time, should I make a temporary > repository for the "latest" docs? Or, if you think this will get > resolved > in the next day or two, then I could just wait. > > Thanks, > Kevin > > On Tue, Jul 15, 2008 at 6:40 PM, Patrick Linskey > <plinskey@...> wrote: > >> Hi, >> >> I think that this is because the machine that builds and uploads the >> snapshots was offline for the last couple of months. I got that >> partially >> back up and running last week, and hope to get the snapshots >> uploading again >> later this week. >> >> -Patrick >> >> >> On Jul 15, 2008, at 5:30 PM, Kevin Sutter wrote: >> >> Hi, >>> I just noticed that our links for the "latest" OpenJPA >>> documentation is >>> out >>> of date (http://cwiki.apache.org/openjpa/documentation.html). I >>> would >>> expect that our "latest" link should point at some version of >>> documentation >>> associated with trunk. But, it's currently pointing at some >>> version based >>> on the 1.1.0 build. I was going to go ahead and clean this up, >>> but it >>> looks >>> like I don't have proper authority to the /www/ >>> openjpa.apache.org/docs/latest directory. It looks like Patrick >>> is the >>> only >>> one with enough authority. >>> >>> This "latest" directory is currently linked to this: latest -> >>> ../builds/1.1.0/apache-openjpa-1.1.0/docs/ >>> >>> So, I'm thinking a few things need to be done: >>> >>> o It would be great to post our current nightly drivers and >>> documentation >>> out on people.apache.org from our TC system. (BTW, it looks like >>> our >>> nightly drivers page is still pointing at the 1.1.0 SNAPSHOT >>> builds, so we >>> have some clean up there as well.) I'm not sure on the status of >>> Patrick's >>> TC system and whether we are able to get something like this setup >>> or not. >>> >>> o If we can post our nightly drivers and documentation, then we >>> could >>> change this "latest" directory link to our upload location for the >>> drivers. >>> >>> o If this type of clean up and setup of nightly drivers is going >>> to take >>> some time, then at a minimum, it would be good to change the >>> permissions >>> on >>> this "latest" directory so that we could do some manual (pardon >>> the pun) >>> cleanup. >>> >>> BTW, all of this came about because I had pointed a user at our >>> "latest" >>> manual to find out how to turn on the Query SQL Cache support >>> (knowing it >>> was part of the 1.2.0 trunk release). But, I soon discovered that >>> our >>> "latest" manual is quite out of date... :-) >>> >>> Thanks, >>> Kevin >>> >> >> -- >> Patrick Linskey >> 202 669 5907 >> >> Patrick Linskey 202 669 5907 |
||||||||
|
|
||||||||
|
|
|
||||||||
|
|
> $ mvn -Dmaven.test.skip=true deploy
> -DaltDeploymentRepository=myserver::default::scp:// > myserver.myhost.com/home/mikedd/temp22 > > $ mvn -Dmaven.test.skip=true site:stage-deploy > -DstagingSiteURL=scp://myserver.myhost.com:/home/mikedd/temp-site Interesting -- I didn't know you could pass in overrides like that. > Here's what I propose, after the 1.0.3 release is approved I'll > update the > pom.xml files for 1.0.x and 1.2.x (1.1.x too if you approve). The > changes > will be to update the default deploy location to be > openjpa.apache.org/builds/latest/${version} (or something similar). > That way > the automated build system will go ahead and publish to the latest > directory > with no need for command line arguments. that right now (without the 'latest' dir); it failed to run from the autobuild on Friday, and I was at a pre-OSCON event yesterday, but am hoping to figure out why not today. > In the release profile we'll change the deployment location to be > people.apache.org/${user}/public_html/. . . so that the release is > publicly > available. If we can't override the location via the profile I'll > update the > instructions to pass it along as a command line arg. Knowing that we can pass overrides into mvn, I think that there's a case to be made for having the defaults be to put contents into the user's homedir, and then have the snapshot process and the release process override the values as appropriate. That seems a bit safer. I think that the current settings for the repository locations in trunk might actually be (almost) sufficient. I think we should make one change: instead of the current values ([1] and [2]), I think we should use the following: scp://people.apache.org/home/${user.name}/public_html/openjpa-staging- repo scp://people.apache.org/home/${user.name}/public_html/openjpa-staging- site Thoughts? -Patrick [1] scp://people.apache.org/home/${user.name}/public_html/openjpa/$ {pom.version}/staging-repo [2] scp://people.apache.org/home/${user.name}/public_html/openjpa/$ {pom.version}/staging-site On Jul 21, 2008, at 8:48 AM, Michael Dick wrote: > Hi, > > I gave this a quick test and it looks like it's working, here's > exactly what > I ran : > > $ mvn -Dmaven.test.skip=true deploy > -DaltDeploymentRepository=myserver::default::scp:// > myserver.myhost.com/home/mikedd/temp22 > > $ mvn -Dmaven.test.skip=true site:stage-deploy > -DstagingSiteURL=scp://myserver.myhost.com:/home/mikedd/temp-site > > I think a similar set of arguments can be used for the release > process. > > Here's what I propose, after the 1.0.3 release is approved I'll > update the > pom.xml files for 1.0.x and 1.2.x (1.1.x too if you approve). The > changes > will be to update the default deploy location to be > openjpa.apache.org/builds/latest/${version} (or something similar). > That way > the automated build system will go ahead and publish to the latest > directory > with no need for command line arguments. > > In the release profile we'll change the deployment location to be > people.apache.org/${user}/public_html/. . . so that the release is > publicly > available. If we can't override the location via the profile I'll > update the > instructions to pass it along as a command line arg. > > If this sounds acceptable to everyone else I'll go ahead and open > another > JIRA (633 has enough changes). > > -mike > > > > > On Sat, Jul 19, 2008 at 11:53 AM, Michael Dick <mikedd@...> > wrote: > >> Hi Patrick, >> >> If you're looking to upload a snapshot to say your home directory on >> people.apache.org you can just run >> $ mvn deploy >> >> I think we'd rather have the snapshots deployed to our builds >> directory though. Something like this should work (untested) >> $ mvn -DaltDeploymentRepository=people.apache.org::default:scp:// >> people.apache.org/www/openjpa.apache.org/builds/${version}<http://people.apache.org/www/openjpa.apache.org/builds/$%7Bversion%7D >> > >> deploy >> >> You'll need to add a server tag for people.apache.org to your >> ${home}/.m2/settings.xml file. Something like this should work: >> >> <servers> >> <server> >> <id>people.apache.org</id> >> <username>[your apache id]</username> >> <passphrase>[secret passphrase]</passphrase> >> <filePermissions>664</filePermissions> >> <directoryPermissions>775</directoryPermissions> >> </server> >> </servers> >> >> The preceding examples will upload our maven artifacts. To deploy the >> site I *think* this would work >> >> $ mvn -DstagingSiteURL=scp:// >> people.apache.org/www/openjpa.apache.org/builds/${version} >> site:stage-deploy<http://people.apache.org/www/openjpa.apache.org/builds/$%7Bversion%7Dsite:stage-deploy >> > >> >> I'll take a closer look when time permits, this should be a starting >> point though. >> >> -mike >> >> On Fri, Jul 18, 2008 at 5:56 PM, Patrick Linskey <plinskey@...> >> wrote: >>> >>> Hi, >>> >>> I'm trying to get the snapshot process working as closely to the new >> release process as possible. From what I can tell, mvn >> release:prepare is >> really oriented towards releases, not towards snapshots. Does >> anyone know of >> an equivalent snapshot target that we could use? >>> >>> -Patrick >>> >>> On Jul 16, 2008, at 7:06 AM, Kevin Sutter wrote: >>> >>>> Sounds good, Patrick. So, in the mean time, should I make a >>>> temporary >>>> repository for the "latest" docs? Or, if you think this will get >> resolved >>>> in the next day or two, then I could just wait. >>>> >>>> Thanks, >>>> Kevin >>>> >>>> On Tue, Jul 15, 2008 at 6:40 PM, Patrick Linskey <plinskey@... >>>> > >> wrote: >>>> >>>>> Hi, >>>>> >>>>> I think that this is because the machine that builds and uploads >>>>> the >>>>> snapshots was offline for the last couple of months. I got that >> partially >>>>> back up and running last week, and hope to get the snapshots >>>>> uploading >> again >>>>> later this week. >>>>> >>>>> -Patrick >>>>> >>>>> >>>>> On Jul 15, 2008, at 5:30 PM, Kevin Sutter wrote: >>>>> >>>>> Hi, >>>>>> >>>>>> I just noticed that our links for the "latest" OpenJPA >>>>>> documentation >> is >>>>>> out >>>>>> of date (http://cwiki.apache.org/openjpa/documentation.html). I >> would >>>>>> expect that our "latest" link should point at some version of >>>>>> documentation >>>>>> associated with trunk. But, it's currently pointing at some >>>>>> version >> based >>>>>> on the 1.1.0 build. I was going to go ahead and clean this up, >>>>>> but it >>>>>> looks >>>>>> like I don't have proper authority to the /www/ >>>>>> openjpa.apache.org/docs/latest directory. It looks like >>>>>> Patrick is >> the >>>>>> only >>>>>> one with enough authority. >>>>>> >>>>>> This "latest" directory is currently linked to this: latest -> >>>>>> ../builds/1.1.0/apache-openjpa-1.1.0/docs/ >>>>>> >>>>>> So, I'm thinking a few things need to be done: >>>>>> >>>>>> o It would be great to post our current nightly drivers and >> documentation >>>>>> out on people.apache.org from our TC system. (BTW, it looks >>>>>> like our >>>>>> nightly drivers page is still pointing at the 1.1.0 SNAPSHOT >>>>>> builds, >> so we >>>>>> have some clean up there as well.) I'm not sure on the status of >>>>>> Patrick's >>>>>> TC system and whether we are able to get something like this >>>>>> setup or >> not. >>>>>> >>>>>> o If we can post our nightly drivers and documentation, then >>>>>> we could >>>>>> change this "latest" directory link to our upload location for >>>>>> the >>>>>> drivers. >>>>>> >>>>>> o If this type of clean up and setup of nightly drivers is >>>>>> going to >> take >>>>>> some time, then at a minimum, it would be good to change the >> permissions >>>>>> on >>>>>> this "latest" directory so that we could do some manual (pardon >>>>>> the >> pun) >>>>>> cleanup. >>>>>> >>>>>> BTW, all of this came about because I had pointed a user at our >> "latest" >>>>>> manual to find out how to turn on the Query SQL Cache support >>>>>> (knowing >> it >>>>>> was part of the 1.2.0 trunk release). But, I soon discovered >>>>>> that our >>>>>> "latest" manual is quite out of date... :-) >>>>>> >>>>>> Thanks, >>>>>> Kevin >>>>>> >>>>> >>>>> -- >>>>> Patrick Linskey >>>>> 202 669 5907 >>>>> >>>>> >>> >>> -- >>> Patrick Linskey >>> 202 669 5907 >>> >> Patrick Linskey 202 669 5907 |
||||||||
|
|
In reply to this post by mikedd
A few questions, since it looks like you might grok this mvn thing
better than I: > $ mvn -Dmaven.test.skip=true deploy > -DaltDeploymentRepository=myserver::default::scp:// > myserver.myhost.com/home/mikedd/temp22 > > $ mvn -Dmaven.test.skip=true site:stage-deploy > -DstagingSiteURL=scp://myserver.myhost.com:/home/mikedd/temp-site What is the difference between site:deploy ad site:stage-deploy? Is it just a matter of which location it gets deployed to? What's with the myserver::default:: syntax? Thanks, -Patrick On Jul 21, 2008, at 8:48 AM, Michael Dick wrote: > Hi, > > I gave this a quick test and it looks like it's working, here's > exactly what > I ran : > > $ mvn -Dmaven.test.skip=true deploy > -DaltDeploymentRepository=myserver::default::scp:// > myserver.myhost.com/home/mikedd/temp22 > > $ mvn -Dmaven.test.skip=true site:stage-deploy > -DstagingSiteURL=scp://myserver.myhost.com:/home/mikedd/temp-site > > I think a similar set of arguments can be used for the release > process. > > Here's what I propose, after the 1.0.3 release is approved I'll > update the > pom.xml files for 1.0.x and 1.2.x (1.1.x too if you approve). The > changes > will be to update the default deploy location to be > openjpa.apache.org/builds/latest/${version} (or something similar). > That way > the automated build system will go ahead and publish to the latest > directory > with no need for command line arguments. > > In the release profile we'll change the deployment location to be > people.apache.org/${user}/public_html/. . . so that the release is > publicly > available. If we can't override the location via the profile I'll > update the > instructions to pass it along as a command line arg. > > If this sounds acceptable to everyone else I'll go ahead and open > another > JIRA (633 has enough changes). > > -mike > > > > > On Sat, Jul 19, 2008 at 11:53 AM, Michael Dick <mikedd@...> > wrote: > >> Hi Patrick, >> >> If you're looking to upload a snapshot to say your home directory on >> people.apache.org you can just run >> $ mvn deploy >> >> I think we'd rather have the snapshots deployed to our builds >> directory though. Something like this should work (untested) >> $ mvn -DaltDeploymentRepository=people.apache.org::default:scp:// >> people.apache.org/www/openjpa.apache.org/builds/${version}<http://people.apache.org/www/openjpa.apache.org/builds/$%7Bversion%7D >> > >> deploy >> >> You'll need to add a server tag for people.apache.org to your >> ${home}/.m2/settings.xml file. Something like this should work: >> >> <servers> >> <server> >> <id>people.apache.org</id> >> <username>[your apache id]</username> >> <passphrase>[secret passphrase]</passphrase> >> <filePermissions>664</filePermissions> >> <directoryPermissions>775</directoryPermissions> >> </server> >> </servers> >> >> The preceding examples will upload our maven artifacts. To deploy the >> site I *think* this would work >> >> $ mvn -DstagingSiteURL=scp:// >> people.apache.org/www/openjpa.apache.org/builds/${version} >> site:stage-deploy<http://people.apache.org/www/openjpa.apache.org/builds/$%7Bversion%7Dsite:stage-deploy >> > >> >> I'll take a closer look when time permits, this should be a starting >> point though. >> >> -mike >> >> On Fri, Jul 18, 2008 at 5:56 PM, Patrick Linskey <plinskey@...> >> wrote: >>> >>> Hi, >>> >>> I'm trying to get the snapshot process working as closely to the new >> release process as possible. From what I can tell, mvn >> release:prepare is >> really oriented towards releases, not towards snapshots. Does >> anyone know of >> an equivalent snapshot target that we could use? >>> >>> -Patrick >>> >>> On Jul 16, 2008, at 7:06 AM, Kevin Sutter wrote: >>> >>>> Sounds good, Patrick. So, in the mean time, should I make a >>>> temporary >>>> repository for the "latest" docs? Or, if you think this will get >> resolved >>>> in the next day or two, then I could just wait. >>>> >>>> Thanks, >>>> Kevin >>>> >>>> On Tue, Jul 15, 2008 at 6:40 PM, Patrick Linskey <plinskey@... >>>> > >> wrote: >>>> >>>>> Hi, >>>>> >>>>> I think that this is because the machine that builds and uploads >>>>> the >>>>> snapshots was offline for the last couple of months. I got that >> partially >>>>> back up and running last week, and hope to get the snapshots >>>>> uploading >> again >>>>> later this week. >>>>> >>>>> -Patrick >>>>> >>>>> >>>>> On Jul 15, 2008, at 5:30 PM, Kevin Sutter wrote: >>>>> >>>>> Hi, >>>>>> >>>>>> I just noticed that our links for the "latest" OpenJPA >>>>>> documentation >> is >>>>>> out >>>>>> of date (http://cwiki.apache.org/openjpa/documentation.html). I >> would >>>>>> expect that our "latest" link should point at some version of >>>>>> documentation >>>>>> associated with trunk. But, it's currently pointing at some >>>>>> version >> based >>>>>> on the 1.1.0 build. I was going to go ahead and clean this up, >>>>>> but it >>>>>> looks >>>>>> like I don't have proper authority to the /www/ >>>>>> openjpa.apache.org/docs/latest directory. It looks like >>>>>> Patrick is >> the >>>>>> only >>>>>> one with enough authority. >>>>>> >>>>>> This "latest" directory is currently linked to this: latest -> >>>>>> ../builds/1.1.0/apache-openjpa-1.1.0/docs/ >>>>>> >>>>>> So, I'm thinking a few things need to be done: >>>>>> >>>>>> o It would be great to post our current nightly drivers and >> documentation >>>>>> out on people.apache.org from our TC system. (BTW, it looks >>>>>> like our >>>>>> nightly drivers page is still pointing at the 1.1.0 SNAPSHOT >>>>>> builds, >> so we >>>>>> have some clean up there as well.) I'm not sure on the status of >>>>>> Patrick's >>>>>> TC system and whether we are able to get something like this >>>>>> setup or >> not. >>>>>> >>>>>> o If we can post our nightly drivers and documentation, then >>>>>> we could >>>>>> change this "latest" directory link to our upload location for >>>>>> the >>>>>> drivers. >>>>>> >>>>>> o If this type of clean up and setup of nightly drivers is >>>>>> going to >> take >>>>>> some time, then at a minimum, it would be good to change the >> permissions >>>>>> on >>>>>> this "latest" directory so that we could do some manual (pardon >>>>>> the >> pun) >>>>>> cleanup. >>>>>> >>>>>> BTW, all of this came about because I had pointed a user at our >> "latest" >>>>>> manual to find out how to turn on the Query SQL Cache support >>>>>> (knowing >> it >>>>>> was part of the 1.2.0 trunk release). But, I soon discovered >>>>>> that our >>>>>> "latest" manual is quite out of date... :-) >>>>>> >>>>>> Thanks, >>>>>> Kevin >>>>>> >>>>> >>>>> -- >>>>> Patrick Linskey >>>>> 202 669 5907 >>>>> >>>>> >>> >>> -- >>> Patrick Linskey >>> 202 669 5907 >>> >> Patrick Linskey 202 669 5907 |
||||||||
|
|
|
||||||||
|
|
| ||||||||