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 14:33:58 GMT
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.

-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