openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Dick" <mik...@apache.org>
Subject Re: snapshot process (was: Re: Documentation links and content "out of date")
Date Wed, 23 Jul 2008 15:27:59 GMT
On Wed, Jul 23, 2008 at 9:33 AM, Michael Dick <mikedd@apache.org> wrote:

> On Tue, Jul 22, 2008 at 5:53 PM, Patrick Linskey <plinskey@gmail.com>
> wrote:
>
>>  $ 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.
>>
>
> Depends on the plugin ;-). I think we can request similar parameters to
> other plugins if we have a compelling use case(s).
>
>>
>>
>>  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}<http://openjpa.apache.org/builds/latest/$%7Bversion%7D>(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/<http://people.apache.org/$%7Buser%7D/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.
>>
>
> You're right that's probably safer. We should be able to specify the
> options in a <profile> in pom.xml. So the maven invocation would look like :
> $ mvn -Pnightly-build deploy
>
> $ mvn -Prelease release:prepare
> // etc.
>
>
>> 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-<http://people.apache.org/home/$%7Buser.name%7D/public_html/openjpa-staging->
>> repo
>> scp://people.apache.org/home/${user.name}/public_html/openjpa-staging-<http://people.apache.org/home/$%7Buser.name%7D/public_html/openjpa-staging->
>> site
>>
>
> I put the pom.version directory in the location to account for the corner
> case where a single release manager has published more than one version at
> the same time. For example if I had submitted a vote for 1.2.0 on Monday
> there would be 1.0.3 and 1.2.0 candidates in the same staging repository. At
> the end of the process when we run mvn stage:deploy I believe both versions
> would be copied to the ibiblio rsync repository.
>
> I think this is a known issue with the stage plugin which should be fixed
> in the near future, but with all the other changes for the release process I
> didn't want to add another point of failure.
>
> Admittedly this is a corner case, but once something is in the ibiblio
> repository it's very hard to remove it.
>

I didn't notice that you suggested removing the openjpa directory too. That
part seems OK with me, it's really only useful if you're releasing another
project at the same time.


>
> -mike
>
>
>> Thoughts?
>>
>> -Patrick
>>
>> [1] scp://people.apache.org/home/${user.name}/public_html/openjpa/$<http://people.apache.org/home/$%7Buser.name%7D/public_html/openjpa/$>
>> {pom.version}/
>>>
>>> staging-repo
>>> [2] scp://people.apache.org/home/${user.name}/public_html/openjpa/$<http://people.apache.org/home/$%7Buser.name%7D/public_html/openjpa/$>
>>> {pom.version}/staging-site
>>
>>
>
> On Wed, Jul 23, 2008 at 9:17 AM, Michael Dick <mikedd@apache.org> wrote:
>
>> Comments inline below
>>
>> On Tue, Jul 22, 2008 at 5:57 PM, Patrick Linskey <plinskey@gmail.com>
>> wrote:
>>
>>> 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?
>>>
>>
>> It's just a matter of where the site is deployed. The site:deploy goal
>> doesn't allow you to override the destination. We might be able to work
>> around this by using a variable in pom.xml to specify the site location, but
>> from what I've seen the release plugin expands many of the variables when
>> you do a release.
>>
>>
>>
>>>
>>> What's with the myserver::default:: syntax?
>>>
>>
>> The definition is ${serverId}::${layout}::${scp.location}. ServerId is a
>> server defined in .m2/settings.xml. Maven uses the server id to authenticate
>> and determine default file permissions, etc. Layout is used to differentiate
>> between a maven1 and maven2 repository (default is maven2).
>>
>> -Mike
>>
>>
>>> 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}<http://openjpa.apache.org/builds/latest/$%7Bversion%7D>(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/<http://people.apache.org/$%7Buser%7D/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>
>>>>> <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}<http://people.apache.org/www/openjpa.apache.org/builds/$%7Bversion%7D>
>>>>> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message