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>
                        <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]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to