Please cut the crap. The "official" release was broken, i.E. the version of the XML was wrong not matching what the tag was intended to be, etc. As mentioned, I am the person eligable to do this with the contribution from OpenDDR. So please Bertrand, if there is a way to restrict certain users from SVN, do this accordingly so that wrongful commits to this tree by Reza or others cannot happen any more[?]
Also note, the parent hierarchy of the POMs is inconsistent. "classifier" not only differs from the POM artifactId (bad but if you don't want to change it, keep it for now, just don't change the artifactId any more after a release) it is an "orphan" without a proper parent[?] Go look at all the other Maven built projects, e.g. Jackrabbit (as this is an RI for a JSR I'm also on I know a bit about it) All modules including https://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-data/pom.xml contain a proper <!-- ====================================================================== --> <!-- P R O J E C T D E S C R I P T I O N --> <!-- ====================================================================== --> <parent> <groupId>org.apache.jackrabbit</groupId> <artifactId>jackrabbit-parent</artifactId> <version>3.0-SNAPSHOT</version> <relativePath>../jackrabbit-parent/pom.xml</relativePath> </parent> <artifactId>jackrabbit-data</artifactId> <name>Jackrabbit Data</name> <description>Jackrabbit DataStore Implentations</description> <packaging>bundle</packaging> You defrauded the "classifier"/"client" module from this sanity, and deleted a proper parent which never caused a build to break, so if you want to have a proper Maven project here, could you please fix this before tagging[?] The parent pom in Jackrabbit's case uses this <!-- =================================================================== --> <!-- P R O J E C T D E S C R I P T I O N --> <!-- =================================================================== --> <parent> <groupId>org.apache</groupId> <artifactId>apache</artifactId> <version>10</version> <relativePath /> </parent> Our parent poms (there should ideally be only one in the devicemap root, but given there's a .NET module with no great use for Maven having one for /trunk/data/device-data or /trunk/data and another for /trunk/devicemap/java seems acceptable) have been adjusted to the latest Apache Master POM version 14. This much like all the projects at JBoss, java.net or Eclipse controls global dependencies and makes sure you have the right set of plugins for a particular project. E.g. the "classifier" deviating from that practice makes it use a different compiler version than the rest. 3.1 is the recent one for Apache 14, you use 3.0 and like with the other POMs don't even know what's there it seems. That's why this is centrally maintained in larger projects[?] Can you please use either the correct java-parent or at least <parent> <groupId>org.apache</groupId> <artifactId>apache</artifactId> <version>14</version> <relativePath /> </parent> Cheers, Werner On Thu, Jul 10, 2014 at 3:15 AM, Reza <[email protected]> wrote: > Just an FYI, what you tagged does not match what I was planning on > releasing. You made 2 commits after my release: > > > http://svn.apache.org/viewvc/incubator/devicemap/trunk/data/device-data/pom.xml?view=log > > > You have made numerous commits after my release which pretty much amount > to nothing except changing around files, changing fields in the pom, > breaking the build, and breaking the release. I have yet to see a single > line of code contributed. If you aren't contributing code, then don't play > around in the codebase. > > Bertrand, is it possible to have commits go into a feature branch and have > the release manager merge commits into trunk, release, and make the tag? > Ie: can we restrict svn access for certain users? > > > ________________________________ > From: Werner Keil <[email protected]> > To: "[email protected]" < > [email protected]> > Sent: Wednesday, July 9, 2014 8:37 PM > Subject: Re: release > > > Hi, > > I tagged the devicemap-data content after getting version and other > meta-data corrected: > https://svn.apache.org/repos/asf/incubator/devicemap/tags/data/1.0.0 > > The structure underneath is like the latest "openddr" tags, so in theory we > may add "test-data" to it if it still applies, otherwise to another > release. > Have a look at how you want to tag the > https://svn.apache.org/repos/asf/incubator/devicemap/tags/devicemap > subtree. > > Either using the "java" and other folders or putting all of them under a > common "1.0.0" release. Or adding a prefix like "java-", "vb-", etc. before > the 1.0.0. > > Werner > > > On Thu, Jul 10, 2014 at 12:47 AM, Werner Keil <[email protected]> > wrote: > > > SVN tags here > > https://svn.apache.org/repos/asf/incubator/devicemap/tags/devicemap > > > > The name space is up to how we want to do this underneath each > "component" > > (hence the suggestion someone who can do this in JIRA might add actual > > components for "Java", ".NET" or VB/CSharp and "Data", so far only > Bertrand > > and for some credentials like change assigneee Reza are in the right > > group/role) > > > > "data" had a snapshot for each OpenDDR update I synced. Reza missed 1.27, > > but as we plan to draft a 1.0.0 milestone release, that can be done via > the > > release tag anyway. > > So I'd do this for > > https://svn.apache.org/repos/asf/incubator/devicemap/tags/data/1.0.0 > > > > Ideally all other tags should be similar. The naming convention is > totally > > different for every single Apache project. > > > > For a "flat" structure using only the top-level "tags" folder, many > > projects chose something like /tags/devicemap-data-1.0.0. > > > > If you prefer, let's do that for ALL artifacts like that, otherwise just > > "1.0.0" or "v1.0.0" are the other patterns. See "CouchDB" using a simple > > "1.0.0", etc. "DeltaCloud" put a "release-" in front of every tag, so > there > > is no mandatory pattern by Apache Foundation, only a common agreement > > inside each team it seems... > > > > If we use the > > /tags/data > > /tags/devicemap > > > > structure, then either > > /tags/devicemap/java-1.0.0 > > /tags/devicemap/csharp-1.0.0 > > ... > > would work or > > /tags/devicemap/java/1.0.0 > > /tags/devicemap/csharp/1.0.0 > > > > I'll leave the decision in the .NET and Java corner to what we like best. > > > > I used "v1.x" under /data/openddr to match the exact same tag OpenDDR > used > > in Git. > > No distinct preference here, but for /tags/data will do a simple 1.0.0 > for > > now. > > As of now, "test-data" did not seem in the archive, and you did not sound > > too eager to include it with a 1.0.0 release right now, is that correct? > > > > Werner > > > > On Wed, Jul 9, 2014 at 11:56 PM, eberhard speer jr. <[email protected]> > > wrote: > > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> Ooops, lost me there "tagged" ? > >> > >> esjr > >> -----BEGIN PGP SIGNATURE----- > >> Version: GnuPG v1.4.8 (MingW32) > >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > >> > >> iQEcBAEBAgAGBQJTvbqXAAoJEOxywXcFLKYctb4H/RJwOLzIjoFKcvRQIkN04uZC > >> DjJGSayj8youkYwAMLY9AsM67osZfJkn0gCiXf+5Phpk5K9/PUJ5Qz8x3x5iizGe > >> a/CQUXuVNyt/zRHXwc85lzuN+6FfC5uGsMGtbDFnf6Wm0ijBfEy3FZBAhHmdZFqB > >> X774m9mI3URQWgqysoiip6UwZ64QKWdLth4KK0Ivyu02iMCwpQey5fWNgCIUvlp0 > >> c8SlkfvLy+n7xMEAQCjfgbh6E778tng7S2Ukurtowyfz83c/tyi/L/n+abEBEjMR > >> F1OkW/SmJZZ3H9Skocq8G78PoCelWzd3JeAlJlmwTS10agF18kEAtJ9oEq67k3I= > >> =e42w > >> -----END PGP SIGNATURE----- > >> > > > > >
