I understand that having a combined jar when we have different implementations for an api is not a good idea.

 

Maybe we could bundle the api within each implementation for those who prefer working with a combined jar.

 

Jose Rodolfo Freitas

 

 

De: Ken Finnigan [mailto:ken@kenfinnigan.me]
Enviada em: sexta-feira, 10 de junho de 2011 09:27
Para: José Rodolfo Carrijo de Freitas
Cc: Dan Allen; Jordan Ganoff; seam-dev@lists.jboss.org
Assunto: Re: [seam-dev] Removing the combined jar

 

+1 to the profile idea and +1 to removing combined jars, as I believe it simplifies the artifacts being produced, especially in situations where a module has multiple implementations and you don't necessarily want to bundle them all together.

And we don't want to have different bundling techniques for modules that multiple implementations and those that don't, too confusing.

>From my enterprise dev experience I can't recall a time when the number of jars in an application became a concern, but I could have been lucky.  I do agree that when using Ant having multiple artifacts is a PITA, but those using Ant know going in that dependency management with it is going to bring its own kind of hell.

José, to your concern around needing to define multiple artifacts when using Arquillian.  From my interpretation of Dan's bundling idea I see that it can be achieved in two ways:
  1) Provide a set of commonly used Seam modules in a single jar pre-packaged as suggested, ie. core, business, etc.
  2) Provide a UI that allows a developer to pick and choose which modules they want, then a background process is kicked off to actually shade all those artifacts together into a single jar and the developer is notified when that bundling is complete with a link to the download.

In either of the above situations you would be specifying the bundled jar as a dependency for any Arquillian tests, thus reducing the number of dependencies to be listed as most tests would probably touch on a Seam module and Solder at a minimum, and possibly other modules as well.

Ken

On Fri, Jun 10, 2011 at 7:47 AM, José Rodolfo Carrijo de Freitas <jose.freitas@softplan.com.br> wrote:

+1 for profile jar Idea. -1 for removing combined jar.

I agree with John and besides, there’re situations that is pretty useful, e.g.  when using shrinkwap mavenresolver it’s easier having one combined jar (less code to write and keep)

 

//war is a shrinkwrap web archive.

war.addAsLibraries(DependencyResolvers.use(MavenDependencyResolver.class)

.artifact(“org.jboss.seam.faces:seam-faces:3.1.0-SNAPSHOT”)

                        .resolveAs(GenericArchive.class));

 

 

 

Atenciosamente,

 

José Rodolfo Carrijo de Freitas
Analista de Sistemas
Pesquisa e desenvolvimento

Softplan/Poligraph

+ 55 48 3027-8000

www.softplan.com.br

 

De: seam-dev-bounces@lists.jboss.org [mailto:seam-dev-bounces@lists.jboss.org] Em nome de Dan Allen
Enviada em: quinta-feira, 9 de junho de 2011 21:04
Para: Jordan Ganoff
Cc: seam-dev@lists.jboss.org
Assunto: Re: [seam-dev] Removing the combined jar

 

On Thu, Jun 9, 2011 at 20:00, Jordan Ganoff <jganoff@gmail.com> wrote:

+1 for "profile" jars and removal of the combiner jar.

 

I'd like to see a friendly user interface for choosing modules which would generate the required Maven/Gradle/Ivy dependency list you can copy/paste... that is of course if you're not using Forge. This would be hosted at the Seam University for example.

 

That might be best for our new project site, which is in the ice box while we fight off some oppression. "Help! I'm being oppressed!"

 

We could do this with a little jQuery magic :)

 

-Dan

 

--

Dan Allen

Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597

 


_______________________________________________
seam-dev mailing list
seam-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev