Re: [xmlc] XMLC_SOURCE_FILE problems

--- Jacob Kjome <hoju@xxxxxxxx> wrote:

> At 01:12 AM 9/1/2005 -0700, you wrote:
>  >
>  >--- Jacob Kjome <hoju@xxxxxxxx> wrote:
>  >> Because your build environment may have little
> to
>  >> nothing to do with your
>  >> deployment environment.  It may in your case,
> but it
>  >> doesn't have
>  >> to.  Additionally, although webapps seem to be
> the
>  >> primary use-case for
>  >> XMLC, there is nothing that locks XMLC into a
> webapp
>  >> paradigm.
>  >
>  >Fine, I understand this.  I still think the
> default
>  >behavior should be to look under the "srcdir" that
> you
>  >passed into the xmlc generation program.  But
> that's
>  >my opinion, and if the override works, then I
> don't
>  >really care.
>  >
> 
> How would a class at runtime know this info without
> it being 
> hardcoded?  So, then your srcdir is at
> "C:\dev\myproject\src".  Then you 
> send the binary to someone to run on their machine. 
> They don't have the 
> srcdir, they just have a binary jar to work with. 
> How does XMLC find the 
> files without being configured in this case?  In the
> case of having them in 
> the same package as the class they get built with,
> they can be pulled from 
> the classpath.  So, not matter where the program is
> run from, XMLC can find 
> its markup.  If you explicitly provide one or more
> reparse resource dirs, 
> then you can override this default behavior.  The
> point of the default is 
> that it can be counted on to work, regardless of the
> environment.  Of 
> course you have to copy the files to the package,
> but that's pretty basic 
> when using a build tool like Ant.

Ah yes.  Windows users.  Sorry, I forgot about you
guys.  I have my webapps in the same absolute path on
my development and production servers.

>  >My desire to have my build and deployment
> environments
>  >seems very sane.  It's much simpler for web
> designers
>  >to understand than to know that they have to dig
> into
>  >a 4-deep directory structure to find the html
> files.
> 
> Why would a designer have to dig for the markup?  I
> never said force a 
> package structure on the source markup files. 
> That's what <copy> is for in 
> Ant and "xmlcReparseResourceDirs" and
> "xmlcReparsePackagePrefixes" are for 
> in web.xml (or programatically on the deferred
> parsing factory).  Your 
> source can stay wherever you want it.  I really get
> the feeling you haven't 
> looked at the Tomcat example app very closely, if at
> all, as it allows for 
> exactly what you are trying to do.

For me, one of the biggest draws of XMLC is the vision
of developing a web app, and then having an
all-I-know-is-dreamweaver-and-how-to-sftp-html-files-to-a-server
web designer deploy directly to a production
environment.  I don't want them having to use ant to
do this.
 
> If the Tomcat app 
> doesn't work for you, then there's a bug to fix for
> configuring reparse 
> dirs in unix environments (or the build file is
> windows-specific, but I 
> doubt that).  If it does work, then we'll work on
> getting it working in 
> your environment.  I think it will do what you
> desire.

I looked at the Tomcat example's web.xml.in, but not
at the ant script.  I didn't want to have to install
Tomcat, so I didn't actually try building and
deploying the example.

AHA!  The answer was hidden in your last email.  I was
setting xmlcReparsePackagePrefixes using dot notation
(e.g. "my.package.name") and I needed to use slashes. 
It seems like it would be pretty simple to allow it to
accept both.  If someone doesn't actually build the
tomcat example, it's not really obvious which notation
to use for "package prefix", especially after using
dot notation in the packagename param in the interface
generation.  Maybe "xmlcReparsePackageDirPrefixes"
might be better?  When I got around to trying that
param, I was pretty fed up, and it didn't occur to me
to try slash package notation.

Now I can remove my
/webapps/mysite/stupidhack/my/package/name/xmlc -->
/webapps/mysite/root
symlink!

You've been very helpful.  Sorry if I got a little
snippy.  :-)

Thanks,
Erik


                
__________________________________ 
Yahoo! Mail 
Stay connected, organized, and protected. Take the tour: 
http://tour.mail.yahoo.com/mailtour.html 



--
You receive this message as a subscriber of the xmlc@xxxxxxxxxxxxx mailing list.
To unsubscribe: mailto:xmlc-unsubscribe@xxxxxxxxxxxxx
For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws