I think there would be a couple issues...
The first is overcoming the stigma of deploying src alongside your compiled
code. The knee jerk reaction is going to be about security. However, what is
humorous about that is that companies regularly expose their database
structures via SQL in xml files or configuration files. Addtionally, if a
company is concerned about intellectual property being hijacked they should
get out of the database business. As soon as you sell a client your app and
install a database for them... the client can see all the database goodness
your app contains. Anyway, I think there are way bigger security risks than
source code being deployed.
The other issue is going to be for the various build tools out there that
aren't ant or maven. Even with maven it will require some deployment magic.
Heck even a standard compile in IDEA has to be tweaked to get something like
that to occur. So, the amount of effort it takes to get code deployed in
this manner may be a non-starter for many. For that reason I'm not sure *I*
would use it. It's almost as bad as a second compile.
Brandon Goodin
On 10/26/07, Clinton Begin <[EMAIL PROTECTED]> wrote:
>
> You've caught me...and you're the perfect person to have done so. I am
> indeed thinking of enhanced runtime reflection. See if Java reflection
> was
> complete, this wouldn't even be a discussion. Certainly in C# land it is
> not.
>
> There's two reasons: 1) parameter names as you've guessed, 2) Comment
> block
> processing because Java has no multiline strings. Again, in C# this isn't
> a
> problem because C# Attributes are much cleaner than Java annotations, they
> have multiline strings and they can introspect on parameter names (James
> Gosling, are you listening? Or farting around with NetBeans?)
>
> GWT is nice, but I hate having to "compile" or "generate"
> code. Blech. The
> code is written, why do I want anymore? :-) So if we did support
> something
> like:
>
> public native Employee getEmployee(int id) /*-{
> SELECT * FROM EMPLOYEE WHERE ID = ${id}
> }-*/;
>
> I would not want to generate yet another artifact (probably XML) at build
> time. I personally hate that. So why not just deploy the source? It's
> the
> easy and natural thing to do. And I love the fact that it still compiles!
>
> My biggest concern is that there are some companies that are kind of
> strict
> in the sense that they believe this is a security risk, which I believe is
> totally false. However, I could understand to some degree that developers
> of desktop apps would not want to do this if they have IP/legal issues
> with
> handing out their source code.
>
> But then again, that's why we have multiple solutions right? ;-)
>
> Cheers,
> Clinton
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of
> Larry Meadors
> Sent: October-26-07 8:26 AM
> To: dev@ibatis.apache.org
> Subject: Re: Deploying Source Code
>
> I used to do that, but looking at it now, I am asking "What's the cost
> and what's the value?".
>
> The cost in terms of disk is negligible these days - You can't buy a
> drive <120GB these days, so what's a few hundred KB, or even a few MB
> on disk? Especially compared to the 80MB of struts or spring?
>
> I'm not sure how class loaders deal with this, I suspect if they load
> a jar, they load all of the resources, not just what's needed. That
> *could* be a bit more costly in terms of startup time, and free memory
> for the application, but again, sheesh, when you have 4-8GB of RAM in
> a server, what's a few K here and there? I suspect you'll leak more
> than that running firefox. ;-)
>
> The value seems kind of iffy. I guess if you wanted to use embedded
> comments for runtime code generation, this is the only real way to do
> that. But IMO, since we have annotations, that's not a great idea. It
> might help overcome some of Java's retarded reflection limitations
> (who needs parameter names, anyway?), but again - an annotations can
> do that, too.
>
> My gut reaction is that it's not a good idea, but I can't really
> quantify why. :-)
>
> Larry
>
>
> On 10/26/07, Clinton Begin <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> >
> > I mean deploying your .java files to production alongside your .class
> files
> > and having it available on the classpath at runtime.
> >
> >
> >
> > com/yourdomain/yourapp/SomeClass.java
> >
> > com/yourdomain/yourapp/SomeClass.class
> >
> >
> >
> > I hope that's more clear.
> >
> >
> >
> > Clinton
> >
> >
> >
> >
> >
> >
> >
> > From: agodinhost [mailto:[EMAIL PROTECTED]
> > Sent: October-26-07 6:17 AM
> > To: dev@ibatis.apache.org
> > Subject: Re: Deploying Source Code
> >
> >
> >
> >
> >
> > I don´t know if I really understood what you mean.
> >
> >
> >
> >
> >
> > If you are just talking about the iBates part of code, to give a more
> > examples, it is okay.
> >
> >
> > But if you are talking about the whole application this can be a
> > nightmare!!!
> >
> >
> >
> >
> >
> > Please, explain better your idea.
> >
> >
> >
> >
> >
> > Woody
> >
> >
> >
> > ----- Original Message -----
> >
> >
> > From: Clinton Begin
> >
> >
> > To: dev@ibatis.apache.org
> >
> >
> > Sent: Thursday, October 25, 2007 11:41 PM
> >
> >
> > Subject: Deploying Source Code
> >
> >
> >
> >
> > What does anyone/everyone think of deploying their Java source code with
> > their application?
> >
> >
> >
> > Thoughts, ideas, fears, absolutely not???
> >
> >
> >
> > Why?
> >
> >
> >
> > Cheers,
> >
> > Clinton
>
>
