openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Linskey <plins...@gmail.com>
Subject Re: snapshot process (was: Re: Documentation links and content "out of date")
Date Tue, 22 Jul 2008 22:53:01 GMT
> $ 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.

I've got changes to the trunk pom.xml that does something much like  
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@apache.org>  
> 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@gmail.com>
>> 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@gmail.com 
>>>> >
>> 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


Mime
View raw message