On 8/24/06, Matt Raible <[EMAIL PROTECTED]> wrote:
So based on this feedback, where I have a webapp like AppFuse (that
implements the same thing with 4 webapps, but also wants to be a
library for users), would you suggest doing something like the
following?

web (JARs)
    - common (common filters, listeners, etc. between impls below)
    - jsf
    - spring
    - struts
    - tapestry
war (WARs)
    - common (common jsps, images, stylesheets, etc between wars below)
    - jsf
    - spring
    - struts
    - tapestry

I suppose this seems reasonable; I just never expected AppFuse to turn
into 9 JARs and 5 WARs!

Matt

Thinking about this a bit more, the following seems like it might be a
little easier to understand and work with (from an AppFuse developer
perspective, not a users).

web
   - common
       - war
   - jsf
       - war
   - spring
       - war
   - struts
       - war
   - tapestry
       - war

Thoughts?

Thanks,

Matt


On 8/23/06, Eric Redmond <[EMAIL PROTECTED]> wrote:
> This isn't really a shortcomming of Maven as much as a Java thing. Imagine
> that your WAR was a JAR that contained a class in:
>   somejar.jar:WEB-INF/classes/com.MyClass.class
> the classloader isn't going to find it anyway. The only reason that classes
> existing in WEB-IN/classes are found in a WAR is because the loading
> container knows where to look for them. So, yes, if you want to share
> classes between projects you will have to create a seperate JAR project, and
> that JAR will be a dependency of the WAR. This is not a bad thing.
>
> Eric
>
> On 8/22/06, Denis Cabasson <[EMAIL PROTECTED]> wrote:
> >
> >
> > I guess this "functionality" isn't present in Maven, as it goes against
> > the
> > "best practice" Maven is trying to enforce.
> > If an artifact is supposed to be used as both an external dependency and a
> > webapp, it should be bundled in its own jar, and user as a normal
> > dependency
> > in both project. To be more precise, the buisness logic (which is to be
> > re-used as a dependency in another project) should be in another project,
> > well the user interface, and all the webapp related stuff should stay in
> > the
> > war project.
> >
> > Well, at least, that's my point of view on the matter.
> >
> > Denis.
> >
> >
> > Matt Raible-3 wrote:
> > >
> > > I discovered this same thing last week.
> > >
> > >
> > 
http://www.nabble.com/Re%3A-Converting-AppFuse-to-a-Maven-2-Project-p5870757.html
> > >
> > > Seems like a bug to me, but it's probably more of a missing feature.
> > > What would it take to add this functionality?
> > >
> > > Thanks,
> > >
> > > Matt
> > >
> > > On 8/22/06, alexsun <[EMAIL PROTECTED]> wrote:
> > >>
> > >> I use this configuration in my pom file
> > >> ...
> > >> <dependency>
> > >>           <groupId><!-- groupId of the war --></groupId>
> > >>           <artifactId><!-- artifactId of the war --></artifactId>
> > >>           <version><! -- version of the war --></version>
> > >>           <type>war</type>
> > >> </dependency>
> > >> ...
> > >>
> > >> but during build process get error that classes from war-package not
> > >> found.
> > >>
> > >> Why?
> > >> --
> > >> View this message in context:
> > >>
> > 
http://www.nabble.com/Maven-cannot-find-dependencies-classes-from-WEB-INF-classes-tf2147059.html#a5928069
> > >> Sent from the Maven - Users forum at Nabble.com.
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >> For additional commands, e-mail: [EMAIL PROTECTED]
> > >>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >
> >
> > --
> > View this message in context:
> > 
http://www.nabble.com/Maven-cannot-find-dependencies-classes-from-WEB-INF-classes-tf2147059.html#a5930280
> > Sent from the Maven - Users forum at Nabble.com.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Eric Redmond
> http://codehaus.org/~eredmond
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to