Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Users List" <users@maven.apache.org>
Received-SPF: pass (hermes.apache.org: domain of brett.porter@gmail.com
 designates 64.233.184.203 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=YD9qDHkO+e8nBrrUJXH5B6eUOmhcxu+9wiA/lspg0aYEJFEmG6DRhtM3+J5gcNjAP/5y0uDpq8GZMEZBnXzv9W5XGVrPcMt329nd6v8iby/8wqO+PNfJ33iRMRrkV1o1lW+XJzOmugTBc2ZG2E7c/sm8JSQdpJhCsczHglQ2mKQ=
Message-ID: <9e3862d80501041122555f48da@mail.gmail.com>
Date: Wed, 5 Jan 2005 06:22:54 +1100
From: Brett Porter <brett.porter@gmail.com>
Reply-To: Brett Porter <brett.porter@gmail.com>
To: Maven Users List <users@maven.apache.org>
Subject: Re: Multiproject without the jars
In-Reply-To: <41DADCAD.2020107@post.harvard.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <41D9C3BA.6080405@post.harvard.edu>
	 <9e3862d805010315393cb5abd0@mail.gmail.com>
	 <41DAD738.1060601@post.harvard.edu>
	 <41DADCAD.2020107@post.harvard.edu>

Yes, sharing a classes directory will work, but you haven't answered
the reason why you think this is better :)

If you want to be able to copy single classes to the appserver, you
can still do this. /WEB-INF/classes takes precedence over
/WEB-INF/lib, so just copy it into there during development. I do this
via my IDE.

Your build should reflect the structure of the project in all stages,
not the way you develop. Adding extra development hooks is always
handy and a good idea, but it should not affect the core structure you
have in place for releases all the way through. You should be able to
build in any environment and expect a consistent result.

Cheers,
Brett


On Tue, 04 Jan 2005 13:13:01 -0500, Randy Xu <r@post.harvard.edu> wrote:
> Oops, badly formatted email
> 
> Just to clarify - say Subproject B depends on Subproject A.
> I would set the classpath of a subproject B to point to the
> /target/classes directory of subproject A.
> 
> Then run 'multiproject:goals' with the goal of 'java:compile'.  This
> should compile all classes without creating jars right?  What I'd like
> to do is have the project in a state where a change to a single class
> can be deployed and tested by just compiling that class then moving it
> to the application server directory.
> 
> -Randy
> 
> Randy Xu wrote:
> 
> > Hmm... you sure it involves copying files around.  I was planning on
> > setting the output classes directories (subproject/target/classes) in
> > the classpath of higher-level subprojects.
> >
> > Then, I'd run multiproject:goal with -Dgoal=java:compile?  Any reason
> > this wouldn't work?
> >
> > Would this involve overwriting the default java:compile goals?  I
> > guess what I'm asking is how one can add directories to the default
> > compile classpath.
> >
> > -Randy
> >
> > Brett Porter wrote:
> >
> >> The only way would be to copy class files around, but its not
> >> recommended.
> >>
> >> Jarring doesn't take very much time at all and makes everything a lot
> >> cleaner.
> >>
> >> If Jarring takes time, is it really that the test step in between
> >> java:compile and jar:jar is slow?
> >>
> >> This is a separate problem - there are ways to disable tests for
> >> development, but its also  highly recommended you run them if they are
> >> effective. If they are slow, perhaps you have some integration or
> >> performance tests in there and should split them into special
> >> integration test projects that can be run before releases instead of
> >> every build.
> >>
> >> - Brett
> >>
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org