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

Reply via email to