April 2007 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Re: Reinstate the top level build project

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | 1) Spot your environment doesn't exist and download the rest (either from svn or the | repository), including creating ide files on the fly | 2) Refork itself and do the main build | You could also do a step zero which was to add a local.properties to choose which of the project's dependencies you wanted as binary and which as development source snaphots. e.g. Imagine being able to develop jboss transactions and jboss appserver in the same workspace using one main build file to rebuild everything. e.g.2. Only rebuilding the jca project in the appserver, using the snapshot binaries from the repository for the rest, instead of recompiling the whole thing all the time :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034655#4034655 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034655

17 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Reinstate the top level build project

by adrian＠jboss.org

"Kevin.Conner(a)jboss.com" wrote : | Deployment could then become simply | - mvn co https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/view/st... | - mvn -PbuildEclipseWorkspace | - run eclipse | | (or something similar) It's funny, but when I did the jbossbuild prototype (some ant plugins that made the build declaritive), this was almost exactly how I had it working. The steps were: mkdir microcontainer cd microcontainer svn co https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/build svn co https://svn.jboss.org/repos/jbossas/trunk/tools ant Which would then internally 1) Spot your environment doesn't exist and download the rest (either from svn or the repository), including creating ide files on the fly 2) Refork itself and do the main build Sadly, I didn't have time to finish it, but that part did work. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034652#4034652 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034652

17 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Reinstate the top level build project

by Kevin.Conner＠jboss.com

"alesj" wrote : When finding a simple solution, don't forget us, humble IDEA users. ;-) rofl. I believe there is a plugin to generate the IDEA setup as well :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034645#4034645 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034645

17 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Reinstate the top level build project

by Kevin.Conner＠jboss.com

Which is why I have been suggesting two things - use subversion to partition the projects so that all IDEs can take advantage of it - modify the maven build so that it creates the workspace At present your suggestion will only ever work on eclipse and there are a number of people who do not use eclipse. If we start pushing this back into a generic jboss project then we can start having this generated automatically and support other IDEs at the same time. We could even extend this to include any formatting/code verification rules. Deployment could then become simply - mvn co https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/view/st... - mvn -PbuildEclipseWorkspace - run eclipse (or something similar) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034644#4034644 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034644

17 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Reinstate the top level build project

by alesj

"adrian(a)jboss.org" wrote : And as I explained before, if I'm working with eclipse When finding a simple solution, don't forget us, humble IDEA users. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034642#4034642 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034642

17 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Reinstate the top level build project

by adrian＠jboss.org

And as I explained before, if I'm working with eclipse, I want to use the features the IDE provides. Not shell out to a command line and find some magic incantation I need to download and run (if I even trust such a script without reading it first :-). Aside: "I" is generic, meaning a normal user, not necessarily me. One of the first things I open everyday is an xterm. :-) In my case, the issue is the "multiple steps" when it should be: file/import/eclipse-project-set <url-to-eclipse.psf> job done. My other issue is the currently redundant eclipse workspace I have to create which is yet another set of manual steps :-( Multiply the "multiple steps" for every project I work with on JBoss and it is going to be a real pain next time I re-install my laptop to recreate my work environments. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034637#4034637 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034637

17 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Bean as a value to a deployment level classloader

by alesj

"adrian(a)jboss.org" wrote : | We should clone and rewrite the ClassLoaderMetaData to replace the nested bean | with an injection and add the bean to the beans in the deployment. | Yup, this one is an oldie in my JIRA tasks. :-( Along with inner beans with no name. But this should all be done as a part of GUID naming rewrite you mentioned in our 'scoped' discussion: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=101320&start=20 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034631#4034631 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034631

17 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Bean as a value to a deployment level classloader

by adrian＠jboss.org

"alesj" wrote : "adrian(a)jboss.org" wrote : | | We don't want to modify the ClassLoaderMetaData set on the deployment by the user! | I don't see what we are modifying in this case? | Your wrote the test case. :-) anonymous wrote : | Probably nothing currently? | Correct. anonymous wrote : | But we should add a dependency on the ClassLoaderMetaData in case actual classloader is inner bean. | We should clone and rewrite the ClassLoaderMetaData to replace the nested bean with an injection and add the bean to the beans in the deployment. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034622#4034622 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034622

17 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Bean as a value to a deployment level classloader

by adrian＠jboss.org

The other failing classloader test is due to the "mock" VFSClassLoader getting used to load kernel classes causing a type inconsistency. This is probably also due to the core kernel classes and the test classes living in the same codesource with the current eclipse configuration. I've hacked this classloader so it only loads classes that begin with "org.jboss.test" | public Class<?> loadClass(String name, boolean flag) | throws ClassNotFoundException | { | | + if (name.startsWith("org.jboss.test") == false) | + return getClass().getClassLoader().loadClass(name); | Which resolves this issue. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034620#4034620 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034620

17 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Reinstate the top level build project

by Kevin.Conner＠jboss.com

"adrian(a)jboss.org" wrote : But you at least need to check it out in the first place, unless you are going to build each project individually. This goes back to the eclipse.psf stuff. But as I tried to say before, this is something than can be 'fixed' using subversion. We can create separate locations in the repository which are responsible for checking out all the required folders, no need for eclipse.psf. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034614#4034614 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034614

17 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums April 2007