Thanks for the details. I've re-organized the issue I pointed to earlier into some manageable sub-tasks, at least one of which I think we can get done for 3.6 -- starting to deploy all artifacts to central via sonatype as part of the release process:
https://jira.duraspace.org/browse/FCREPO-1014 I also folded your pom changes into my working copy to test what you did, and was able to successfully deploy 3.6-SNAPSHOT to sonatype. I'm generally happy with the approach you've used, and I fully support your pushing your 3.5 artifacts to central under the org.fcrepo artifactid. Once you've done that and requested the central sync for org.fcrepo, we can start doing it as a matter of course. - Chris On Tue, Oct 18, 2011 at 6:16 PM, Greg Pendlebury <[email protected]> wrote: > Thanks Chris, > > Yes they were just POM changes. Just the new parent as you noted: > <parent> > <groupId>org.sonatype.oss</groupId> > <artifactId>oss-parent</artifactId> > <version>7</version> > </parent> > > And a new build profile (copied and modified from the existing one) to > isolate the changes to one location and prevent them from triggering under > the wrong circumstances... not that that would be a problem, it's just > source JARs and javadoc JARs being built. The delay involved in building > them was why I isolated them: > <profile> > <id>sonatype-release</id> > <build> > <plugins> > <!-- sign each artifact with a pgp key --> > <plugin> > <groupId>org.apache.maven.plugins</groupId> > <artifactId>maven-gpg-plugin</artifactId> > <executions> > <execution> > <id>sign-artifacts</id> > <phase>verify</phase> > <goals> > <goal>sign</goal> > </goals> > </execution> > </executions> > </plugin> > > <!-- Generate javadoc JARs --> > <plugin> > <groupId>org.apache.maven.plugins</groupId> > <artifactId>maven-javadoc-plugin</artifactId> > <version>2.6.1</version> > <executions> > <execution> > <id>attach-javadocs</id> > <goals> > <goal>jar</goal> > </goals> > </execution> > </executions> > </plugin> > > <!-- Generate source JARs --> > <plugin> > <groupId>org.apache.maven.plugins</groupId> > <artifactId>maven-source-plugin</artifactId> > <executions> > <execution> > <id>attach-sources</id> > <goals> > <goal>jar</goal> > </goals> > </execution> > </executions> > </plugin> > > </plugins> > </build> > </profile> > > Then run: > mvn clean > mvn -P sonatype-release deploy > > This leaves them (after closing the repo) sitting in the staging repository > already linked, and I can build using them from there until they finish > public inspection and get properly released to Central. > > So if you're generally happy with this I will release them then. I have no > urgency as long as I can develop against the staging repo, so I'm happy to > wait a couple of days if anyone wants to check them. > > Ta, > Greg > > On 18 October 2011 21:44, Chris Wilper <[email protected]> wrote: >> >> Greg, >> >> There's been a long-standing desire (but not so much time) to start >> hosting all the org.fcrepo artifacts at Sonatype, and eventually sync >> to central[1]. One of the assumptions we've had (I've had) about >> Sonatype hosting is that they've become a lot more strict about >> non-central dependencies. So it's seemed like an arduous process to >> get all our dependencies in order beforehand, which is why it hasn't >> happened yet. >> >> If that's not the case, then personally, I'd be happy with you >> publishing your build of the 3.5 artifacts to central under the >> org.fcrepo groupId as long as they're digitally signed by you (which >> it looks like they are) and you didn't make any non-pom changes to the >> code before doing your build (I assume that's true?). Until we start >> doing it as part of the release process, it seems like that's going to >> make your life (and other developers' lives) easier. >> >> Btw, I noticed the sonatype-oss-parent change in the root pom. Were >> there other changes that allowed to you build and upload all the >> artifacts via mvn, or did you manually build and upload them? If the >> former, can you describe what you did? The sooner we can integrate >> automatic publishing of our artifacts to central with our release >> process, the better. >> >> Thanks, >> Chris >> >> [1] https://jira.duraspace.org/browse/FCREPO-825 >> >> On Tue, Oct 18, 2011 at 12:20 AM, Greg Pendlebury >> <[email protected]> wrote: >> > For my testing today I released the artifacts to a Sonatype staging >> > repository: >> > https://oss.sonatype.org/content/repositories/orgfcrepo-409/org/fcrepo/ >> > >> > So far things seem to be going ok for my testing, and I'm currently >> > coding >> > against this. Are there any objections to be synching this with Central? >> > The >> > alternative is I could release them under our own group ID, but I'd >> > prefer >> > to use the correct 'org.fcrepo' GID unless there are objections. >> > >> > Ta, >> > Greg >> > >> > On 18 October 2011 08:48, Greg Pendlebury <[email protected]> >> > wrote: >> >> >> >> Thanks for the reply Edwin, >> >> >> >> I was more thinking of the artifact from inside the codebase: >> >> <groupId>org.fcrepo</groupId> >> >> <artifactId>fcrepo-client</artifactId> >> >> <version>3.5</version> >> >> >> >> Or this one: >> >> <groupId>org.fcrepo</groupId> >> >> <artifactId>fcrepo-client-admin</artifactId> >> >> <version>3.5</version> >> >> >> >> Unfortunately I've never heard of the 'com.mediashelf' version, but I >> >> don't lurk in the Fedora community very often. How does it differ from >> >> the >> >> client in the 'core' code? >> >> >> >> Maven Central does not require all dependencies to also be hosted there >> >> (although it is their preference), as per >> >> >> >> https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide >> >> >> >> I'm of the opinion that is far better to start getting something into >> >> Maven Central and work on the dependencies later then to hold >> >> everything >> >> outside and make it hard to get to... but of course that is just my >> >> little >> >> old opinion. >> >> >> >> If this is the only hold up is there any objection to me pushing the >> >> v3.5 >> >> artifacts into Central? The POMs look like they are well fleshed out >> >> and >> >> ready to go. >> >> >> >> Ta, >> >> Greg >> >> >> >> On 18 October 2011 02:38, Edwin Shin <[email protected]> wrote: >> >>> >> >>> Greg, >> >>> >> >>> Pardon my jet-lag, I had assumed you were talking about the >> >>> fedora-client >> >>> library at https://github.com/mediashelf/fedora-client >> >>> >> >>> On 16 Oct 2011, at 8:55 PM, Greg Pendlebury wrote: >> >>> >> >>> > Hello again, >> >>> > >> >>> > I started looking at later versions today. I've currently got v3.3, >> >>> > v3.3.1, v3.4.2 and v3.5 all running happily on my laptop. Some >> >>> > testing >> >>> > various permutations of compatibility makes me tentatively confident >> >>> > I can >> >>> > get the functionality required just from using the latest v3.5 >> >>> > client. >> >>> > >> >>> > I may be blind however, because I can't seem to find the Maven >> >>> > artifacts anywhere. From the project's root POM I expected they >> >>> > might be >> >>> > somewhere in the Duraspace repo: >> >>> > https://m2.duraspace.org/content/repositories/releases/org/fcrepo/ >> >>> > >> >>> > But there are no fedora artifacts there that I can see. I also can't >> >>> > see any under Maven central ('fedora-common', 'fcrepo' isn't there >> >>> > at all): >> >>> > http://search.maven.org/#browse|-924277200 >> >>> > >> >>> > There is a ticket for fedora to synch with central under >> >>> > 'org.fcrepo': >> >>> > https://issues.sonatype.org/browse/OSSRH-307 but no artifacts.. are >> >>> > they >> >>> > hosted anywhere? >> >>> > >> >>> > Ta, >> >>> > Greg >> >>> > >> >>> > On 14 July 2011 09:25, Greg Pendlebury <[email protected]> >> >>> > wrote: >> >>> > Hey All, >> >>> > >> >>> > I'm trying to get the Fedora Client available as a Maven dependency >> >>> > for >> >>> > our software to make use of in talking to Fedora repositories. >> >>> > >> >>> > The first version I was looking for was v2.2.4, which uses the old >> >>> > ant >> >>> > builds. I've built a bundle as per: >> >>> > http://code.google.com/p/redbox-mint/wiki/BuildingFedoraClient >> >>> > >> >>> > and it is available here: >> >>> > >> >>> > http://code.google.com/p/redbox-mint/downloads/detail?name=fcrepo-client-2.2.4-bundle.jar >> >>> > >> >>> > But wanted to check on a few thing: >> >>> > • I can't upload this to Sonatype since I'm not a member of >> >>> > your >> >>> > community (as per: https://issues.sonatype.org/browse/OSSRH-1942). >> >>> > • Does anyone object to me building in this way? Or the >> >>> > contents >> >>> > of the POM (such as your dev details, which I grabbed from the >> >>> > wiki/web >> >>> > where I could find them)? >> >>> > • Are the GAV details correct? I originally went for >> >>> > org.fedora-commons:fedora-client:2.2.4, but after looking at later >> >>> > versions >> >>> > (see below) I switched to org.fcrepo:fcrepo-client:2.2.4 - Is there >> >>> > any >> >>> > preference? >> >>> > • Can either A) someone with authority upload this bundle for >> >>> > me? >> >>> > or B) allow me access (presumably via Sonatype) to upload? >> >>> > >> >>> > Next I moved on to v3.3.1, which one of our clients has indicated >> >>> > they >> >>> > will soon be migrating to. I haven't started on this one yet, so >> >>> > some of >> >>> > these questions will just be me trying to sort out some confusion: >> >>> > • The src.zip link from here is broken: >> >>> > http://www.fedora-commons.org/software/repository/v_3_3_0 Although I >> >>> > did >> >>> > look around and find: >> >>> > http://sourceforge.net/projects/fedora-commons/files/fedora/3.3/ >> >>> > • The location above had only a jar file listed for v3.3.1 and >> >>> > seemed to relate only to the server (I didn't try using it though). >> >>> > I assume >> >>> > this is not big deal and the client is compatible? >> >>> > • After grabbing the v3.3 source I was happy to note the Maven >> >>> > build and adjusted my 2.2.4 GAV to match, but the build process >> >>> > fails since >> >>> > it appears the fedora-commons.org maven repository is defunct. >> >>> > • I can't find any publicly available artifacts in either >> >>> > Maven >> >>> > Central or the Duraspace repo that match the GAV details from the >> >>> > v3.3 POMs, >> >>> > are these available somewhere? >> >>> > • Failing this I thought I could either go through the pain of >> >>> > building up all the v3.3 dependencies and releasing them (ouch), or >> >>> > move to >> >>> > the current versions and pray they are compatible for a v3.3.1 >> >>> > server... any >> >>> > advice on the more likely route to success? >> >>> > Apologies for the wall of text in this post, but I'm mainly looking >> >>> > for >> >>> > information/authorization. I'm happy to do any/all dev work involved >> >>> > if it >> >>> > falls in line with community expectations. >> >>> > >> >>> > Ta, >> >>> > Greg >> >>> > >> >>> > >> >>> > >> >>> > ------------------------------------------------------------------------------ >> >>> > All the data continuously generated in your IT infrastructure >> >>> > contains >> >>> > a >> >>> > definitive record of customers, application performance, security >> >>> > threats, fraudulent activity and more. Splunk takes this data and >> >>> > makes >> >>> > sense of it. Business sense. IT sense. Common sense. >> >>> > >> >>> > >> >>> > http://p.sf.net/sfu/splunk-d2d-oct_______________________________________________ >> >>> > Fedora-commons-developers mailing list >> >>> > [email protected] >> >>> > >> >>> > https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers >> >>> >> >>> >> >>> >> >>> >> >>> ------------------------------------------------------------------------------ >> >>> All the data continuously generated in your IT infrastructure contains >> >>> a >> >>> definitive record of customers, application performance, security >> >>> threats, fraudulent activity and more. Splunk takes this data and >> >>> makes >> >>> sense of it. Business sense. IT sense. Common sense. >> >>> http://p.sf.net/sfu/splunk-d2d-oct >> >>> _______________________________________________ >> >>> Fedora-commons-developers mailing list >> >>> [email protected] >> >>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers >> >> >> > >> > >> > >> > ------------------------------------------------------------------------------ >> > All the data continuously generated in your IT infrastructure contains a >> > definitive record of customers, application performance, security >> > threats, fraudulent activity and more. Splunk takes this data and makes >> > sense of it. Business sense. IT sense. Common sense. >> > http://p.sf.net/sfu/splunk-d2d-oct >> > _______________________________________________ >> > Fedora-commons-developers mailing list >> > [email protected] >> > https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers >> > >> > >> >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure contains a >> definitive record of customers, application performance, security >> threats, fraudulent activity and more. Splunk takes this data and makes >> sense of it. Business sense. IT sense. Common sense. >> http://p.sf.net/sfu/splunk-d2d-oct >> _______________________________________________ >> Fedora-commons-developers mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2d-oct > _______________________________________________ > Fedora-commons-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers > > ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ Fedora-commons-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
