Re: sanity check

2004-07-08 Thread Stephen McConnell
Stefan Bodewig wrote:
On Mon, 05 Jul 2004, Stephen McConnell <[EMAIL PROTECTED]> wrote:

The idea scenario is that gump generates the module using the above
after doing the checkout and before computing dependencies.

So Gump had to know how to generate descriptors before it could start
to do some work.  As much as I understand your intention, I see rather
big bootstrap problems here.
All we need to to is to recognize a magic based module and generate the 
module to a file using java.  For example, the following ant task:

  


  http://avalon.apache.org/"/>
  
  
  

  
... generates a file named gump.xml.  I've just posted a copy of this to 
http://www.apache.org/~mcconnell/temp/gump.xml - this will give you an 
idea of what is possible without any input from gump.

Would your magic project description contain all information necessary
to build your projects?  
Yes.
The generated file has everything that gump needs to do its stuff. It 
includes *all* of avalon (as opposed to the current 79% in the current 
hand-maintained gump descriptor).  It is completely up-to-date with 
respect to dependencies and names and covers a complete build, test, and 
publication cycle using gump supplied artifacts for :

  * compilation
  * creation and loading of ant plugin meta-data
  * creation and loading of repository plugin meta-data
  * creation and loading of composite component descriptors
  * unit testing
  * integration testing
  * integrated javadoc and site generation
In all of the above - magic itself, magic plugins, application plugins, 
composite component definitions - everything is running of artifacts 
generated by gump.

You'd probably still need to pull SCM
information and jar locations from Gump in addtion, right?
No - not for module generation.
Magic has internal build support for running in a gump context.  It will 
automatically adjust version information across all managed projects to 
synchronize with the gump @@DATE@@ value and it will automatically map 
non-avalon artifacts to the gump supplied jar filenames.

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


--
|---|
| Magic by Merlin   |
| Production by Avalon  |
|   |
| http://avalon.apache.org  |
|---|
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: sanity check

2004-07-08 Thread Stefan Bodewig
On Mon, 05 Jul 2004, Stephen McConnell <[EMAIL PROTECTED]> wrote:

> The idea scenario is that gump generates the module using the above
> after doing the checkout and before computing dependencies.

So Gump had to know how to generate descriptors before it could start
to do some work.  As much as I understand your intention, I see rather
big bootstrap problems here.

Would your magic project description contain all information necessary
to build your projects?  You'd probably still need to pull SCM
information and jar locations from Gump in addtion, right?

Stefan

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



Re: sanity check

2004-07-05 Thread Stephen McConnell
Stefan Bodewig wrote:
On Mon, 05 Jul 2004, Stephen McConnell <[EMAIL PROTECTED]> wrote:

How do we integrate the generated avalon module definition into the
gump process?

commit them to the Gump module as you've done for avalon-tools or
commit them to the Avalon SVN repo and point the profile to them via
http.
The former allows non-Avalon people to tweak them if something goes
wrong.
Actually that's not desirable.  If something goes wrong it's a issue 
related to the project definition that magic reads in (for example, a 
missing dependency).  So the principal is .. update the magic definition 
and from that generate the gump module automatically.

Running the following ant target on build.xml in avalon/truck generates 
the complete avalon module into a file name gump.xml:

  


  http://avalon.apache.org/"/>
  
  

  
The idea scenario is that gump generates the module using the above 
after doing the checkout and before computing dependencies.

Stephen.

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


--
|---|
| Magic by Merlin   |
| Production by Avalon  |
|   |
| http://avalon.apache.org  |
|---|
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: sanity check

2004-07-05 Thread Stefan Bodewig
On Mon, 05 Jul 2004, Stephen McConnell <[EMAIL PROTECTED]> wrote:

> How do we integrate the generated avalon module definition into the
> gump process?

commit them to the Gump module as you've done for avalon-tools or
commit them to the Avalon SVN repo and point the profile to them via
http.

The former allows non-Avalon people to tweak them if something goes
wrong.

Stefan

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



Re: sanity check

2004-07-05 Thread Stephen McConnell
Stefan Bodewig wrote:
On Mon, 05 Jul 2004, Stephen McConnell <[EMAIL PROTECTED]> wrote:

Here is the latest generation.

looks good.
OK - now for the big question.
How do we integrate the generated avalon module definition into the gump 
process?

Steve.
--
|---|
| Magic by Merlin   |
| Production by Avalon  |
|   |
| http://avalon.apache.org  |
|---|
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: sanity check

2004-07-05 Thread Stefan Bodewig
On Mon, 05 Jul 2004, Stephen McConnell <[EMAIL PROTECTED]> wrote:

> Here is the latest generation.

looks good.

Stefan

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



Re: sanity check

2004-07-05 Thread Stephen McConnell
Stefan Bodewig wrote:
On Mon, 05 Jul 2004, Stephen McConnell <[EMAIL PROTECTED]> wrote:

  

has to be property, not depend.
 is  (BTW, still
resource should be reference).
Umm - sorry about that!
Here is the latest generation.
  


  
  project="avalon-tools-magic-home" inherit="runtime" />
  
  
  
  
  




   from="Magic Integration <[EMAIL PROTECTED]>"/>
  

Steve.

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


--
|---|
| Magic by Merlin   |
| Production by Avalon  |
|   |
| http://avalon.apache.org  |
|---|
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: sanity check

2004-07-05 Thread Stefan Bodewig
On Mon, 05 Jul 2004, Stephen McConnell <[EMAIL PROTECTED]> wrote:

>project="avalon-tools-magic-home" inherit="runtime" />

has to be property, not depend.

 is  (BTW, still
resource should be reference).

Stefan

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



Re: sanity check

2004-07-05 Thread Stephen McConnell
Stefan Bodewig wrote:
On Mon, 05 Jul 2004, Stephen McConnell <[EMAIL PROTECTED]> wrote:

Everything is now committed so I guess there will be something
interesting to look at in the morning.  In the meantime if anyone
can see any immediate issue I'd love to hear about them.

Yep.
you can't use  when referencing avalon-tools-magic-home since
it doesn't define any output.  Simply use a plain property.
Fixed.

The  for gump.resource.ant is lacking an id attribute in
avalon-tools-magic.
Have updated magic's index.
Here is the revised generated output for magic building magic:
  


  
  project="avalon-tools-magic-home" inherit="runtime" />
  
  
  
  
  




   from="Magic Integration <[EMAIL PROTECTED]>"/>
  

Steve.

I'll commit a fixed version shortly.
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


--
|---|
| Magic by Merlin   |
| Production by Avalon  |
|   |
| http://avalon.apache.org  |
|---|
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: sanity check

2004-07-05 Thread Stephen McConnell
Stefan Bodewig wrote:
On Mon, 05 Jul 2004, Stefan Bodewig <[EMAIL PROTECTED]> wrote:

you can't use  when referencing avalon-tools-magic-home
since it doesn't define any output.  Simply use a plain property.

... and the attribute's name is reference, not resource.
Thanks - have just fixed this in the gump task.
Steve.
--
|---|
| Magic by Merlin   |
| Production by Avalon  |
|   |
| http://avalon.apache.org  |
|---|
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: sanity check

2004-07-05 Thread Stefan Bodewig
On Mon, 05 Jul 2004, Stefan Bodewig <[EMAIL PROTECTED]> wrote:

> you can't use  when referencing avalon-tools-magic-home
> since it doesn't define any output.  Simply use a plain property.

... and the attribute's name is reference, not resource.

Stefan

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



Re: sanity check

2004-07-05 Thread Stefan Bodewig
On Mon, 05 Jul 2004, Stephen McConnell <[EMAIL PROTECTED]> wrote:

> Everything is now committed so I guess there will be something
> interesting to look at in the morning.  In the meantime if anyone
> can see any immediate issue I'd love to hear about them.

Yep.

you can't use  when referencing avalon-tools-magic-home since
it doesn't define any output.  Simply use a plain property.

The  for gump.resource.ant is lacking an id attribute in
avalon-tools-magic.

I'll commit a fixed version shortly.

Stefan

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



sanity check

2004-07-05 Thread Stephen McConnell
Hi again!
I've just committed some changes to avalon-tools.xml.  Basically we now 
have three projects defined:

   * avalon-tools-magic-bootstrap
   * avalon-tools-magic-home
   * avalon-tools-magic
avalon-tools-magic-bootstrap

This should build the magic jar.  It assumes the ant and junit will be 
in the classpath.  We can edit this definition as much as we want.

avalon-tools-magic-home
---
Uses the same buildfile as bootstrap to create and populate a directory 
with doc generation themes and magic build template and sets the created 
directory as the project .  All generated project definitions 
reference this project as a dependency (with inherit="runtime") and use 
the home reference as the value assigned to ${magic.home}.  This 
definition is also changeable.

avalon-tools-magic
--
This is a generated gump project definition that is only included for 
the purpose of testing the logic in the generation code.  I.e. if there 
are problems with this definition I'll need to update Magic's gump task. 
 The definition is a strait cut-and-past from this file:

  http://www.apache.org/~mcconnell/temp/gump.xml
Everything is now committed so I guess there will be something 
interesting to look at in the morning.  In the meantime if anyone can 
see any immediate issue I'd love to hear about them.

Cheers, Steve.
--
|---|
| Magic by Merlin   |
| Production by Avalon  |
|   |
| http://avalon.apache.org  |
|---|
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]