Short term dev goals...
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
On Thu, 4 Nov 2004 19:53:38 +0800, Niclas Hedhman <niclas at hedhman.org> wrote:
> To elaborate a bit, since it came up;
> I think most of us agree that we should concentrate the efforts in the order
> 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.
> 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
> 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)
> 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.
> 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
> / http://www.bali.ac /
> / http://niclas.hedhman.org /
> support-dpml mailing list
> support-dpml at lists.ibiblio.org
More information about the support-dpml