Hello,
I've attached the patches for the 1.4.x pom.xml and the trunk 1.5
pom.xml to the issue: (https://issues.apache.org/jira/browse/WICKET-2918)
I added the apache parent pom and then created a copy of the bamboo
profile minus the dependencyManagement section to let the definition
contained in the apache parent pom to be used.
I'm not totally clear at this point how the access credentials will work
but I think it should be the existing committer username/password
Essentially one username/password will have to be placed into a
settings.xml file that can be located relative to the workspace
directory within the hudson job that builds each version.
With the oss.sonatype.org repository I created a set of CI credentials
that were then granted permission to deploy a specific groupID
(org.wicketstuff) then I used a custom settings.xml file with those
credentials to line up with the <id/>tag of the snapshot repository
which allowed hudson to deploy the snapshots. In my hudson instance I
needed to use shell access to place the settings.xml file in the right
location.
The release repository is configured to use staging so when a release is
cut the deploy will upload into a temporary space within nexus.
The nexus username/password is used to authenticate and 'close' (a right
click menu option) the repository which makes the uploaded artifacts
available for download by those knowing the link. If the vote to
release is passed there is an option to 'promote' (another right click
menu item) the staged release which will then within an hour sync it up
with the central repository.
I think testing the nexus release mechanism should be doable before the
next release because it can be staged and if successful it can be dropped.
Regards,
Mike
I don't see a downside to extending the Apache parent pom.
Martijn
On Wed, Jun 16, 2010 at 4:35 AM, Michael O'Cleirigh
<michael.ocleir...@rivulet.ca> wrote:
)Jeremy Thomerson wrote:
On Tue, Jun 15, 2010 at 6:58 PM, James Carman
<ja...@carmanconsulting.com>wrote:
I believe that repository is for software published by the ASF, but I
could be wrong.
He wants us to deploy Wicket to it, so I think that fits the bill. :)
I'm +1 for this. I'll do the committer part with the help of Michael.
Let's see if anyone has an objection. Michael, could you open a JIRA for
this and attach a patch for our pom? If nobody has an objection, I'll
work
on it later in the week.
https://issues.apache.org/jira/browse/WICKET-2918
I've created an issue and will attach the modified pom's hopefully by
tomorrow. My thinking is that only future releases need to be handled so I
will create new snapshot and release profiles in the 1.4.x branch and the
1.5 trunk to handle the snapshots right now and to support the next
releases.
For the snapshots the apache build cluster job definition would need to be
modified with the appropriate server credentials to be able to deploy the
snapshot artifacts. I also found out that the nexus repository supports
auto removal of older snapshots (I think it will keep the last 3) and will
remove all the snapshots when a matching release is made. So the
<uniqueVersion>false<uniqueVersion> flag is no longer needed and apparently
maven 3.0 removes support for this tag anyways.
I've looked at a couple of the other apache projects that were setup to use
the apache nexus repository and most of the have a parent pom of the
org.apache.apache artifact version 7.
http://svn.apache.org/repos/asf/maven/pom/tags/apache-7/pom.xml
But I will try and figure out a profile that incorporates this definition
without needing the parent pom to be defined.
Also the ticket (https://issues.apache.org/jira/browse/INFRA-1896) asks that
sub issues include a link (like through nabble) to the vote on switching
over to the nexus managed repository.
Regards,
Mike
