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]] On Behalf Of Marcel Offermans Sent: vrijdag 3 februari 2012 10:25 To: [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.commons.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] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
