Re: Source Repository Organization and Release Strategy Thoughts
On Jul 29, 2006, at 7:30 PM, Sean Schofield wrote: Is Shale a sourceforge project? http://sourceforge.net/projects/shale Looks like a graphical file mgr for Linux :-) And it appears to be orphaned. At least there's nothing there. Greg
Re: Source Repository Organization and Release Strategy Thoughts
I was also going to suggest just shipping this one as source. We will have to exclude the the incompatibly licensed dependencies from the default build, which means 'mvn install' would still build a war that doesn't work. (Back to that 'reading the directions' thing again. :) ). But 'mvn install -Phibernate' would. Why do we have to exclude the incompatible licenses from the default build? That seems like a strange requirement. If it is in fact a requirement, we should be working to get it changed. What about a java.net project instead? Also, can we host the full app on our zone? Wendy Sean
Re: Source Repository Organization and Release Strategy Thoughts
Why is CDDL an issue? That was on Cliff's list of acceptable licenses. I wasn't sure which licenses were cool and which weren't. Google also just announced that they're going to do hosting of open source prrojects[1]. They are in the early days (don't even have infrastructure in place for downloading releases yet), but it has some interesting ideas. If you like labels in GMail, you'll like their approach to issue tracking. (By the way, Greg Stein is the engineering manager at Google for this project.) I really like JIRA but I'd be curious to see what their alternative for issue tracking is. My instinct is to stick with a more established host since we'd like this to be available and we'd like it to be easy for people to access it. I'm not wild about Sourceforge. What do you think about java.net? I'm sure you investigated it when you were considering Shale options. By the way, are you aware of any Apache restrictions on using depedencies like Hibernate in Maven? It seems like excluding them from the default build would be a idiotic policy. With everyone switching to Maven now, it would just push projects that want to use Maven right out of the ASF. I tried to register shale as a project, but they've got an interesting twist in the signup process ... if you duplicate the name of an existing SourceForge project, they ask the owner of that project for an ok (on the theory that you might just be trying to do a land grab on the project names. We could undoubltedly do shale-goodies or shale-petstore or whatever there, if we wanted. Is Shale a sourceforge project? Craig Sean
Re: Source Repository Organization and Release Strategy Thoughts
They will land in the top directory of the artifact. That's how we
do it for the struts1 stuff now.
--
James Mitchell
On Jul 23, 2006, at 8:02 PM, Craig McClanahan wrote:
On 7/23/06, James Mitchell [EMAIL PROTECTED] wrote:
I like to keep them (LICENSE.txt and NOTICE.txt) under:
${project}/src/main/resources
... so that they will, by default, make it into the package (jar/war/
whatever) without requiring any special copying or resource
inclusions.
Works for me as long as they end up in the top-level directory of the
resulting artifact (which they should, if you don't put them in
subdirectories inside /src/main/resources).
--
James Mitchell
Craig
On Jul 20, 2006, at 7:33 PM, Greg Reddin wrote:
On Jul 20, 2006, at 4:03 PM, Wendy Smoak wrote:
Ok, so we have framework/trunk/LICENSE.txt?
Sure. If that turns out to be wrong, we'll move it later. (Is
there
some reason you're concerned about this file?)
Nope, just that it and pom.xml were the only files under trunk that
didn't seem to have a natural home in my mind. (And NOTICE.txt now
that I look again.)
No biggie. We can move 'em if we don't like where they land.
Greg
Re: Source Repository Organization and Release Strategy Thoughts
I like to keep them (LICENSE.txt and NOTICE.txt) under:
${project}/src/main/resources
... so that they will, by default, make it into the package (jar/war/
whatever) without requiring any special copying or resource inclusions.
--
James Mitchell
On Jul 20, 2006, at 7:33 PM, Greg Reddin wrote:
On Jul 20, 2006, at 4:03 PM, Wendy Smoak wrote:
Ok, so we have framework/trunk/LICENSE.txt?
Sure. If that turns out to be wrong, we'll move it later. (Is there
some reason you're concerned about this file?)
Nope, just that it and pom.xml were the only files under trunk that
didn't seem to have a natural home in my mind. (And NOTICE.txt now
that I look again.)
No biggie. We can move 'em if we don't like where they land.
Greg
Re: Source Repository Organization and Release Strategy Thoughts
+1 for framework -- James Mitchell On Jul 18, 2006, at 12:19 AM, Craig McClanahan wrote: On 7/17/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 7/16/06, Craig McClanahan [EMAIL PROTECTED] wrote: Before doing so, it's probably worth spending some time figuring out how we want the source repository to be organized ... What do you think? I don't see the need to release things separately right now. Once again we have people asking for a shale-test release, and there have been enough changes in shale-core and shale-clay that it makes sense to go ahead and release the whole thing. For the examples, it seems like we would always want to update them to depend on the latest framework jars, so we might as well just version them together with the framework and release it all at once. Possibly... shale/framework/trunk/ shale/maven/trunk/ shale/sandbox/ The 'framework' directory could be called something else... I'd just as soon have shale/shale/trunk, but Ted says it will confuse viewvc. I can buy into framework at this level ... that's exactly the word I use after Shale to describe what it really is. Sandbox doesn't need trunk/branches/tags, you can just copy sandbox/projectA to sandbox/projectB if you want to try something else. Sounds good. The other consideration is that I can't modify the nightly builds script remotely until this coming Sunday night, so any changes we make in the next few days will temporarily break those. -- Wendy Craig
Re: Source Repository Organization and Release Strategy Thoughts
I like that organization. Keep it as simple as possible and expand on it if needed. Greg On Jul 17, 2006, at 10:11 PM, Wendy Smoak wrote: On 7/16/06, Craig McClanahan [EMAIL PROTECTED] wrote: Before doing so, it's probably worth spending some time figuring out how we want the source repository to be organized ... What do you think? I don't see the need to release things separately right now. Once again we have people asking for a shale-test release, and there have been enough changes in shale-core and shale-clay that it makes sense to go ahead and release the whole thing. For the examples, it seems like we would always want to update them to depend on the latest framework jars, so we might as well just version them together with the framework and release it all at once. Possibly... shale/framework/trunk/ shale/maven/trunk/ shale/sandbox/ The 'framework' directory could be called something else... I'd just as soon have shale/shale/trunk, but Ted says it will confuse viewvc. Sandbox doesn't need trunk/branches/tags, you can just copy sandbox/projectA to sandbox/projectB if you want to try something else. -- Wendy
