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
: [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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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]
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
17 matches
Mail list logo
