February 2008 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Re: Update the relevant .classpath files

by ALRubinger

Indirectly-related, but often helpful is the m2eclipse Plugin: http://m2eclipse.codehaus.org/ ...which I use to not worry about .classpath at all. :) S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133347#4133347 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133347

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Update the relevant .classpath files

by ALRubinger

"adrian(a)jboss.org wrote : How is it different to what you suggest (no .classpath file or an old one they generated before doing the svn update?) Fail-fast. No .classpath is very obviously wrong in Eclipse. An incorrect .classpath might pose as correct (pointing to wrong versions, perhaps). Though I still disagree with storing gen'd files in SCM, I can live with the addition of a Mojo/Plugin to autorun eclipse:eclipse. At the end of the day, this is developer preference, we're debating the architecture of .classpath here. :) "adrian(a)jboss.org" wrote : Of course the real fix is to replace eclipse's java project bundle with an extended one that runs off the pom.xml instead of .classpath ;-) Max/Culpepper/Stryker...get on it. :D S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133344#4133344 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133344

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Domain resolve algorithm

by alesj

"adrian(a)jboss.org" wrote : I'll bet the OSGi TCK is non-disclosure correct? So we need to make sure our | public tests are written "clean room", i.e. no copying of tests and | nobody that has seen the TCK tests writing similar public tests. | Sure, it's like all TCKs, non-disclosure all the way. Yup. Tests then become pita. I guess there is no way of bumping into duplicate effort. It should be the minimization of that duplication that we should work on. Or how to we handle this wtr to other TCKs? "adrian(a)jboss.org" wrote : | That's not to say that you can't raise a bug report describing the problem. ;-) | That harsh? Ouch. You can pretend that you didn't get that error info from tck. :-) "adrian(a)jboss.org" wrote : | I'd be happier porting the relevant eclipse or apache felix tests to our framework | before trying the TCK since those can be distributed under their relevant OS licenses. John? :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133343#4133343 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133343

18 years

1
0
0 / 0

[Design of OSGi Integration] - Re: Logging and Exception Handling

by johnbailey

The other issue I had was getting the MainDeployerImpl and DeployersImpl created at Test bootstrap without creating a project dependency from osgi-int to deployers-impl. Referencing deployers-impl in a test should be ok, correct? It is referenced in the pom already. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133336#4133336 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133336

18 years

1
0
0 / 0

[Design of OSGi Integration] - Re: Logging and Exception Handling

by johnbailey

The mocks just helped me get moving and understand the key players in the MC. ;) I agree mocking is not a long term solution for testing the facade. I have a local TestCase I have been using which loads the OSGI deployers, but I have been waiting for the classloading work to be further along, as the classloader was not set on the DeploymentUnit after the deployment process completes. It looks like a lot of work has been done with the classloading, so I will pull my local OSGI deployer and make sure it follows a similar pattern to the BootstrapDeployersTest and base the facade test off that. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133332#4133332 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133332

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Domain resolve algorithm

by adrian＠jboss.org

I'll bet the OSGi TCK is non-disclosure correct? So we need to make sure our public tests are written "clean room", i.e. no copying of tests and nobody that has seen the TCK tests writing similar public tests. That's not to say that you can't raise a bug report describing the problem. :-) I'd be happier porting the relevant eclipse or apache felix tests to our framework before trying the TCK since those can be distributed under their relevant OS licenses. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133323#4133323 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133323

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Update the relevant .classpath files

by adrian＠jboss.org

"ALRubinger" wrote : | "adrian(a)jboss.org" wrote : Remembering and performing recipes of many tool procedures is not productive | | You're going to have to do it anyway whenever you make changes to the dependencies. | Not if there's a mojo defined in the pom that says, aha the pom is newer than the .classpath file, re-run eclipse:eclipse automagically. "adrian(a)jboss.org" wrote : Redundancy is only a problem when it leads to error or reduced performance This is the root of my concern; an Eclipse user with an outdated classpath. How is it different to what you suggest (no .classpath file or an old one they generated before doing the svn update?) "adrian(a)jboss.org" wrote : Checking in the eclipse files in svn makes little difference in practice unless everybody updates them you have to run mvn eclipse:eclipse anyway. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133318#4133318 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133318

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Domain resolve algorithm

by alesj

"adrian(a)jboss.org" wrote : | I think most of the work will actually be in creating the test coverage. | I'm working on getting the official RI OSGi testsuite/tck into place for our tests (it's gonna take me a while, since the instructions are useless :-)). But this should take care of the OSGi specific usage tests, weather our impl is OSGi compliant. "adrian(a)jboss.org" wrote : | I can think of complicated scenarios in OSGi and for example the scoped domains with (parent first/last) or "importAll" are addtional features beyond what OSGi can do. | Those 'complicated scenarios in OSGi' should already be a part of official testsuite (hopefully, otherwise that tck is rubbish). But for our extensions, it's of course up to us to provide extensive testing. And I would suggest we do that as part of our OSGi tck project. Perhaps eventually putting some stuff back to OSGi, as a possible thoroughly tested extension. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133317#4133317 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133317

18 years

1
0
0 / 0

[Design of OSGi Integration] - Re: Logging and Exception Handling

by adrian＠jboss.org

We need to create a simple helper class so you can bootstrap a minimal deployers impl inside the MC with the OSGi deployers for your unit tests. If you want to do it, look at org.jboss.test.deployers.BootstrapDeployersTest and its related delegate in deployers-vfs as an example. That one is mainly used for testing the classloaders, so it's essentially a cutdown version of JBossAS with only the MC and classloading deployers running inside a JUnit test. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133316#4133316 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133316

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Domain resolve algorithm

by alesj

"adrian(a)jboss.org" wrote : | Like I said elsewhere, "I know how to do it". | OK, I'll leave it up to you then. :-) I could see that you have things in place for straight fwd wire-ing. I just wasn't sure if we wanted to handle the re-wire-ing atm. Since it would probably require some more work on the algorithm impl. That's where the hand for help came from. ;-) And I'm a sucker for such open challenges. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133315#4133315 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133315

18 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums February 2008