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>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-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]
