Yes, that's an alternative. But in my opinion not a better one (as this is almost the current situation; update license headers, change package names, move the code to elsewhere and that would be it) . As I said, soon more artifacts will join this project and we would end up with some kind of shadow-Amdatu project. Is that really what we want?
Regards, Ivo -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jan Willem Janssen Sent: vrijdag 3 februari 2012 12:56 To: [email protected] Subject: Re: [Amdatu-developers] Subprojects that depend on sandboxes that have been released? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There's an alternative mentioned in one of the first mail: create an entirely separate project on Github/SF/... and release it yourself. On 2/3/12 12:46 PM, Ivo Ladage-van Doorn wrote: > I cannot remove anything before there is an alternative solution. > So far I didn?t hear an alternative to introducing an Amdatu Commons > subproject. I would be happy to discuss alternatives. > > > > Regards, Ivo > > > > *From:*[email protected] > [mailto:[email protected]] *On Behalf Of *Marcel > Offermans *Sent:* vrijdag 3 februari 2012 11:29 *To:* > [email protected] *Subject:* Re: [Amdatu-developers] > Subprojects that depend on sandboxes that have been released? > > > > Repeating myself: > > > > You cannot just release code in the subversion repository of Amdatu > (because either it is in a sandbox and you cannot release it at all, > or it is in an officially approved project, which "Amdatu Commons" is > not, so remove the releases and the dependencies. > > > > Greetings, Marcel > > > > > > On Feb 3, 2012, at 11:00 AM, Ivo Ladage-van Doorn wrote: > > > > Repeating myself; the source location of the artifact is irrelevant. I > do agree that using the references to Amdatu should be removed if we > do not move it to Amdatu (i.e. Amdatu Commons subproject), as I said > before. > > We should however be careful with moving artifacts to external repo?s > which we do develop for the benefit of Amdatu. As I said, I expect > much more of these artifacts to come, especially if we move to the new > platform version. Do we really want to introduce another external repo > just because we refuse to introduce an Amdatu Commons subproject? We > should acknowledge that there is an obvious need for a subproject like > this and come up with a solution. So far I didn?t hear an alternative > to the Commons subproject. > > > > Regards, Ivo > > > > *From:* [email protected] > <mailto:[email protected]> > [mailto:[email protected]] > <mailto:[mailto:[email protected]]> *On Behalf Of > *Marcel Offermans *Sent:* vrijdag 3 februari 2012 10:25 *To:* > [email protected] <mailto:[email protected]> > *Subject:* Re: [Amdatu-developers] Subprojects that depend on > sandboxes that have been released? > > > > Are you seriously arguing that it's fine to put arbitrary code in the > Amdatu subversion repository, use the Amdatu name and release it > without consulting anybody? > > > > I'm fine with you moving this code to sourceforge or github and > releasing it there on a personal title, provided that you do change > the name to not refer to Amdatu in any way, but as long as its in our > repository you should stick to the procedures we agreed upon. > > > > Greetings, Marcel > > > > > > On Feb 3, 2012, at 10:03 AM, Ivo Ladage-van Doorn wrote: > > > > > The origin of the artifact doesn?t matter. We use a whole bunch of > other artifacts, like json, gson, sf4j, log4j, shindig, cassandra, > oauth, commons-httpclient, commons-logging, etc. etc. We do not care > where the actual source code resides, we depend on their released > versions (and even shapshots; like pax useradmin > 0.0.1-SNAPSHOT) and if they are not available in some online mvn repo, > we add it to our mvn repo. This is exactly the case for this artifact; > you should see it as an external artifact used by us and deployed in > the amdatu mvn repo for convenience. It is not part of Amdatu so there > is nothing to discuss or vote about. > > Of course, since I created the artifact I added the amdatu license > header and used the amdatu package naming. This at least implies that > there is a link with Amdatu. I can change the license header and > rename the packages/artifact names if needed. > > We did have a discussion about the ?Amdatu Commons? subproject, and it > was obvious (as mentioned below) that we will not agree about its > need. Therefore this is the best alternative. > > > > Regards, Ivo > > > > *From:* [email protected] > <mailto:[email protected]> > [mailto:[email protected]] > <mailto:[mailto:[email protected]]> *On Behalf Of > *Marcel Offermans *Sent:* vrijdag 3 februari 2012 9:40 *To:* > [email protected] <mailto:[email protected]> > *Subject:* Re: [Amdatu-developers] Subprojects that depend on > sandboxes that have been released? > > > > My point is you should have discussed that before having projects > depend on code in your sandbox or releasing code in your sandbox. > > > > So undo these changes and releases and then start a proper discussion, > explaining us why you want an "Amdatu Commons" > subproject. If there is consensus, then we have to go to the board > (because they're the only ones who can formally approve that). > > > > For the record, in the platform we had a discussion about the > "utilities" that were used amongst different sub projects and decided > against those (see > http://jira.amdatu.org/jira/browse/AMDATU-264) so I don't think having > an "Amdatu Commons" subproject would be a good idea. > > > > Greetings, Marcel > > > > On Feb 3, 2012, at 9:14 AM, Ivo Ladage-van Doorn wrote: > > > > > > Hi Marcel, > > > > I agree that this is not an ideal situation, but there are currently > no alternatives. This particular bundle is shared among the > subprojects Big Data, OpenSocial and Auth. It is not part of these > subprojects and has an independent release cycle. With removing > various ?generic? bundles like this one from the platform in the > upcoming release, much more of these bundles will arise. > > So we need to think about how to deal with bundles like these. I > suggest to introduce an ?Amdatu Commons? subproject, an umbrella > project for generic bundles/utilities used by the subprojects but not > part of the platform. If such a subproject is available, I can move > the code from my sandbox to that subproject. Until then, it remains in > my sandbox. > > > > Regards, Ivo > > > > *From:* Marcel Offermans [mailto:[email protected]] > <mailto:[mailto:[email protected]]> *Sent:* donderdag 2 > februari 2012 17:44 *To:* [email protected] > <mailto:[email protected]> *Cc:* Ivo Ladage-van Doorn > *Subject:* Subprojects that depend on sandboxes that have been > released? > > > > Hello Ivo, > > > > I was highly surprised today that I could no longer build the trunk of > our OpenSocial project, even though the Bamboo build works. > > > > After some investigation, it turns out that OpenSocial depends on > something called > org.amdatu.commons:org.amdatu.commons.restdoclet:jar:1.0.3, which has > a package name that does not seem to belong to any of our subprojects, > nor is it part of the platform. After browsing around it seems to be > in your sandbox: > http://subversion.amdatu.org/viewvc/amdatu/sandbox/ivol/amdatu-commons > / > > > > > No project should ever depend on something in someone's sandbox. > > > > The next question was, why does Bamboo not fail. It seems that there > were even versions released from this sandbox, as can be seen here: > http://repository.amdatu.org/releases/org/amdatu/commons/org.amdatu.co > mmons.restdoclet/ > > > > > I don't remember us ever voting on any of those releases, nor did we > ever agree to even do releases from sandboxes (which makes no sense > whatsoever). > > > > Please: > > a) immediately remove all releases from that folder; > > b) remove all dependencies of OpenSocial on stuff in a sandbox. > > > > Greetings, Marcel > > > > _______________________________________________ Amdatu-developers > mailing list [email protected] > <mailto:[email protected]> > http://lists.amdatu.org/mailman/listinfo/amdatu-developers > > > > _______________________________________________ Amdatu-developers > mailing list [email protected] > <mailto:[email protected]> > http://lists.amdatu.org/mailman/listinfo/amdatu-developers > > > > _______________________________________________ Amdatu-developers > mailing list [email protected] > <mailto:[email protected]> > http://lists.amdatu.org/mailman/listinfo/amdatu-developers > > > > > > _______________________________________________ Amdatu-developers > mailing list [email protected] > http://lists.amdatu.org/mailman/listinfo/amdatu-developers - -- Met vriendelijke groeten | Kind regards Jan Willem Janssen | Software Architect +31 631 765 814 /My world is:/ Luminis Technologies B.V. IJsselburcht 3 6825 BS Arnhem +31 88 586 46 30 http://www.luminis-technologies.com http://www.luminis.eu KvK (CoC) 09 16 28 93 BTW (VAT) NL8169.78.566.B.01 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPK8tJAAoJEKF/mP2eHDc4Cy8P/j8DIandF2A+TJZoNskVSyOu uaYZS28oLoo0CeSZIxAlrNOAg7aIVWkN6F182upG3GE1D3JncI7bbbO70fTIlZ9q hnuETvM9C7sO+1DXnKzDAJLR0yE100U/p9RLNSvC+gGeTgQptOW5dbL1arCUWlAr ahsewvTAzd/dt0dzO4yZ91BJPq9gziZayRUeri634I4XHadWt+GFs6gG9CURlv8y otdr62ijnHjL1/V63jPiGNQh6itfOKIBbdcytckXzl/6+MnK/QrFc0zP1Mus5TmD xTXn6nDkzQzANlrNnfuzO1c/SWN40IsxrIuIwE5Y866YUO6Ba+Egs6GaJGQ5zycz h1HB/44HDlWKolef5t+n/c2BUP1DHoiY8uabbTcve+I6H17YR5IGNu/EmvbArKsz pHKS3TSokasoETXgHLCclKyTd2uGD33jdfMDon47AXaSznNBtklg5ZqW+a74aeWn um2B6mXrthdm3tv3nnavk8OJ/1RKg7aqGmC6C+oCl1Hs9yqQfOupvUsPz/LSa6b8 6Pgmpuh0JTPUsciR1n7s8bqYHATZwg9eMBBcG3QZLmnk0YhslrsyRiTrzhO7KiQa ftR5xexOa/u7dR4IV/9TTcC8uJG9funL6Qcw2hcHBKzvwrNO4yX+Z21Aoosc95h3 inWOtGEINgpZCOFT39ym =hlc0 -----END PGP SIGNATURE----- _______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers _______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
