Well if you think this is just bureaucracy
<http://dict.leo.org/ende/index_de.html#/search=bureaucracy&searchLoc=0&resultOrder=basic&multiwordShowSingle=on>
ask https://github.com/gpetracek or the other 15 contributors to
DeltaSpike:
https://github.com/apache/deltaspike/tree/master/deltaspike
Gerhard works at IRIAN, a JSF company also involved in a couple of other
projects like MyFaces. IRIAN hosted the stage where I presented DeviceMap
on JavaLand, and I just had a chat with former DeltaSpike lead Mark
Struberg in Vienna about DeltaSpike, CDI and some licensing issues.
If you want to know why DeltaSpike not only has a "master" POM but a
dedicated "parent" pom (both derived from subsequent Apache parent POMs)
ask them how they do it and avoid solo stuff like you tend to play here.
DeltaSpike also has "examples" something notably missing from the Apache
SVN repo.
Now I am responsible and taking care of modules initially contributed by
OpenDDR, and a proper integration into the Apache and DeviceMap ecosystem
like using the right parent POM, etc. was done initially by Bertrand and I
picked that up where he didn't have time over the months. This exists since
early 2013, mainly adjusted and tweaked by Bertrand in case of the
"classifier" module.
That had a proper
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.apache</groupId>
<artifactId>apache</artifactId>
<version>9</version>
<relativePath/>
</parent>
And contrary to a recent commit comment that never broke a build, nor using
the "java-parent" pom as a mid layer instead.
Bertrand also proposed a more "OSGi" like naming, which did not bother, you
completely reversed that without asking or creating a JIRA ticket (or where
is that?)
Now that is a naming detail I personally don't worry that much about.
Eclipse uses OSGi bundles, but most other project, even OSGi enabled Apache
projects like DeltaSpike are fine with an artifactId like "deltaspike-core"
or similar.
Even being used to develop in a single office or at home on your own most
of the time, doesn't mean throwing somthing into a larger ecosystem that
breaks everything else put up by the mentors or project leads before is how
you should work here. Or in any other Open Source community. DeltaSpike
also has an "examples" module like the one still empty here. Instead there
is something on GitHub or elsewhere it seems, you develop there on your
own, but under "org.apache.devicemap".
This is something you need to contribute, but if there isn't a "1.0.0"
example demonstrating how the "1.0.0" client works, then it seems
incomplete or fragmented[?]
Werner
On Thu, Jul 10, 2014 at 3:51 AM, Reza <[email protected]>
wrote:
> Fine, make the changes, you are obviously the expert here. This is your
> release and project now. How you completely asserted control of this
> project in the last 2 days is simply amazing.
>
>
>
> ------------------------------
> *From:* Werner Keil <[email protected]>
> *To:* "[email protected]" <
> [email protected]>; Reza <[email protected]>
> *Sent:* Wednesday, July 9, 2014 9:45 PM
> *Subject:* Re: release
>
> 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-----
> >>
> >
> >
>
>
>
>
>
