modules backed by a repo part 2
by Bill Burke
1) Anybody know why jboss-seam-int-jbossas is copied directly into a
bundle/ directory of its module? And doesn't use <module-def> in the
build script?
2) After you'd convert all modules to reference a maven artifact,
there's still the bundles and client jars left. 28.7M. OSGi isn't
enabled by default right? So these bundles aren't needed unless you're
doing OSGi?
3) How could our OSGi bundles be supported in this maven repo model? Is
it JBoss OSGi that locates and loads the bundles?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years, 9 months
Add Notification support to the domain management API
by Jeff Mesnil
I've started to work on [AS7-370] Add Notification support to the domain management API[1].
To make sure we agree on the content and scope of this task, I've created a doc on our dev forum summarizing what I intend to do (and not do) about this[2].
It's a simple draft but I'd appreciate any feedback on this.
I'm particularly interested by the use cases what would benefit from such notifications (Web Console, auditing, others…) to make sure they'd be covered by the requirements.
I'm trying to keep this as simple as possible for subsystems to leverage notifications without too much involvement while making sure there are no performance or memory penalty for the AS7 to handle them.
jeff
[1] https://issues.jboss.org/browse/AS7-370
[2] https://community.jboss.org/wiki/AddNotificationSupportToTheDomainManagem...
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
11 years, 9 months
AS8 smoke test failure
by Frank Langelage
Since today after update of sources from github.com I see
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running org.jboss.as.protocol.mgmt.RemoteChannelManagementTestCase
23:31:19,641 INFO (main) [org.xnio] <Xnio.java:73> XNIO Version 3.1.0.Beta9
23:31:19,789 INFO (main) [org.xnio.nio] <NioXnio.java:51> XNIO NIO
Implementation Version 3.1.0.Beta9
23:31:19,923 INFO (main) [org.jboss.remoting] <EndpointImpl.java:70>
JBoss Remoting version 3.2.15.GA
Tests run: 22, Failures: 0, Errors: 22, Skipped: 0, Time elapsed: 1.771
sec <<< FAILURE!
Results :
Tests in error:
testExceptionInRequestHandlerWrite(org.jboss.as.protocol.mgmt.RemoteChannelManagementTestCase):
sun.nio.ch.EPollArrayWrapper.sizeofEPollEvent()I
testExceptionInRequestHandlerWrite(org.jboss.as.protocol.mgmt.RemoteChannelManagementTestCase)
testCancelAsyncTask(org.jboss.as.protocol.mgmt.RemoteChannelManagementTestCase):
Could not initialize class sun.nio.ch.EPollArrayWrapper
testCancelAsyncTask(org.jboss.as.protocol.mgmt.RemoteChannelManagementTestCase)
testMissingRequestHandler(org.jboss.as.protocol.mgmt.RemoteChannelManagementTestCase):
Could not initialize class sun.nio.ch.EPollArrayWrapper
testMissingRequestHandler(org.jboss.as.protocol.mgmt.RemoteChannelManagementTestCase)
testTwoSimpleRequests(org.jboss.as.protocol.mgmt.RemoteChannelManagementTestCase):
Could not initialize class sun.nio.ch.EPollArrayWrapper
testTwoSimpleRequests(org.jboss.as.protocol.mgmt.RemoteChannelManagementTestCase)
testExceptionInRequestHandlerRead(org.jboss.as.protocol.mgmt.RemoteChannelManagementTestCase):
Could not initialize class sun.nio.ch.EPollArrayWrapper
testExceptionInRequestHandlerRead(org.jboss.as.protocol.mgmt.RemoteChannelManagementTestCase)
testNoResponse(org.jboss.as.protocol.mgmt.RemoteChannelManagementTestCase):
Could not initialize class sun.nio.ch.EPollArrayWrapper
testNoResponse(org.jboss.as.protocol.mgmt.RemoteChannelManagementTestCase)
testMissingOperationHandler(org.jboss.as.protocol.mgmt.RemoteChannelManagementTestCase):
Could not initialize class sun.nio.ch.EPollArrayWrapper
testMissingOperationHandler(org.jboss.as.protocol.mgmt.RemoteChannelManagementTestCase)
testSimpleRequest(org.jboss.as.protocol.mgmt.RemoteChannelManagementTestCase):
Could not initialize class sun.nio.ch.EPollArrayWrapper
testSimpleRequest(org.jboss.as.protocol.mgmt.RemoteChannelManagementTestCase)
testSeveralConcurrentSimpleRequests(org.jboss.as.protocol.mgmt.RemoteChannelManagementTestCase):
Could not initialize class sun.nio.ch.EPollArrayWrapper
testSeveralConcurrentSimpleRequests(org.jboss.as.protocol.mgmt.RemoteChannelManagementTestCase)
testAwaitCompletion(org.jboss.as.protocol.mgmt.RemoteChannelManagementTestCase):
Could not initialize class sun.nio.ch.EPollArrayWrapper
testAwaitCompletion(org.jboss.as.protocol.mgmt.RemoteChannelManagementTestCase)
testExceptionInRequestWrite(org.jboss.as.protocol.mgmt.RemoteChannelManagementTestCase):
Could not initialize class sun.nio.ch.EPollArrayWrapper
testExceptionInRequestWrite(org.jboss.as.protocol.mgmt.RemoteChannelManagementTestCase)
Tests run: 22, Failures: 0, Errors: 22, Skipped: 0
See also attached files.
Platform is SPARC Solaris 10.
11 years, 9 months
Do new model attributes require manual setup of transformers?
by Jaikiran Pai
I've been trying to implement a new feature which requires the addition
of a new model attribute for the EJB3 subsystem root resource. This
model attribute is supposed to be "mandatory" (i.e. non-nullable at
model level and "required" at xml level). All works fine without
bringing into picture older versions of the model. Now while testing
with older versions of the model and compatibility, things start failing
for obvious reasons- the older model handlers, parsers etc... have no
clue about this new attribute. I'm aware that that's where the
transformers come into picture and I've setup an appropriate transformer
that is supposed to handle this scenario. But, the transformers tests in
EJB3SubsystemUnitTestCase fails for different test methods. I had to dig
a bit into the code to figure out that one of the failures had to do
with the test case itself rather than the new code.
One part of the problem and the main reason why I decided to ask this
via a mail instead of over IRC is because, I've been having a difficult
time with the transformer APIs and its usage. On a higher level I
(think) I do understand what the transformers are supposed to do and how
to deal with individual attribute/resource changes when multiple
versions of the model come into picture. But when it comes to wiring the
right transformers at the right place in the code or figuring out what
such places are or even debugging failing tests, I find it not so
straightforward to understand what's going on. Perhaps it's just that I
am not yet used to those APIs. To be honest, with whatever transformer
code I've added, although it seems to work to a certain extent, I'm not
confident about the code I'm adding - I've been just looking at other
places and copying over the code wherever appropriate.
So back to the original issue and the related question - would it be
possible to "automate" this process of plugging in these transformers?
In this specific case, for example, I think almost all (there maybe be
exceptions) subsystems and resources introducing a new attribute in the
higher model would expect that that attribute to be ignored (I'm not
using the term discarded or rejected because I am not 100% sure I
understand the difference yet :) ) by lower versions of the model. So
instead of me trying to figure out where to plugin these transformers,
would it be possible to *dynamically* generate these transformers for
some of these cases? That way I wouldn't have to deal with these for
every new attribute and instead be assured that this would be handled
centrally at some place?
P.S: If someone wants to take a look at the (failing WIP) code that I'm
talking about, then let me know, I can push my code to github. I wanted
to keep this mail to be broader than just this specific failing case.
-Jaikiran
11 years, 9 months
Subsystem model version for AS8
by Tomaž Cerar
Hi,
I remember few discussions on IRC in last weeks(s) about how to handle
version bumps for subsystem model when changes are done on AS8 codebase.
It was somewhat agreed that instead of bumping minor version we should
upgrade major version.
aka instead of doing 1.2 --> 1.3, new version should be 2.0
That gives us flexibility of bumping minor version to 7.x codebase if need
arises.
I am writing this as there was some PRs lately that bump just minor version.
So, can we get an agreement of new versioning rules, that we will then
follow.
I personalty favor major version bumps...
--
tomaz
11 years, 9 months
Comparison of JMX information model and AS7 resource model
by Jeff Mesnil
While working on adding AS7 notifications[1], I had an extensive look at the JMX information model to see how it modelizes notifications.
I took the opportunity to make a comparison of the whole JMX information model (including the extension for Model MBeans) to the AS7 resource model[2]
Notifications are the main thing missing in the AS7 resource model.
We have additional info (esp. a tree hierarchy) but there are some informations that JMX provides and we do not.
Amon the interesting info that we are missing:
- deprecated => we have deprecated info for attribute and operation but not for the resource as a whole
- since => we have no information on when a resource/attribute/operation has been added
- displayName => we have no human-readable info suitable for display (e.g. "JMS Queue" for jms-queue resource, same for attribute and operation names)
- lastUpdatedTimeStamp => when an attribute has been updated for the last time
Additionally, JMX's ObjectName can define patterns. AS7 PathAddress allows only wildcard for the path element value (e.g. /subsystem=messaging/hornetq-server=*/jms-queue=*) but not for a path element itself (e.g. /subsystem=messaging/* to match child of the subystem).
The only use case where I would like to be able to use such a pattern is to register notifications more simply (i.e., send me any notifications for the messaging subsystem is simpler if I can use something like Ant's file pattern such as /subsystem=messaging/**/* instead of having to iterate on all the resource in the tree).
Some of these infos could be added to AS8 resource model.
If we find that these missing infos are interesting, we could add them to AS8 resource model.
[1] https://issues.jboss.org/browse/AS7-370
[2] https://docs.google.com/spreadsheet/ccc?key=0AgnxDyYwHtqVdE9RaW9IM2lZbzBo... sorry for the color blind :)
[3] http://ant.apache.org/manual/dirtasks.html
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
11 years, 9 months
About the getSecurityManager() optimization
by David M. Lloyd
We have, in our core code and frameworks, a few chunks of code like this:
if (getSecurityManager() == null) {
doSomePrivilegedThing();
} else {
AccessController.doPrivileged(new PrivilegedThingAction());
}
The idea is that doPrivileged and the action GC load is a cost we should
not pay if there's no security manager.
There is a potential problem here though. It is possible to install a
security manager after the server is started. While this may sound like
an odd thing to do, we know that at least one third-party library does
in fact install a security manager if you don't prevent it from doing
so. Furthermore, as we're required to support running under a security
manager, we were talking about allowing the subsystem to install a
security manager during extension init instead of requiring it to be
sent in to the command at boot.
The problem is that if you set a security manager during the window
between when the presence of a security manager is checked for, and when
the privileged action runs, you run the risk of getting a random
SecurityException. We'll call this problem "the SM race".
It seems to me that we have a few options for supporting running under a
security manager:
1) Require it to be specified at boot (pass -secmgr to JBoss Modules in
the start script)
2) Let it be set by a security manager subsystem
3) Just run with a security manager at all times
Only #1 would allow the above optimization to work, and that's only if
nobody else sets a security manager in the meantime.
Given that fact, coupled with the observation that running under a
security manager does not appear to significantly impact server boot
time, I'm wondering if we should get rid of this optimization wherever
it appears and just always use doPrivileged.
Maybe once we see what kind of time impact -secmgr has on the test
suite, we'll know whether this is a reasonable course of action (I would
expect the performance impact to be somewhere between running with and
without a security manager for the non-SM case, and of course no impact
for the SM case).
--
- DML
11 years, 9 months
Removing JAXR & backward compatiblity
by Thomas Diesler
Folks,
related to
* [AS7-6612] Remove JAXR support
I'd like to know whether we need to preserve backward compatibility of the configuration and if so what should happen if there is a jaxr config item? Generally, can AS8 break backward compatibility with respect to the config?
cheers
--thomas
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
11 years, 10 months
Re: [jboss-as7-dev] Removing JAXR & backward compatiblity
by Tomaž Cerar
that is why i would suggest packaging this modules in special folder
under our distribution that would only be accessible by domain controller
itself.
This way we make sure this modules only operate in MODEL stage.
Sure noting stops user from moving this modules to some other folder,
but he could also copy them from older version....
Other option would be to do model version checking, aka if module name is
org.jboss.as.*
and major version is < 2 we would not allow runtime stage to be executed.
That brings some more complexity and forces us to bump major version for
all subsystems
On Sat, Mar 2, 2013 at 12:15 AM, Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
> When I say "find problems" I don't mean management problems. I mean
> runtime service bugs. If we ship the 7.2 CMP module and someone runs it on
> an AS8 server and reports an EJBQL parsing bug, how do we respond?
>
>
> On 3/1/13 5:07 PM, Tomaž Cerar wrote:
>
>> hmm, given that DC only operates on MODEL/ADMIN stage
>> there should no big issues if we make sure our model driven api is
>> compatible also in AS8.
>> I think that would be mostly jboss-as-controller and maybe few more.
>> But before I speculate, I should test my theory...
>> --
>> tomaz
>>
>>
>> On Fri, Mar 1, 2013 at 11:55 PM, Brian Stansberry
>> <brian.stansberry(a)redhat.com <mailto:brian.stansberry@**redhat.com<brian.stansberry(a)redhat.com>>>
>> wrote:
>>
>> They have to have logic that prevents their use on an AS8 server.
>> Unless we are willing to tell folks who use them on AS8 servers and
>> find problems that they're out of luck and should know better.
>>
>>
>> On 3/1/13 4:49 PM, Tomaž Cerar wrote:
>>
>> What about if we just use legacy extensions that would be loaded
>> only on DC?
>> for legacy i mean, why not just have modules / jars from 7.2 in
>> 8.0 distro?
>> that would make it easiest to support, and no extra work.
>> We should just put them in some special place in distro,
>> so it would be obvious that is legacy stuff only DC uses...
>>
>>
>> On Fri, Mar 1, 2013 at 11:44 PM, Brian Stansberry
>> <brian.stansberry(a)redhat.com
>> <mailto:brian.stansberry@**redhat.com<brian.stansberry(a)redhat.com>
>> >
>> <mailto:brian.stansberry@__red**hat.com <http://redhat.com>
>>
>> <mailto:brian.stansberry@**redhat.com<brian.stansberry(a)redhat.com>>>>
>> wrote:
>>
>> The extension registration logic would have to be altered
>> to not barf
>> when multiple aliases all try to register the same
>> extensions/
>> subsystems.
>>
>> But it probably should still barf if a user tried to do
>> that for some
>> other reason. So which is happening needs to be clarified.
>>
>> A way to do that is to use something other than
>> org.jboss.as.controller.__**Extension for the ServiceLoader
>>
>> (i.e. first try
>> ServiceLoader for "LegacyExtension" and then if not there
>> try for
>> org.jboss.as.controller.__**Extension.) That's hacky though
>>
>> unless there is
>> a real difference in the service API between Extension and
>> what these
>> legacy extensions do. AFAICT though, there is no API
>> difference;
>> difference is only in impl.
>>
>> On 3/1/13 4:23 PM, David M. Lloyd wrote:
>> > Rewinding the discussion a bit :)
>> >
>> > If we just had one compat module (with N pure aliases),
>> it could
>> easily
>> > register all the subsystems for all the modules at that
>> time
>> (subsystem
>> > registration is pretty lightweight these days, or so it
>> seems at a
>> > glance). If extra subsystems are available as a result
>> of an
>> extension
>> > reg I don't see that as harmless.
>> >
>> > On 03/01/2013 02:48 PM, Brian Stansberry wrote:
>> >> I'm not sure how the ServiceLoader part would work
>> there. At
>> least not
>> >> with what I imagine when I think of an "alias." With
>> some kind
>> of stub
>> >> where each has a different
>> >> META-INF/services/org.jboss.__**as.controller.Extension
>>
>> file it
>> could work.
>> >>
>> >> On 3/1/13 2:29 PM, David M. Lloyd wrote:
>> >>> Yeah, I was thinking they could just be aliases or
>> stubs though.
>> >>>
>> >>> On 03/01/2013 02:22 PM, Brian Stansberry wrote:
>> >>>> In terms of code organization, perhaps. But the way the
>> extension is
>> >>>> activated in the HCs and servers is via the module
>> name. So if
>> you want
>> >>>> a 7.2 server to be able to run CMP, there is going to
>> have to be a
>> >>>> module named org.jboss.as.cmp.
>> >>>>
>> >>>> On 3/1/13 2:13 PM, David M. Lloyd wrote:
>> >>>>> I wonder - should we retain a skeletal version of
>> each of
>> these modules?
>> >>>>> I was thinking maybe it would be better to
>> maintain
>> one big
>> >>>>> "removed-subsystems" or "compat-subsystems" module or
>> something like
>> >>>>> that where we can neatly/consistently organize all
>> the model
>> stuff for
>> >>>>> these removals.
>> >>>>>
>> >>>>> On 03/01/2013 09:39 AM, Brian Stansberry wrote:
>> >>>>>> Thanks Thomas, for raising this and for the JIRA.
>> >>>>>>
>> >>>>>> I've outlined what I think is needed for the stub
>> extensions
>> as a
>> >>>>>> comment on
>> https://issues.jboss.org/__**browse/AS7-6656<https://issues.jboss.org/__browse/AS7-6656>
>>
>> <https://issues.jboss.org/**browse/AS7-6656<https://issues.jboss.org/browse/AS7-6656>>
>> .
>> >>>>>>
>> >>>>>> Can I request that folks hold up on deleting these
>> subsystems? I think
>> >>>>>> it will be easier to make these changes and then
>> delete the
>> unneeded
>> >>>>>> runtime stuff than it will be to semi-restore from
>> history
>> and then change.
>> >>>>>>
>> >>>>>> The ones that have already been deleted, it's no
>> big deal.
>> >>>>>>
>> >>>>>> On 2/28/13 10:35 AM, Thomas Diesler wrote:
>> >>>>>>> Ok, stub extensions is the obvious alternative to
>> breaking
>> compatibility. I'll leave this as a future task and create
>> a jira
>> for it if that's ok with you.
>> >>>>>>>
>> >>>>>>> cheers
>> >>>>>>> --thomas
>> >>>>>>>
>> >>>>>>> On Feb 28, 2013, at 4:22 PM, David M. Lloyd
>> <david.lloyd(a)redhat.com <mailto:david.lloyd@redhat.com**>
>> <mailto:david.lloyd@redhat.com
>>
>> <mailto:david.lloyd@redhat.com**>__>> wrote:
>> >>>>>>>
>> >>>>>>>> On 02/28/2013 05:57 AM, Thomas Diesler wrote:
>> >>>>>>>>> Folks,
>> >>>>>>>>>
>> >>>>>>>>> related to
>> >>>>>>>>>
>> >>>>>>>>> * [AS7-6612
>> <https://issues.jboss.org/__**browse/AS7-6612<https://issues.jboss.org/__browse/AS7-6612>
>>
>> <https://issues.jboss.org/**browse/AS7-6612<https://issues.jboss.org/browse/AS7-6612>
>> >>]
>> Remove JAXR support
>> >>>>>>>>>
>> >>>>>>>>> I'd like to know whether we need to preserve
>> backward
>> compatibility of
>> >>>>>>>>> the configuration and if so what should happen
>> if there
>> is a jaxr config
>> >>>>>>>>> item? Generally, can AS8 break backward
>> compatibility
>> with respect to
>> >>>>>>>>> the config?
>> >>>>>>>>
>> >>>>>>>> Brian points out that we don't have a specific
>> requirement
>> to maintain
>> >>>>>>>> compatibility with obsolete subsystems. I think
>> we could
>> go ahead with
>> >>>>>>>> the removal (granted part of the reason I feel
>> this way is
>> that I've
>> >>>>>>>> already removed JSR-88...).
>> >>>>>>>>
>> >>>>>>>> Going forward though Kabir suggested that if we
>> do want
>> to, say, allow
>> >>>>>>>> 7.x instances to be managed from an 8.x DC, that
>> we should
>> create "stub"
>> >>>>>>>> extensions for the removed stuff that only carry
>> and validate
>> >>>>>>>> configuration but aren't actually supported on 8.x
>> servers. This seems
>> >>>>>>>> like a valid possibility to me.
>> >>>>>>>> --
>> >>>>>>>> - DML
>> >>>>>>>> ______________________________**
>> ___________________
>>
>> >>>>>>>> jboss-as7-dev mailing list
>> >>>>>>>> jboss-as7-dev(a)lists.jboss.org
>> <mailto:jboss-as7-dev@lists.**jboss.org<jboss-as7-dev(a)lists.jboss.org>
>> >
>> <mailto:jboss-as7-dev@lists.__**jboss.org <http://jboss.org>
>> <mailto:jboss-as7-dev@lists.**jboss.org<jboss-as7-dev(a)lists.jboss.org>
>> >>
>>
>> >>>>>>>>
>> https://lists.jboss.org/__**mailman/listinfo/jboss-as7-dev<https://lists.jboss.org/__mailman/listinfo/jboss-as7-dev>
>>
>> <https://lists.jboss.org/**mailman/listinfo/jboss-as7-dev<https://lists.jboss.org/mailman/listinfo/jboss-as7-dev>
>> **>
>> >>>>>>>
>> >>>>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> >>>>>>> Thomas Diesler
>> >>>>>>> JBoss OSGi Lead
>> >>>>>>> JBoss, a division of Red Hat
>> >>>>>>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> ______________________________**___________________
>>
>> >>>>>>> jboss-as7-dev mailing list
>> >>>>>>> jboss-as7-dev(a)lists.jboss.org
>> <mailto:jboss-as7-dev@lists.**jboss.org<jboss-as7-dev(a)lists.jboss.org>
>> >
>> <mailto:jboss-as7-dev@lists.__**jboss.org <http://jboss.org>
>> <mailto:jboss-as7-dev@lists.**jboss.org<jboss-as7-dev(a)lists.jboss.org>
>> >>
>>
>> >>>>>>>
>> https://lists.jboss.org/__**mailman/listinfo/jboss-as7-dev<https://lists.jboss.org/__mailman/listinfo/jboss-as7-dev>
>>
>> <https://lists.jboss.org/**mailman/listinfo/jboss-as7-dev<https://lists.jboss.org/mailman/listinfo/jboss-as7-dev>
>> **>
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>
>> >>
>> >
>> >
>>
>>
>> --
>> Brian Stansberry
>> Principal Software Engineer
>> JBoss by Red Hat
>> ______________________________**___________________
>>
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org
>> <mailto:jboss-as7-dev@lists.**jboss.org<jboss-as7-dev(a)lists.jboss.org>
>> >
>> <mailto:jboss-as7-dev@lists.__**jboss.org <http://jboss.org>
>> <mailto:jboss-as7-dev@lists.**jboss.org<jboss-as7-dev(a)lists.jboss.org>
>> >>
>> https://lists.jboss.org/__**mailman/listinfo/jboss-as7-dev<https://lists.jboss.org/__mailman/listinfo/jboss-as7-dev>
>>
>> <https://lists.jboss.org/**mailman/listinfo/jboss-as7-dev<https://lists.jboss.org/mailman/listinfo/jboss-as7-dev>
>> **>
>>
>>
>>
>>
>> --
>> Brian Stansberry
>> Principal Software Engineer
>> JBoss by Red Hat
>>
>>
>>
>
> --
> Brian Stansberry
> Principal Software Engineer
> JBoss by Red Hat
>
11 years, 10 months
sisu and spymemcached
by Fernando Nasser
Hi guys,
I found these in our todo tag (for building the EAP AS in Brew) these artifats:
org.sonatype.forge-forge-parent-9-1 jb-eap-6-rhel-6-todo jsanda
org.sonatype.oss-oss-parent-5-1 jb-eap-6-rhel-6-todo dfediuck
org.sonatype.sisu-sisu-inject-2.2.3-1 jb-eap-6-rhel-6-todo jsanda
org.sonatype.sisu-sisu-inject-bean-2.2.3-1 jb-eap-6-rhel-6-todo jsanda
org.sonatype.sisu-sisu-inject-plexus-2.2.3-1 jb-eap-6-rhel-6-todo jsanda
org.sonatype.sisu-sisu-parent-2.2.3-1 jb-eap-6-rhel-6-todo jsanda
org.sonatype.sisu.inject-containers-2.2.3-1 jb-eap-6-rhel-6-todo jsanda
org.sonatype.sisu.inject-guice-bean-2.2.3-1 jb-eap-6-rhel-6-todo jsanda
org.sonatype.sisu.inject-guice-plexus-2.2.3-1 jb-eap-6-rhel-6-todo jsanda
spy-spymemcached-2.8.0-1 jb-eap-6-rhel-6-todo mikeb
They do not have todo versions and are not included in the AS we ship, it is not
in our POM, so they must be some build-time indirect dependencies.
I see our BOM has:
<version.org.sonatype.sisu>3.0.3</version.org.sonatype.sisu>
but it is just the property, no <dependency> entry for this at all in the DM.
Note the version is considerably different.
Similar for spy-spymemcached
Do we really need those to build the AS? Can we exclude these perhaps?
Thanks for any help.
Cheers,
Fernando
11 years, 10 months
