Re: [discuss] Organizing Wicket Stuff / Regular Release Schedule?
Great work! Its really looking good! Two more suggestions: 1. Add the maven-jetty-plugin the the root pom. It would be nice if 'mvn jetty:run' works for all the examples. 2. Remove all eclipse projects (.project .classpath) from svn and add the 'maven-eclipse-plugin' to the root project. I can make patches for these changes if you like... but i'm not totally clear on the etiquette for wicketstuff. Is someone (you?) allowed to apply a patch that affects build for many projects? ryan On Nov 30, 2008, at 1:16 AM, Jeremy Thomerson wrote: PS - Good suggestion - this was included. Take a look at: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core -- Jeremy Thomerson http://www.wickettraining.com On Tue, Nov 25, 2008 at 4:32 PM, Ryan McKinley [EMAIL PROTECTED] wrote: I don't know if this has already been discussed, but another part of the cleanup that would be nice is to group the main project and the example project into a folder with a common parent pom. For example, I find the layout of: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/inmethod-grid/ much easier to use/maintain then the apparent standard of /wicketstuff-project /wicketstuff-project-example https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push/ https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push-examples/ one key thing about this change is that mvn eclipse:eclipse makes the example project depend on the core project perhaps this could be added to the 'organize' task? ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [discuss] Organizing Wicket Stuff / Regular Release Schedule?
I agree with both of those. I'm not real sure either regarding the etiquette - that's been my dilemna throughout. That's the reason I started so many vote threads. I think both of those things would be acceptable, though. A common build setup was the goal of this. I'd like to also see us use a common version of many standard libraries at some point (commons, logging etc), but I don't think it's critical right this moment. At least they're all against a common Wicket version. If you supply a patch, I'll apply it. Or you can just do it if you want. You would be making sure each folder also had svn:ignore for .classpath, .project and target folder? Jeremy Thomerson http://www.wickettraining.com -- sent from a wireless device -Original Message- From: Ryan McKinley [EMAIL PROTECTED] Sent: Sunday, November 30, 2008 10:33 AM To: users@wicket.apache.org Subject: Re: [discuss] Organizing Wicket Stuff / Regular Release Schedule? Great work! Its really looking good! Two more suggestions: 1. Add the maven-jetty-plugin the the root pom. It would be nice if 'mvn jetty:run' works for all the examples. 2. Remove all eclipse projects (.project .classpath) from svn and add the 'maven-eclipse-plugin' to the root project. I can make patches for these changes if you like... but i'm not totally clear on the etiquette for wicketstuff. Is someone (you?) allowed to apply a patch that affects build for many projects? ryan On Nov 30, 2008, at 1:16 AM, Jeremy Thomerson wrote: PS - Good suggestion - this was included. Take a look at: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core -- Jeremy Thomerson http://www.wickettraining.com On Tue, Nov 25, 2008 at 4:32 PM, Ryan McKinley [EMAIL PROTECTED] wrote: I don't know if this has already been discussed, but another part of the cleanup that would be nice is to group the main project and the example project into a folder with a common parent pom. For example, I find the layout of: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/inmethod-grid/ much easier to use/maintain then the apparent standard of /wicketstuff-project /wicketstuff-project-example https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push/ https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push-examples/ one key thing about this change is that mvn eclipse:eclipse makes the example project depend on the core project perhaps this could be added to the 'organize' task? ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Organizing Wicket Stuff / Regular Release Schedule?
Check: http://wicketstuff.org/jira/browse/WSYUI-6 (YUI seemed like the best option... no 'core' project exists) This also adds a logging implementation so the tinymce-examples runs with jetty:run I don't have commit access on wicketstuff, so I can't directly apply the patch :) As for svn:ignore on the .classpath and .project... I think you need to first go through and delete the files, then add them to the ignore list. thanks! ryan On Nov 30, 2008, at 11:54 AM, Jeremy Thomerson wrote: I agree with both of those. I'm not real sure either regarding the etiquette - that's been my dilemna throughout. That's the reason I started so many vote threads. I think both of those things would be acceptable, though. A common build setup was the goal of this. I'd like to also see us use a common version of many standard libraries at some point (commons, logging etc), but I don't think it's critical right this moment. At least they're all against a common Wicket version. If you supply a patch, I'll apply it. Or you can just do it if you want. You would be making sure each folder also had svn:ignore for .classpath, .project and target folder? Jeremy Thomerson http://www.wickettraining.com -- sent from a wireless device -Original Message- From: Ryan McKinley [EMAIL PROTECTED] Sent: Sunday, November 30, 2008 10:33 AM To: users@wicket.apache.org Subject: Re: [discuss] Organizing Wicket Stuff / Regular Release Schedule? Great work! Its really looking good! Two more suggestions: 1. Add the maven-jetty-plugin the the root pom. It would be nice if 'mvn jetty:run' works for all the examples. 2. Remove all eclipse projects (.project .classpath) from svn and add the 'maven-eclipse-plugin' to the root project. I can make patches for these changes if you like... but i'm not totally clear on the etiquette for wicketstuff. Is someone (you?) allowed to apply a patch that affects build for many projects? ryan On Nov 30, 2008, at 1:16 AM, Jeremy Thomerson wrote: PS - Good suggestion - this was included. Take a look at: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core -- Jeremy Thomerson http://www.wickettraining.com On Tue, Nov 25, 2008 at 4:32 PM, Ryan McKinley [EMAIL PROTECTED] wrote: I don't know if this has already been discussed, but another part of the cleanup that would be nice is to group the main project and the example project into a folder with a common parent pom. For example, I find the layout of: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/inmethod-grid/ much easier to use/maintain then the apparent standard of /wicketstuff-project /wicketstuff-project-example https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push/ https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push-examples/ one key thing about this change is that mvn eclipse:eclipse makes the example project depend on the core project perhaps this could be added to the 'organize' task? ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Organizing Wicket Stuff / Regular Release Schedule?
PS - Good suggestion - this was included. Take a look at: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core -- Jeremy Thomerson http://www.wickettraining.com On Tue, Nov 25, 2008 at 4:32 PM, Ryan McKinley [EMAIL PROTECTED] wrote: I don't know if this has already been discussed, but another part of the cleanup that would be nice is to group the main project and the example project into a folder with a common parent pom. For example, I find the layout of: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/inmethod-grid/ much easier to use/maintain then the apparent standard of /wicketstuff-project /wicketstuff-project-example https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push/ https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push-examples/ one key thing about this change is that mvn eclipse:eclipse makes the example project depend on the core project perhaps this could be added to the 'organize' task? ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Organizing Wicket Stuff / Regular Release Schedule?
Merely bundling the examples with the code itself shouldn't cause this, do you think? On Wed, Nov 26, 2008 at 2:17 AM, Wayne Pope [EMAIL PROTECTED] wrote: YES. However I feel people may pass over the earlier branches (especially when we're on Wicket version 5.8!) and hence miss some great code that may not take much to get working and maintain on the newer branch. On Wed, Nov 26, 2008 at 2:06 AM, James Carman [EMAIL PROTECTED] wrote: Yes, our entire project at work is like this. The top-level project holds multiple modules. Each has a common, server, and client submodule. Works like a charm. On Tue, Nov 25, 2008 at 5:45 PM, Jeremy Thomerson [EMAIL PROTECTED] wrote: Great idea! Yes. I have not nested any projects three deep in the past, but it should work. Has anybody else tried this? It would be: wicket-stuff-parent -- wicket-foo -- wicket-foo-core -- wicket-foo-examples On Tue, Nov 25, 2008 at 4:32 PM, Ryan McKinley [EMAIL PROTECTED] wrote: I don't know if this has already been discussed, but another part of the cleanup that would be nice is to group the main project and the example project into a folder with a common parent pom. For example, I find the layout of: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/inmethod-grid/ much easier to use/maintain then the apparent standard of /wicketstuff-project /wicketstuff-project-example https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push/ https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push-examples/ one key thing about this change is that mvn eclipse:eclipse makes the example project depend on the core project perhaps this could be added to the 'organize' task? ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jeremy Thomerson http://www.wickettraining.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Organizing Wicket Stuff / Regular Release Schedule?
I think Wayne was referring not to your post, but in general - if we package most of the projects up neatly under one parent, then other projects that aren't in the same subdirectory / build cycle may get lost. I don't see this as too much of an issue - a project's visibility will come from a) it's documentation on wicketstuff.org or b) it's userbase talking about it on the user list. Typically, browsing the SVN tree isn't the way we find projects. -- Jeremy Thomerson http://www.wickettraining.com On Wed, Nov 26, 2008 at 7:10 AM, James Carman [EMAIL PROTECTED]wrote: Merely bundling the examples with the code itself shouldn't cause this, do you think? On Wed, Nov 26, 2008 at 2:17 AM, Wayne Pope [EMAIL PROTECTED] wrote: YES. However I feel people may pass over the earlier branches (especially when we're on Wicket version 5.8!) and hence miss some great code that may not take much to get working and maintain on the newer branch. On Wed, Nov 26, 2008 at 2:06 AM, James Carman [EMAIL PROTECTED] wrote: Yes, our entire project at work is like this. The top-level project holds multiple modules. Each has a common, server, and client submodule. Works like a charm. On Tue, Nov 25, 2008 at 5:45 PM, Jeremy Thomerson [EMAIL PROTECTED] wrote: Great idea! Yes. I have not nested any projects three deep in the past, but it should work. Has anybody else tried this? It would be: wicket-stuff-parent -- wicket-foo -- wicket-foo-core -- wicket-foo-examples On Tue, Nov 25, 2008 at 4:32 PM, Ryan McKinley [EMAIL PROTECTED] wrote: I don't know if this has already been discussed, but another part of the cleanup that would be nice is to group the main project and the example project into a folder with a common parent pom. For example, I find the layout of: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/inmethod-grid/ much easier to use/maintain then the apparent standard of /wicketstuff-project /wicketstuff-project-example https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push/ https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push-examples/ one key thing about this change is that mvn eclipse:eclipse makes the example project depend on the core project perhaps this could be added to the 'organize' task? ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jeremy Thomerson http://www.wickettraining.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Organizing Wicket Stuff / Regular Release Schedule?
On Wed, Nov 26, 2008 at 11:38 AM, Jeremy Thomerson [EMAIL PROTECTED] wrote: I think Wayne was referring not to your post, but in general - if we package most of the projects up neatly under one parent, then other projects that aren't in the same subdirectory / build cycle may get lost. I don't see this as too much of an issue - a project's visibility will come from a) it's documentation on wicketstuff.org or b) it's userbase talking about it on the user list. Typically, browsing the SVN tree isn't the way we find projects. Agreed! Now, the only issue is beefing up the documentation on wicketstuff.org. I've found that it's very difficult to find what I'm looking for up there.
Re: [discuss] Organizing Wicket Stuff / Regular Release Schedule?
On Wed, Nov 26, 2008 at 5:38 PM, Jeremy Thomerson [EMAIL PROTECTED] wrote: Typically, browsing the SVN tree isn't the way we find projects. Talk for yourself :) Martijn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Organizing Wicket Stuff / Regular Release Schedule?
On Nov 26, 2008, at 11:38 AM, Jeremy Thomerson wrote: I think Wayne was referring not to your post, but in general - if we package most of the projects up neatly under one parent, then other projects that aren't in the same subdirectory / build cycle may get lost. Hopefully having a cleaned up source tree with better pom/version reuse will make it much easier to keep things up-to-date and useful. It should not be that hard to clean up most of the existing projects. Another thing that would be nice to add to the parent pom is: http://maven.apache.org/plugin-developers/cookbook/add-svn-revision-to-manifest.html I have found it invaluable to have the SVN version cooked into the artifacts -- particularly after something has been running stable for a year and you can't possibly remember exactly where it came from. ryan -- Jeremy Thomerson http://www.wickettraining.com On Wed, Nov 26, 2008 at 7:10 AM, James Carman [EMAIL PROTECTED] wrote: Merely bundling the examples with the code itself shouldn't cause this, do you think? On Wed, Nov 26, 2008 at 2:17 AM, Wayne Pope [EMAIL PROTECTED] wrote: YES. However I feel people may pass over the earlier branches (especially when we're on Wicket version 5.8!) and hence miss some great code that may not take much to get working and maintain on the newer branch. On Wed, Nov 26, 2008 at 2:06 AM, James Carman [EMAIL PROTECTED] wrote: Yes, our entire project at work is like this. The top-level project holds multiple modules. Each has a common, server, and client submodule. Works like a charm. On Tue, Nov 25, 2008 at 5:45 PM, Jeremy Thomerson [EMAIL PROTECTED] wrote: Great idea! Yes. I have not nested any projects three deep in the past, but it should work. Has anybody else tried this? It would be: wicket-stuff-parent -- wicket-foo -- wicket-foo-core -- wicket-foo-examples On Tue, Nov 25, 2008 at 4:32 PM, Ryan McKinley [EMAIL PROTECTED] wrote: I don't know if this has already been discussed, but another part of the cleanup that would be nice is to group the main project and the example project into a folder with a common parent pom. For example, I find the layout of: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/inmethod-grid/ much easier to use/maintain then the apparent standard of /wicketstuff-project /wicketstuff-project-example https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push/ https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push-examples/ one key thing about this change is that mvn eclipse:eclipse makes the example project depend on the core project perhaps this could be added to the 'organize' task? ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jeremy Thomerson http://www.wickettraining.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Organizing Wicket Stuff / Regular Release Schedule?
Good suggestion - I like that, too. I'll plan on adding it to the parent POM. Thanks! On Wed, Nov 26, 2008 at 1:13 PM, Ryan McKinley [EMAIL PROTECTED] wrote: On Nov 26, 2008, at 11:38 AM, Jeremy Thomerson wrote: I think Wayne was referring not to your post, but in general - if we package most of the projects up neatly under one parent, then other projects that aren't in the same subdirectory / build cycle may get lost. Hopefully having a cleaned up source tree with better pom/version reuse will make it much easier to keep things up-to-date and useful. It should not be that hard to clean up most of the existing projects. Another thing that would be nice to add to the parent pom is: http://maven.apache.org/plugin-developers/cookbook/add-svn-revision-to-manifest.html I have found it invaluable to have the SVN version cooked into the artifacts -- particularly after something has been running stable for a year and you can't possibly remember exactly where it came from. ryan -- Jeremy Thomerson http://www.wickettraining.com On Wed, Nov 26, 2008 at 7:10 AM, James Carman [EMAIL PROTECTED] wrote: Merely bundling the examples with the code itself shouldn't cause this, do you think? On Wed, Nov 26, 2008 at 2:17 AM, Wayne Pope [EMAIL PROTECTED] wrote: YES. However I feel people may pass over the earlier branches (especially when we're on Wicket version 5.8!) and hence miss some great code that may not take much to get working and maintain on the newer branch. On Wed, Nov 26, 2008 at 2:06 AM, James Carman [EMAIL PROTECTED] wrote: Yes, our entire project at work is like this. The top-level project holds multiple modules. Each has a common, server, and client submodule. Works like a charm. On Tue, Nov 25, 2008 at 5:45 PM, Jeremy Thomerson [EMAIL PROTECTED] wrote: Great idea! Yes. I have not nested any projects three deep in the past, but it should work. Has anybody else tried this? It would be: wicket-stuff-parent -- wicket-foo -- wicket-foo-core -- wicket-foo-examples On Tue, Nov 25, 2008 at 4:32 PM, Ryan McKinley [EMAIL PROTECTED] wrote: I don't know if this has already been discussed, but another part of the cleanup that would be nice is to group the main project and the example project into a folder with a common parent pom. For example, I find the layout of: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/inmethod-grid/ much easier to use/maintain then the apparent standard of /wicketstuff-project /wicketstuff-project-example https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push/ https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push-examples/ one key thing about this change is that mvn eclipse:eclipse makes the example project depend on the core project perhaps this could be added to the 'organize' task? ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jeremy Thomerson http://www.wickettraining.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jeremy Thomerson http://www.wickettraining.com
Re: [discuss] Organizing Wicket Stuff / Regular Release Schedule?
The revision doesn't tell you everything, though. Typically, you don't release from trunk (at least you're not supposed to). You create a tag and create the release from there. So, the tag/revision would be what you need to easily recreate the release. On Wed, Nov 26, 2008 at 2:13 PM, Ryan McKinley [EMAIL PROTECTED] wrote: On Nov 26, 2008, at 11:38 AM, Jeremy Thomerson wrote: I think Wayne was referring not to your post, but in general - if we package most of the projects up neatly under one parent, then other projects that aren't in the same subdirectory / build cycle may get lost. Hopefully having a cleaned up source tree with better pom/version reuse will make it much easier to keep things up-to-date and useful. It should not be that hard to clean up most of the existing projects. Another thing that would be nice to add to the parent pom is: http://maven.apache.org/plugin-developers/cookbook/add-svn-revision-to-manifest.html I have found it invaluable to have the SVN version cooked into the artifacts -- particularly after something has been running stable for a year and you can't possibly remember exactly where it came from. ryan -- Jeremy Thomerson http://www.wickettraining.com On Wed, Nov 26, 2008 at 7:10 AM, James Carman [EMAIL PROTECTED] wrote: Merely bundling the examples with the code itself shouldn't cause this, do you think? On Wed, Nov 26, 2008 at 2:17 AM, Wayne Pope [EMAIL PROTECTED] wrote: YES. However I feel people may pass over the earlier branches (especially when we're on Wicket version 5.8!) and hence miss some great code that may not take much to get working and maintain on the newer branch. On Wed, Nov 26, 2008 at 2:06 AM, James Carman [EMAIL PROTECTED] wrote: Yes, our entire project at work is like this. The top-level project holds multiple modules. Each has a common, server, and client submodule. Works like a charm. On Tue, Nov 25, 2008 at 5:45 PM, Jeremy Thomerson [EMAIL PROTECTED] wrote: Great idea! Yes. I have not nested any projects three deep in the past, but it should work. Has anybody else tried this? It would be: wicket-stuff-parent -- wicket-foo -- wicket-foo-core -- wicket-foo-examples On Tue, Nov 25, 2008 at 4:32 PM, Ryan McKinley [EMAIL PROTECTED] wrote: I don't know if this has already been discussed, but another part of the cleanup that would be nice is to group the main project and the example project into a folder with a common parent pom. For example, I find the layout of: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/inmethod-grid/ much easier to use/maintain then the apparent standard of /wicketstuff-project /wicketstuff-project-example https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push/ https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push-examples/ one key thing about this change is that mvn eclipse:eclipse makes the example project depend on the core project perhaps this could be added to the 'organize' task? ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jeremy Thomerson http://www.wickettraining.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Organizing Wicket Stuff / Regular Release Schedule?
Right, the svn url is important especially when you deploy from 'non-
released' versions (like most of wicketstuff)
This is what I have in my pom.xml
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
configuration
archive
manifestEntries
Specification-Title${project.name}/Specification-
Title
Specification-Version${project.version}/
Specification-Version
Implementation-Title${project.name}/Implementation-
Title
Implementation-Version${project.version} $
{buildNumber} - ${user.name}/Implementation-Version
SCM-Revision${buildNumber}/SCM-Revision
SCM-url${scm.url}/SCM-url
/manifestEntries
/archive
/configuration
/plugin
On Nov 26, 2008, at 3:24 PM, James Carman wrote:
The revision doesn't tell you everything, though. Typically, you
don't
release from trunk (at least you're not supposed to). You create
a tag
and create the release from there. So, the tag/revision would be
what you
need to easily recreate the release.
On Wed, Nov 26, 2008 at 2:13 PM, Ryan McKinley [EMAIL PROTECTED]
wrote:
On Nov 26, 2008, at 11:38 AM, Jeremy Thomerson wrote:
I think Wayne was referring not to your post, but in general - if we
package
most of the projects up neatly under one parent, then other
projects that
aren't in the same subdirectory / build cycle may get lost.
Hopefully having a cleaned up source tree with better pom/version
reuse
will make it much easier to keep things up-to-date and useful. It
should
not be that hard to clean up most of the existing projects.
Another thing that would be nice to add to the parent pom is:
http://maven.apache.org/plugin-developers/cookbook/add-svn-revision-to-manifest.html
I have found it invaluable to have the SVN version cooked into the
artifacts -- particularly after something has been running stable
for a year
and you can't possibly remember exactly where it came from.
ryan
--
Jeremy Thomerson
http://www.wickettraining.com
On Wed, Nov 26, 2008 at 7:10 AM, James Carman [EMAIL PROTECTED]
wrote:
Merely bundling the examples with the code itself shouldn't
cause this,
do
you think?
On Wed, Nov 26, 2008 at 2:17 AM, Wayne Pope
[EMAIL PROTECTED] wrote:
YES.
However I feel people may pass over the earlier branches
(especially
when
we're on Wicket version 5.8!) and hence miss some great code
that may
not
take much to get working and maintain on the newer branch.
On Wed, Nov 26, 2008 at 2:06 AM, James Carman
[EMAIL PROTECTED]
wrote:
Yes, our entire project at work is like this. The top-level
project
holds multiple modules. Each has a common, server, and client
submodule. Works like a charm.
On Tue, Nov 25, 2008 at 5:45 PM, Jeremy Thomerson
[EMAIL PROTECTED] wrote:
Great idea! Yes. I have not nested any projects three deep
in the
past,
but it should work. Has anybody else tried this?
It would be:
wicket-stuff-parent
-- wicket-foo
-- wicket-foo-core
-- wicket-foo-examples
On Tue, Nov 25, 2008 at 4:32 PM, Ryan McKinley [EMAIL PROTECTED]
wrote:
I don't know if this has already been discussed, but another
part of
the
cleanup that would be nice is to group the main project and the
example
project into a folder with a common parent pom.
For example, I find the layout of:
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/inmethod-grid/
much easier to use/maintain then the apparent standard of
/wicketstuff-project /wicketstuff-project-example
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push/
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push-examples/
one key thing about this change is that mvn eclipse:eclipse
makes
the
example project depend on the core project
perhaps this could be added to the 'organize' task?
ryan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jeremy Thomerson
http://www.wickettraining.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Organizing Wicket Stuff / Regular Release Schedule?
But, here you have to assume it was released from the trunk (which I guess
you can ascertain from the pom's SVN url). I'm not saying this information
isn't useful. I'm just saying it doesn't give you the whole picture by
itself. I was unaware of this plugin, but I do believe I'll add it to our
build cycle. Thanks for the tip!
On Wed, Nov 26, 2008 at 4:18 PM, Ryan McKinley [EMAIL PROTECTED] wrote:
Right, the svn url is important especially when you deploy from
'non-released' versions (like most of wicketstuff)
This is what I have in my pom.xml
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
configuration
archive
manifestEntries
Specification-Title${project.name}/Specification-Title
Specification-Version${project.version}/Specification-Version
Implementation-Title${project.name}/Implementation-Title
Implementation-Version${project.version} ${buildNumber} - ${
user.name}/Implementation-Version
SCM-Revision${buildNumber}/SCM-Revision
SCM-url${scm.url}/SCM-url
/manifestEntries
/archive
/configuration
/plugin
On Nov 26, 2008, at 3:24 PM, James Carman wrote:
The revision doesn't tell you everything, though. Typically, you don't
release from trunk (at least you're not supposed to). You create a tag
and create the release from there. So, the tag/revision would be what you
need to easily recreate the release.
On Wed, Nov 26, 2008 at 2:13 PM, Ryan McKinley [EMAIL PROTECTED] wrote:
On Nov 26, 2008, at 11:38 AM, Jeremy Thomerson wrote:
I think Wayne was referring not to your post, but in general - if we
package
most of the projects up neatly under one parent, then other projects
that
aren't in the same subdirectory / build cycle may get lost.
Hopefully having a cleaned up source tree with better pom/version reuse
will make it much easier to keep things up-to-date and useful. It should
not be that hard to clean up most of the existing projects.
Another thing that would be nice to add to the parent pom is:
http://maven.apache.org/plugin-developers/cookbook/add-svn-revision-to-manifest.html
I have found it invaluable to have the SVN version cooked into the
artifacts -- particularly after something has been running stable for a
year
and you can't possibly remember exactly where it came from.
ryan
--
Jeremy Thomerson
http://www.wickettraining.com
On Wed, Nov 26, 2008 at 7:10 AM, James Carman
[EMAIL PROTECTED]
wrote:
Merely bundling the examples with the code itself shouldn't cause
this,
do
you think?
On Wed, Nov 26, 2008 at 2:17 AM, Wayne Pope
[EMAIL PROTECTED] wrote:
YES.
However I feel people may pass over the earlier branches (especially
when
we're on Wicket version 5.8!) and hence miss some great code that may
not
take much to get working and maintain on the newer branch.
On Wed, Nov 26, 2008 at 2:06 AM, James Carman
[EMAIL PROTECTED]
wrote:
Yes, our entire project at work is like this. The top-level project
holds multiple modules. Each has a common, server, and client
submodule. Works like a charm.
On Tue, Nov 25, 2008 at 5:45 PM, Jeremy Thomerson
[EMAIL PROTECTED] wrote:
Great idea! Yes. I have not nested any projects three deep in the
past,
but it should work. Has anybody else tried this?
It would be:
wicket-stuff-parent
-- wicket-foo
-- wicket-foo-core
-- wicket-foo-examples
On Tue, Nov 25, 2008 at 4:32 PM, Ryan McKinley [EMAIL PROTECTED]
wrote:
I don't know if this has already been discussed, but another part of
the
cleanup that would be nice is to group the main project and the
example
project into a folder with a common parent pom.
For example, I find the layout of:
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/inmethod-grid/
much easier to use/maintain then the apparent standard of
/wicketstuff-project /wicketstuff-project-example
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push/
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push-examples/
one key thing about this change is that mvn eclipse:eclipse makes
the
example project depend on the core project
perhaps this could be added to the 'organize' task?
ryan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jeremy Thomerson
http://www.wickettraining.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
Re: [discuss] Organizing Wicket Stuff / Regular Release Schedule?
It is easy to vote yes to this.
On Wed, Nov 26, 2008 at 5:55 PM, James Carman [EMAIL PROTECTED]wrote:
But, here you have to assume it was released from the trunk (which I guess
you can ascertain from the pom's SVN url). I'm not saying this information
isn't useful. I'm just saying it doesn't give you the whole picture by
itself. I was unaware of this plugin, but I do believe I'll add it to our
build cycle. Thanks for the tip!
On Wed, Nov 26, 2008 at 4:18 PM, Ryan McKinley [EMAIL PROTECTED] wrote:
Right, the svn url is important especially when you deploy from
'non-released' versions (like most of wicketstuff)
This is what I have in my pom.xml
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
configuration
archive
manifestEntries
Specification-Title${project.name}/Specification-Title
Specification-Version${project.version}/Specification-Version
Implementation-Title${project.name
}/Implementation-Title
Implementation-Version${project.version} ${buildNumber} -
${
user.name}/Implementation-Version
SCM-Revision${buildNumber}/SCM-Revision
SCM-url${scm.url}/SCM-url
/manifestEntries
/archive
/configuration
/plugin
On Nov 26, 2008, at 3:24 PM, James Carman wrote:
The revision doesn't tell you everything, though. Typically, you don't
release from trunk (at least you're not supposed to). You create a
tag
and create the release from there. So, the tag/revision would be what
you
need to easily recreate the release.
On Wed, Nov 26, 2008 at 2:13 PM, Ryan McKinley [EMAIL PROTECTED]
wrote:
On Nov 26, 2008, at 11:38 AM, Jeremy Thomerson wrote:
I think Wayne was referring not to your post, but in general - if we
package
most of the projects up neatly under one parent, then other projects
that
aren't in the same subdirectory / build cycle may get lost.
Hopefully having a cleaned up source tree with better pom/version reuse
will make it much easier to keep things up-to-date and useful. It
should
not be that hard to clean up most of the existing projects.
Another thing that would be nice to add to the parent pom is:
http://maven.apache.org/plugin-developers/cookbook/add-svn-revision-to-manifest.html
I have found it invaluable to have the SVN version cooked into the
artifacts -- particularly after something has been running stable for a
year
and you can't possibly remember exactly where it came from.
ryan
--
Jeremy Thomerson
http://www.wickettraining.com
On Wed, Nov 26, 2008 at 7:10 AM, James Carman
[EMAIL PROTECTED]
wrote:
Merely bundling the examples with the code itself shouldn't cause
this,
do
you think?
On Wed, Nov 26, 2008 at 2:17 AM, Wayne Pope
[EMAIL PROTECTED] wrote:
YES.
However I feel people may pass over the earlier branches (especially
when
we're on Wicket version 5.8!) and hence miss some great code that
may
not
take much to get working and maintain on the newer branch.
On Wed, Nov 26, 2008 at 2:06 AM, James Carman
[EMAIL PROTECTED]
wrote:
Yes, our entire project at work is like this. The top-level project
holds multiple modules. Each has a common, server, and client
submodule. Works like a charm.
On Tue, Nov 25, 2008 at 5:45 PM, Jeremy Thomerson
[EMAIL PROTECTED] wrote:
Great idea! Yes. I have not nested any projects three deep in
the
past,
but it should work. Has anybody else tried this?
It would be:
wicket-stuff-parent
-- wicket-foo
-- wicket-foo-core
-- wicket-foo-examples
On Tue, Nov 25, 2008 at 4:32 PM, Ryan McKinley [EMAIL PROTECTED]
wrote:
I don't know if this has already been discussed, but another part
of
the
cleanup that would be nice is to group the main project and the
example
project into a folder with a common parent pom.
For example, I find the layout of:
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/inmethod-grid/
much easier to use/maintain then the apparent standard of
/wicketstuff-project /wicketstuff-project-example
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push/
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push-examples/
one key thing about this change is that mvn eclipse:eclipse makes
the
example project depend on the core project
perhaps this could be added to the 'organize' task?
ryan
Re: [discuss] Organizing Wicket Stuff / Regular Release Schedule?
yes, that is a problem with this plugin -- it looks at the configured
pom scm and uses the info from there. The biggest problem is that if
you build a modified version, the revision number is from the repos,
*not* your code! so if 'svn info' shows Revision: 220M or 220~218,
the cooked in version would still be 220.
In ant, I had a task that calls 'svn info' and parses the result, but
this is the best off the shelf replacement i could find in maven.
ryan
On Nov 26, 2008, at 5:55 PM, James Carman wrote:
But, here you have to assume it was released from the trunk (which I
guess
you can ascertain from the pom's SVN url). I'm not saying this
information
isn't useful. I'm just saying it doesn't give you the whole picture
by
itself. I was unaware of this plugin, but I do believe I'll add it
to our
build cycle. Thanks for the tip!
On Wed, Nov 26, 2008 at 4:18 PM, Ryan McKinley [EMAIL PROTECTED]
wrote:
Right, the svn url is important especially when you deploy from
'non-released' versions (like most of wicketstuff)
This is what I have in my pom.xml
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
configuration
archive
manifestEntries
Specification-Title${project.name}/Specification-
Title
Specification-Version${project.version}/Specification-Version
Implementation-Title${project.name}/Implementation-
Title
Implementation-Version${project.version} $
{buildNumber} - ${
user.name}/Implementation-Version
SCM-Revision${buildNumber}/SCM-Revision
SCM-url${scm.url}/SCM-url
/manifestEntries
/archive
/configuration
/plugin
On Nov 26, 2008, at 3:24 PM, James Carman wrote:
The revision doesn't tell you everything, though. Typically, you
don't
release from trunk (at least you're not supposed to). You
create a tag
and create the release from there. So, the tag/revision would be
what you
need to easily recreate the release.
On Wed, Nov 26, 2008 at 2:13 PM, Ryan McKinley [EMAIL PROTECTED]
wrote:
On Nov 26, 2008, at 11:38 AM, Jeremy Thomerson wrote:
I think Wayne was referring not to your post, but in general - if
we
package
most of the projects up neatly under one parent, then other
projects
that
aren't in the same subdirectory / build cycle may get lost.
Hopefully having a cleaned up source tree with better pom/version
reuse
will make it much easier to keep things up-to-date and useful.
It should
not be that hard to clean up most of the existing projects.
Another thing that would be nice to add to the parent pom is:
http://maven.apache.org/plugin-developers/cookbook/add-svn-revision-to-manifest.html
I have found it invaluable to have the SVN version cooked into the
artifacts -- particularly after something has been running stable
for a
year
and you can't possibly remember exactly where it came from.
ryan
--
Jeremy Thomerson
http://www.wickettraining.com
On Wed, Nov 26, 2008 at 7:10 AM, James Carman
[EMAIL PROTECTED]
wrote:
Merely bundling the examples with the code itself shouldn't
cause
this,
do
you think?
On Wed, Nov 26, 2008 at 2:17 AM, Wayne Pope
[EMAIL PROTECTED] wrote:
YES.
However I feel people may pass over the earlier branches
(especially
when
we're on Wicket version 5.8!) and hence miss some great code
that may
not
take much to get working and maintain on the newer branch.
On Wed, Nov 26, 2008 at 2:06 AM, James Carman
[EMAIL PROTECTED]
wrote:
Yes, our entire project at work is like this. The top-level
project
holds multiple modules. Each has a common, server, and client
submodule. Works like a charm.
On Tue, Nov 25, 2008 at 5:45 PM, Jeremy Thomerson
[EMAIL PROTECTED] wrote:
Great idea! Yes. I have not nested any projects three deep
in the
past,
but it should work. Has anybody else tried this?
It would be:
wicket-stuff-parent
-- wicket-foo
-- wicket-foo-core
-- wicket-foo-examples
On Tue, Nov 25, 2008 at 4:32 PM, Ryan McKinley [EMAIL PROTECTED]
wrote:
I don't know if this has already been discussed, but another
part of
the
cleanup that would be nice is to group the main project and the
example
project into a folder with a common parent pom.
For example, I find the layout of:
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/inmethod-grid/
much easier to use/maintain then the apparent standard of
/wicketstuff-project /wicketstuff-project-example
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push/
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push-examples/
one key thing about
Re: [discuss] Organizing Wicket Stuff / Regular Release Schedule?
Great idea! Yes. I have not nested any projects three deep in the past, but it should work. Has anybody else tried this? It would be: wicket-stuff-parent -- wicket-foo -- wicket-foo-core -- wicket-foo-examples On Tue, Nov 25, 2008 at 4:32 PM, Ryan McKinley [EMAIL PROTECTED] wrote: I don't know if this has already been discussed, but another part of the cleanup that would be nice is to group the main project and the example project into a folder with a common parent pom. For example, I find the layout of: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/inmethod-grid/ much easier to use/maintain then the apparent standard of /wicketstuff-project /wicketstuff-project-example https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push/ https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push-examples/ one key thing about this change is that mvn eclipse:eclipse makes the example project depend on the core project perhaps this could be added to the 'organize' task? ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jeremy Thomerson http://www.wickettraining.com
Re: [discuss] Organizing Wicket Stuff / Regular Release Schedule?
Yes, our entire project at work is like this. The top-level project holds multiple modules. Each has a common, server, and client submodule. Works like a charm. On Tue, Nov 25, 2008 at 5:45 PM, Jeremy Thomerson [EMAIL PROTECTED] wrote: Great idea! Yes. I have not nested any projects three deep in the past, but it should work. Has anybody else tried this? It would be: wicket-stuff-parent -- wicket-foo -- wicket-foo-core -- wicket-foo-examples On Tue, Nov 25, 2008 at 4:32 PM, Ryan McKinley [EMAIL PROTECTED] wrote: I don't know if this has already been discussed, but another part of the cleanup that would be nice is to group the main project and the example project into a folder with a common parent pom. For example, I find the layout of: https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/inmethod-grid/ much easier to use/maintain then the apparent standard of /wicketstuff-project /wicketstuff-project-example https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push/ https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-push-examples/ one key thing about this change is that mvn eclipse:eclipse makes the example project depend on the core project perhaps this could be added to the 'organize' task? ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jeremy Thomerson http://www.wickettraining.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
