4:19 p.m.
instead of the way our JBoss AS distribution is structure now, why not
introduce the idea of maven-based booting and deployment?
Core components (specifically deployers, sars, really anything in the
JBoss domain) of a profile (default, minimal, all, etc.) would only
include bean.xml and other configuration files. Within beans.xml or a
different file, each deployment unit would specify its dependencies,
either through <dependency> elements, or a list of maven artifacts, i.e.
org.jboss.resteasy:resteasy-jaxrs:2.0
That way our distribution can be either very very tiny, just a zip of
text files that point to our maven repository. Or, very optimized, we
ship a maven repository with the distribution that shared between the
different profiles.
This could get very interesting over time. Deployment units could
delegate to the base AS for versioning, much like maven modules delegate
to a parent pom for dependency versions. We could automatically create
scoped deployments or issue warnings if base AS and the deployment unit
require different library versions, etc.
Just a thought...
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
4:27 p.m.
It's not booting, but doens't Resin already have the ability to deploy a
pom.xml? Can't recall where I heard this but it definitely turns conventional
wisdom on its head.
-CB
On Thursday 01 April 2010 05:19:42 pm Bill Burke wrote:
instead of the way our JBoss AS distribution is structure now, why
not
introduce the idea of maven-based booting and deployment?
Core components (specifically deployers, sars, really anything in the
JBoss domain) of a profile (default, minimal, all, etc.) would only
include bean.xml and other configuration files. Within beans.xml or a
different file, each deployment unit would specify its dependencies,
either through <dependency> elements, or a list of maven artifacts, i.e.
org.jboss.resteasy:resteasy-jaxrs:2.0
That way our distribution can be either very very tiny, just a zip of
text files that point to our maven repository. Or, very optimized, we
ship a maven repository with the distribution that shared between the
different profiles.
This could get very interesting over time. Deployment units could
delegate to the base AS for versioning, much like maven modules delegate
to a parent pom for dependency versions. We could automatically create
scoped deployments or issue warnings if base AS and the deployment unit
require different library versions, etc.
Just a thought...
Bill
7:42 a.m.
Actually i wrote a deployer a while back using maven embedder to include
maven artifacts from a pom.xml in the deployment classpath - trying to
demonstrate Max how easy it is to extend AS. I'm not sure what to do
with this though :)
On 04/01/2010 11:27 PM, Chris Bredesen wrote:
It's not booting, but doens't Resin already have the ability
to deploy a
pom.xml? Can't recall where I heard this but it definitely turns conventional
wisdom on its head.
-CB
On Thursday 01 April 2010 05:19:42 pm Bill Burke wrote:
> instead of the way our JBoss AS distribution is structure now, why not
> introduce the idea of maven-based booting and deployment?
>
> Core components (specifically deployers, sars, really anything in the
> JBoss domain) of a profile (default, minimal, all, etc.) would only
> include bean.xml and other configuration files. Within beans.xml or a
> different file, each deployment unit would specify its dependencies,
> either through<dependency> elements, or a list of maven artifacts, i.e.
>
> org.jboss.resteasy:resteasy-jaxrs:2.0
>
> That way our distribution can be either very very tiny, just a zip of
> text files that point to our maven repository. Or, very optimized, we
> ship a maven repository with the distribution that shared between the
> different profiles.
>
> This could get very interesting over time. Deployment units could
> delegate to the base AS for versioning, much like maven modules delegate
> to a parent pom for dependency versions. We could automatically create
> scoped deployments or issue warnings if base AS and the deployment unit
> require different library versions, etc.
>
> Just a thought...
>
> Bill
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
8:42 a.m.
Blog about it, put it out there on the .org wiki, demonstrate it. This is
cool stuff!
-CB
On Tuesday 06 April 2010 08:42:47 am Emanuel Muckenhuber wrote:
Actually i wrote a deployer a while back using maven embedder to
include
maven artifacts from a pom.xml in the deployment classpath - trying to
demonstrate Max how easy it is to extend AS. I'm not sure what to do
with this though :)
On 04/01/2010 11:27 PM, Chris Bredesen wrote:
> It's not booting, but doens't Resin already have the ability to deploy a
> pom.xml? Can't recall where I heard this but it definitely turns
> conventional wisdom on its head.
>
> -CB
>
> On Thursday 01 April 2010 05:19:42 pm Bill Burke wrote:
>> instead of the way our JBoss AS distribution is structure now, why not
>> introduce the idea of maven-based booting and deployment?
>>
>> Core components (specifically deployers, sars, really anything in the
>> JBoss domain) of a profile (default, minimal, all, etc.) would only
>> include bean.xml and other configuration files. Within beans.xml or a
>> different file, each deployment unit would specify its dependencies,
>> either through<dependency> elements, or a list of maven artifacts, i.e.
>>
>> org.jboss.resteasy:resteasy-jaxrs:2.0
>>
>> That way our distribution can be either very very tiny, just a zip of
>> text files that point to our maven repository. Or, very optimized, we
>> ship a maven repository with the distribution that shared between the
>> different profiles.
>>
>> This could get very interesting over time. Deployment units could
>> delegate to the base AS for versioning, much like maven modules delegate
>> to a parent pom for dependency versions. We could automatically create
>> scoped deployments or issue warnings if base AS and the deployment unit
>> require different library versions, etc.
>>
>> Just a thought...
>>
>> Bill
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
2:52 p.m.
How about a deployer which picks up a pom puts the dependencies on the
classpath and deploys the artifact?
It still leaves you with a broken dependency resolver though.
Hmm, could be a deployer which picks up an ivy.xml.
Carlo
On 04/06/2010 02:42 PM, Emanuel Muckenhuber wrote:
Actually i wrote a deployer a while back using maven embedder to
include
maven artifacts from a pom.xml in the deployment classpath - trying to
demonstrate Max how easy it is to extend AS. I'm not sure what to do
with this though :)
On 04/01/2010 11:27 PM, Chris Bredesen wrote:
> It's not booting, but doens't Resin already have the ability to deploy a
> pom.xml? Can't recall where I heard this but it definitely turns conventional
> wisdom on its head.
>
> -CB
>
> On Thursday 01 April 2010 05:19:42 pm Bill Burke wrote:
>
>> instead of the way our JBoss AS distribution is structure now, why not
>> introduce the idea of maven-based booting and deployment?
>>
>> Core components (specifically deployers, sars, really anything in the
>> JBoss domain) of a profile (default, minimal, all, etc.) would only
>> include bean.xml and other configuration files. Within beans.xml or a
>> different file, each deployment unit would specify its dependencies,
>> either through<dependency> elements, or a list of maven artifacts, i.e.
>>
>> org.jboss.resteasy:resteasy-jaxrs:2.0
>>
>> That way our distribution can be either very very tiny, just a zip of
>> text files that point to our maven repository. Or, very optimized, we
>> ship a maven repository with the distribution that shared between the
>> different profiles.
>>
>> This could get very interesting over time. Deployment units could
>> delegate to the base AS for versioning, much like maven modules delegate
>> to a parent pom for dependency versions. We could automatically create
>> scoped deployments or issue warnings if base AS and the deployment unit
>> require different library versions, etc.
>>
>> Just a thought...
>>
>> Bill
>>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
4:32 p.m.
BTW, I got this idea when I was doing testing with RESTEasy against AS 6
trunk. My thought was, "wouldn't it be cool if AS just loaded RESTEasy
from my local maven repository so that I didn't have to manually copy to
or rebuild the AS distribution?" I guess what I'm saying is that it
would help make us more productive too.
Also, from a product standpoint, it would be very easy for us to define
and ship different profiles. A profile would be so small, it could
easily be archived and distributed through a maven repository. Could
easily be sent across the wire for support engineers to look at, etc.
Bill Burke wrote:
instead of the way our JBoss AS distribution is structure now, why
not
introduce the idea of maven-based booting and deployment?
Core components (specifically deployers, sars, really anything in the
JBoss domain) of a profile (default, minimal, all, etc.) would only
include bean.xml and other configuration files. Within beans.xml or a
different file, each deployment unit would specify its dependencies,
either through <dependency> elements, or a list of maven artifacts, i.e.
org.jboss.resteasy:resteasy-jaxrs:2.0
That way our distribution can be either very very tiny, just a zip of
text files that point to our maven repository. Or, very optimized, we
ship a maven repository with the distribution that shared between the
different profiles.
This could get very interesting over time. Deployment units could
delegate to the base AS for versioning, much like maven modules delegate
to a parent pom for dependency versions. We could automatically create
scoped deployments or issue warnings if base AS and the deployment unit
require different library versions, etc.
Just a thought...
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
5:25 p.m.
This is the closest we have today.
https://jira.jboss.org/jira/browse/RELOADED-2
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/reloaded/trun...
I think it relies on outdated snapshots, so it probably doesn't work
anymore on clean machines.
Combine (or replace) it with a package manager.
https://jira.jboss.org/jira/browse/EJBTHREE-1942
Make sure we can bootstrap a (proper) dependency manager.
https://jira.jboss.org/jira/browse/EJBTHREE-1744
And you should end up with a distro which is measured in KB, not MB.
$ java -jar jboss-reloaded.jar -Dorg=org.jboss.resteasy
-Dmodule=resteasy-reloaded -Drev=latest.integration
You'll probably whine a boot on the first boottime, but alas... ;-)
Carlo
On 04/01/2010 11:32 PM, Bill Burke wrote:
BTW, I got this idea when I was doing testing with RESTEasy against
AS 6
trunk. My thought was, "wouldn't it be cool if AS just loaded RESTEasy
from my local maven repository so that I didn't have to manually copy to
or rebuild the AS distribution?" I guess what I'm saying is that it
would help make us more productive too.
Also, from a product standpoint, it would be very easy for us to define
and ship different profiles. A profile would be so small, it could
easily be archived and distributed through a maven repository. Could
easily be sent across the wire for support engineers to look at, etc.
Bill Burke wrote:
> instead of the way our JBoss AS distribution is structure now, why not
> introduce the idea of maven-based booting and deployment?
>
> Core components (specifically deployers, sars, really anything in the
> JBoss domain) of a profile (default, minimal, all, etc.) would only
> include bean.xml and other configuration files. Within beans.xml or a
> different file, each deployment unit would specify its dependencies,
> either through<dependency> elements, or a list of maven artifacts, i.e.
>
> org.jboss.resteasy:resteasy-jaxrs:2.0
>
> That way our distribution can be either very very tiny, just a zip of
> text files that point to our maven repository. Or, very optimized, we
> ship a maven repository with the distribution that shared between the
> different profiles.
>
> This could get very interesting over time. Deployment units could
> delegate to the base AS for versioning, much like maven modules delegate
> to a parent pom for dependency versions. We could automatically create
> scoped deployments or issue warnings if base AS and the deployment unit
> require different library versions, etc.
>
> Just a thought...
>
> Bill
>
>
>
4:37 p.m.
This is in line with what DML/Carlo/Jason were initially pointing to.
The AS has to be lean - pulling in packages more like Fedora.
On 04/01/2010 04:19 PM, Bill Burke wrote:
instead of the way our JBoss AS distribution is structure now, why
not
introduce the idea of maven-based booting and deployment?
Core components (specifically deployers, sars, really anything in the
JBoss domain) of a profile (default, minimal, all, etc.) would only
include bean.xml and other configuration files. Within beans.xml or a
different file, each deployment unit would specify its dependencies,
either through<dependency> elements, or a list of maven artifacts, i.e.
org.jboss.resteasy:resteasy-jaxrs:2.0
That way our distribution can be either very very tiny, just a zip of
text files that point to our maven repository. Or, very optimized, we
ship a maven repository with the distribution that shared between the
different profiles.
This could get very interesting over time. Deployment units could
delegate to the base AS for versioning, much like maven modules delegate
to a parent pom for dependency versions. We could automatically create
scoped deployments or issue warnings if base AS and the deployment unit
require different library versions, etc.
Just a thought...
Bill
7:04 p.m.
Yes, we have said that should be an implementation of the profileservice
repository. Emanuel has done some initial prototyping of this.
Bill Burke wrote:
instead of the way our JBoss AS distribution is structure now, why
not
introduce the idea of maven-based booting and deployment?
Core components (specifically deployers, sars, really anything in the
JBoss domain) of a profile (default, minimal, all, etc.) would only
include bean.xml and other configuration files. Within beans.xml or a
different file, each deployment unit would specify its dependencies,
either through <dependency> elements, or a list of maven artifacts, i.e.
org.jboss.resteasy:resteasy-jaxrs:2.0
That way our distribution can be either very very tiny, just a zip of
text files that point to our maven repository. Or, very optimized, we
ship a maven repository with the distribution that shared between the
different profiles.
This could get very interesting over time. Deployment units could
delegate to the base AS for versioning, much like maven modules delegate
to a parent pom for dependency versions. We could automatically create
scoped deployments or issue warnings if base AS and the deployment unit
require different library versions, etc.
Just a thought...
Bill
7:37 a.m.
On 04/02/2010 02:04 AM, Scott Stark wrote:
Yes, we have said that should be an implementation of the
profileservice
repository. Emanuel has done some initial prototyping of this.
I started a wiki a while ago outlining the current state of this
prototype, in case you are interested:
http://community.jboss.org/wiki/AS6ProfileServiceDesign
Bill Burke wrote:
> instead of the way our JBoss AS distribution is structure now, why not
> introduce the idea of maven-based booting and deployment?
>
> Core components (specifically deployers, sars, really anything in the
> JBoss domain) of a profile (default, minimal, all, etc.) would only
> include bean.xml and other configuration files. Within beans.xml or a
> different file, each deployment unit would specify its dependencies,
> either through<dependency> elements, or a list of maven artifacts, i.e.
>
> org.jboss.resteasy:resteasy-jaxrs:2.0
>
> That way our distribution can be either very very tiny, just a zip of
> text files that point to our maven repository. Or, very optimized, we
> ship a maven repository with the distribution that shared between the
> different profiles.
>
> This could get very interesting over time. Deployment units could
> delegate to the base AS for versioning, much like maven modules delegate
> to a parent pom for dependency versions. We could automatically create
> scoped deployments or issue warnings if base AS and the deployment unit
> require different library versions, etc.
>
> Just a thought...
>
> Bill
>
>
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
6:39 a.m.
IBM has prototyped an OSGi provisioning system based on Felix OBR and
Eclipse P2.
It turned out that Felix OBR was much easier to integrate and they could
get the results they needed only after a couple of days.
cheers
-thomas
On 04/01/2010 11:19 PM, Bill Burke wrote:
instead of the way our JBoss AS distribution is structure now, why
not
introduce the idea of maven-based booting and deployment?
Core components (specifically deployers, sars, really anything in the
JBoss domain) of a profile (default, minimal, all, etc.) would only
include bean.xml and other configuration files. Within beans.xml or a
different file, each deployment unit would specify its dependencies,
either through<dependency> elements, or a list of maven artifacts, i.e.
org.jboss.resteasy:resteasy-jaxrs:2.0
That way our distribution can be either very very tiny, just a zip of
text files that point to our maven repository. Or, very optimized, we
ship a maven repository with the distribution that shared between the
different profiles.
This could get very interesting over time. Deployment units could
delegate to the base AS for versioning, much like maven modules delegate
to a parent pom for dependency versions. We could automatically create
scoped deployments or issue warnings if base AS and the deployment unit
require different library versions, etc.
Just a thought...
Bill
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
3:46 a.m.
Are you saying they dropped P2 or that they used P2 together with Felix OBR ?
P2 is actually very interesting in this respect IMO since it is basically a portable
provisioning system that works on all platforms, has a public API and is not tied
to any specific provisioning format. Thus if you want to use rpm's, zips,
p2-repositories,
maven layout or whatnot it is possible to customize P2 to do it.
That would mean AS could simply focus on the interesting parts (booting) and let P2 do
all the heavy lifting of figuring out proper dependencies and resolution strategies.
/max
On Apr 2, 2010, at 13:39, Thomas Diesler wrote:
IBM has prototyped an OSGi provisioning system based on Felix OBR and
Eclipse P2.
It turned out that Felix OBR was much easier to integrate and they could
get the results they needed only after a couple of days.
cheers
-thomas
On 04/01/2010 11:19 PM, Bill Burke wrote:
> instead of the way our JBoss AS distribution is structure now, why not
> introduce the idea of maven-based booting and deployment?
>
> Core components (specifically deployers, sars, really anything in the
> JBoss domain) of a profile (default, minimal, all, etc.) would only
> include bean.xml and other configuration files. Within beans.xml or a
> different file, each deployment unit would specify its dependencies,
> either through<dependency> elements, or a list of maven artifacts, i.e.
>
> org.jboss.resteasy:resteasy-jaxrs:2.0
>
> That way our distribution can be either very very tiny, just a zip of
> text files that point to our maven repository. Or, very optimized, we
> ship a maven repository with the distribution that shared between the
> different profiles.
>
> This could get very interesting over time. Deployment units could
> delegate to the base AS for versioning, much like maven modules delegate
> to a parent pom for dependency versions. We could automatically create
> scoped deployments or issue warnings if base AS and the deployment unit
> require different library versions, etc.
>
> Just a thought...
>
> Bill
>
>
>
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
4:14 a.m.
it's not weird at all. That's where a few maven repository managers make the real
money:
deployment based on declarative dependency sets.
Iirc think jfrog is one of them.
/heiko
On Apr 1, 2010, at 11:19 PM, Bill Burke wrote:
instead of the way our JBoss AS distribution is structure now, why
not
introduce the idea of maven-based booting and deployment?
7:25 a.m.
It might be more reliable to locally cache the maven resources
(otherwise maven becomes your single point of failure). I wouldn't want
to see an entire cluster halt, just because maven crashed.
Its also not weird to boot/deploy from a version control system either.
Although, the weird thing is when you make direct changes to the cached
application jars, instead of through maven or version control. That
should be avoided but it might not be bad for debugging (drop in a quick
debug jar and later replace with production bits from maven/source
control).
On Tue, 2010-04-06 at 11:14 +0200, Heiko Braun wrote:
it's not weird at all. That's where a few maven repository
managers make the real money:
deployment based on declarative dependency sets.
Iirc think jfrog is one of them.
/heiko
On Apr 1, 2010, at 11:19 PM, Bill Burke wrote:
> instead of the way our JBoss AS distribution is structure now, why not
> introduce the idea of maven-based booting and deployment?
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
10:09 a.m.
The problem with deploying from maven is that maven doesn't encode enough
information to be useful beyond building up a big, flat classpath. But I
think at this point everyone is feeling the pain of flat deployment, which
is why threads like this keep popping up. Add to that the fact that JavaEE
7 is probably going to modular by spec.
Modularity is inevitable, that's why I started
http://community.jboss.org/wiki/JBossASModularizationRequirements ...
On 04/06/2010 04:14 AM, Heiko Braun wrote:
it's not weird at all. That's where a few maven repository managers make the real
money:
deployment based on declarative dependency sets.
Iirc think jfrog is one of them.
/heiko
On Apr 1, 2010, at 11:19 PM, Bill Burke wrote:
> instead of the way our JBoss AS distribution is structure now, why not
> introduce the idea of maven-based booting and deployment?
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
- DML ☍
1:08 p.m.
Few weeks ago, we (QA dept) discussed your second option - to distribute
the deps in a form of maven repository.
Taking our mavenization trend into account, that would be beneficial
because Maven-based testsuites could work with the *ARs from the
distribution without needing to do mvn install:install-file for each
artifact needed in the process.
The problem could be the limited length of classpath on some systems.
Ondra
Bill Burke píše v Čt 01. 04. 2010 v 17:19 -0400:
instead of the way our JBoss AS distribution is structure now, why
not
introduce the idea of maven-based booting and deployment?
Core components (specifically deployers, sars, really anything in the
JBoss domain) of a profile (default, minimal, all, etc.) would only
include bean.xml and other configuration files. Within beans.xml or a
different file, each deployment unit would specify its dependencies,
either through <dependency> elements, or a list of maven artifacts, i.e.
org.jboss.resteasy:resteasy-jaxrs:2.0
That way our distribution can be either very very tiny, just a zip of
text files that point to our maven repository. Or, very optimized, we
ship a maven repository with the distribution that shared between the
different profiles.
This could get very interesting over time. Deployment units could
delegate to the base AS for versioning, much like maven modules delegate
to a parent pom for dependency versions. We could automatically create
scoped deployments or issue warnings if base AS and the deployment unit
require different library versions, etc.
Just a thought...
Bill
1:24 p.m.
Doesn't surefire plug-in overcome the problem using a manifest file?
Ondřej Žižka wrote, On 04/09/2010 09:08 PM (EEST):
Few weeks ago, we (QA dept) discussed your second option - to
distribute
the deps in a form of maven repository.
Taking our mavenization trend into account, that would be beneficial
because Maven-based testsuites could work with the *ARs from the
distribution without needing to do mvn install:install-file for each
artifact needed in the process.
The problem could be the limited length of classpath on some systems.
Ondra
Bill Burke píše v Čt 01. 04. 2010 v 17:19 -0400:
> instead of the way our JBoss AS distribution is structure now, why not
> introduce the idea of maven-based booting and deployment?
>
> Core components (specifically deployers, sars, really anything in the
> JBoss domain) of a profile (default, minimal, all, etc.) would only
> include bean.xml and other configuration files. Within beans.xml or a
> different file, each deployment unit would specify its dependencies,
> either through <dependency> elements, or a list of maven artifacts, i.e.
>
> org.jboss.resteasy:resteasy-jaxrs:2.0
>
> That way our distribution can be either very very tiny, just a zip of
> text files that point to our maven repository. Or, very optimized, we
> ship a maven repository with the distribution that shared between the
> different profiles.
>
> This could get very interesting over time. Deployment units could
> delegate to the base AS for versioning, much like maven modules delegate
> to a parent pom for dependency versions. We could automatically create
> scoped deployments or issue warnings if base AS and the deployment unit
> require different library versions, etc.
>
> Just a thought...
>
> Bill
>
>
------------------------------------------------------------------------
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
12:13 p.m.
It's not only surefire - also WAR plugin, Cargo, and other...
Ondra
Aleksandar Kostadinov píše v Pá 09. 04. 2010 v 21:24 +0300:
Doesn't surefire plug-in overcome the problem using a manifest
file?
Ondřej Žižka wrote, On 04/09/2010 09:08 PM (EEST):
> Few weeks ago, we (QA dept) discussed your second option - to distribute
> the deps in a form of maven repository.
> Taking our mavenization trend into account, that would be beneficial
> because Maven-based testsuites could work with the *ARs from the
> distribution without needing to do mvn install:install-file for each
> artifact needed in the process.
>
> The problem could be the limited length of classpath on some systems.
>
> Ondra
>
>
>
> Bill Burke píše v Čt 01. 04. 2010 v 17:19 -0400:
>> instead of the way our JBoss AS distribution is structure now, why not
>> introduce the idea of maven-based booting and deployment?
>>
>> Core components (specifically deployers, sars, really anything in the
>> JBoss domain) of a profile (default, minimal, all, etc.) would only
>> include bean.xml and other configuration files. Within beans.xml or a
>> different file, each deployment unit would specify its dependencies,
>> either through <dependency> elements, or a list of maven artifacts, i.e.
>>
>> org.jboss.resteasy:resteasy-jaxrs:2.0
>>
>> That way our distribution can be either very very tiny, just a zip of
>> text files that point to our maven repository. Or, very optimized, we
>> ship a maven repository with the distribution that shared between the
>> different profiles.
>>
>> This could get very interesting over time. Deployment units could
>> delegate to the base AS for versioning, much like maven modules delegate
>> to a parent pom for dependency versions. We could automatically create
>> scoped deployments or issue warnings if base AS and the deployment unit
>> require different library versions, etc.
>>
>> Just a thought...
>>
>> Bill
>>
>>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
11:24 a.m.
Few weeks ago, we (QA dept) discussed your second option - to
distribute the deps in a form of maven repository.
Taking our mavenization trend into account, that would be beneficial because Maven-based
testsuites could work with the *ARs from the distribution without needing to do mvn
install:install-file for each artifact needed in the process.
The problem could be the limited length of classpath on some systems.
Combine P2 to be able to use Maven as the source of jars and P2 to put them in the right
place to be used sounds like a good option then.
/max
Ondra
Bill Burke píše v Čt 01. 04. 2010 v 17:19 -0400:
>
> instead of the way our JBoss AS distribution is structure now, why not
> introduce the idea of maven-based booting and deployment?
>
> Core components (specifically deployers, sars, really anything in the
> JBoss domain) of a profile (default, minimal, all, etc.) would only
> include bean.xml and other configuration files. Within beans.xml or a
> different file, each deployment unit would specify its dependencies,
> either through <dependency> elements, or a list of maven artifacts, i.e.
>
> org.jboss.resteasy:resteasy-jaxrs:2.0
>
> That way our distribution can be either very very tiny, just a zip of
> text files that point to our maven repository. Or, very optimized, we
> ship a maven repository with the distribution that shared between the
> different profiles.
>
> This could get very interesting over time. Deployment units could
> delegate to the base AS for versioning, much like maven modules delegate
> to a parent pom for dependency versions. We could automatically create
> scoped deployments or issue warnings if base AS and the deployment unit
> require different library versions, etc.
>
> Just a thought...
>
> Bill
>
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
5316
days inactive
5335
days old
jboss-development@lists.jboss.org
18 comments
13 participants
participants (13)
-
Aleksandar Kostadinov -
Andersen Max -
Anil Saldhana -
Bill Burke -
Carlo de Wolf -
Chris Bredesen -
David M. Lloyd -
Emanuel Muckenhuber -
Heiko Braun -
Ondřej Žižka -
Scott Marlow -
Scott Stark -
Thomas Diesler