Short term dev goals...

Cameron Taggart cameron.taggart at gmail.com
Thu Nov 4 13:18:07 EST 2004


Yipee!  I'm looking forward to further progress on Magic.  I'm still
stuck with Avalon Magic until DPML Magic has a better install process.
 I can't tell other devs to checkout and build Metro via SVN, just to
get DPML Magic installed.  With Avalon Magic, I distribute the
setup.xml Ant build file and have them run it.

The first Spell on my list is an Eclipse Spell.  I created an Ant 
EclipseTask and packaged it in a jar, but there isn't a great way to
distribute it.  I've been having other devs put it in their .ant/lib
directory.  I would rather have it be in the Magic repository. 
Basically, it creates a basic .project and .classpath files based on
the project definition.  Code available upon request to DPML devs.

Niclas, is the basic idea for a Spell, to be able to wrap an Ant task
with meta information containing what resources the task needs to
execute?

Cameron




On Thu, 4 Nov 2004 19:53:38 +0800, Niclas Hedhman <niclas at hedhman.org> wrote:
> 
> Hi,
> 
> To elaborate a bit, since it came up;
> 
> I think most of us agree that we should concentrate the efforts in the order
> of;
> 1. Magic (solves anyones build problems)
> 2. Transit  (solves anyones Jar handling problems)
> 3. Metro  (solves all other problems :o)  )
> And that the barrier of entry into any organization increases according to the
> same list. So, Magic has priority right now.
> 
> MAGIC
> -----
> I am working on getting a nice plugin system present in Magic (named
> SpellBinder), which will allow for plugins to be installed permanently on the
> local Magic installation, inclusive of targets that are accessible in all
> projects without further declarations. Since Spells then can be produced much
> more independently, I hope that more people will join forces and create
> useful spells, either published here or at an another central repository.
> 
> Also, Magic needs a Spell for publishing (release) artifacts into the central
> repositories.
> 
> Magic needs a lot more documentation at various levels, both reference and
> user guides.
> 
> And finally, Magic needs some 'massaging' to make it into a proper product.
> 
> Once all that is done, we can promote Magic into a release process. :o)
> 
> TRANSIT
> -------
> We have created an "artifact:" protocol handler, which we want to be able to
> package as a completely separate product, so that one can reference remotely
> downloaded, locally cached artifacts of any type in any Java application,
> after simply including the Transit Jar file in the system or extension
> classpath. Steve and I still have some minor arguments of the exact size of
> this little Jar file, and there are currently some bugs which will be sorted
> out once we come to the conclusion of how to layer Transit.
> We will then break out Transit from the /svn/metro/main into its own codebase,
> and then look at having Magic using Transit, to synchronize the behaviour,
> but I suspect that happens after the first release cycle of Magic.
> 
> End of the day, Transit will become two products; The protocol handler, and
> the complete package.
> 
> We will also need to productify Transit.
> 
> METRO
> -----
> I have no immediate news of what will happen on that other than Steve is now
> slaving hard at putting documentation up on http://www.dpml.net
> 
> Cheers
> Niclas
> --
>    +------//-------------------+
>   / http://www.bali.ac        /
>  / http://niclas.hedhman.org /
> +------//-------------------+
> 
> _______________________________________________
> support-dpml mailing list
> support-dpml at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/support-dpml
>



More information about the support-dpml mailing list