-
1. Re: So what is required to allow jboss projects to be updata
I'm not exactly sure what you want to do here (maybe push out JBoss updates via Eclipse' update manager?)..
But yes, it is a common practice to bundle a plugin that contains nothing but JARs and then depend on that plugin as part of your UI plugin's classpath. -
2. Re: So what is required to allow jboss projects to be updata
Yes, potentially the jboss jems components could be integrated as plugins to allow for simpler updates. Issues:
- This should tie into the existing repository.jboss.com mechanism used for binary dependencies in the project builds. What are the requirements for the update site?
- Can the existing jboss ide plugin dependencies on jboss jars be refactored to go through a library plugin? -
3. Re: So what is required to allow jboss projects to be updata
Concerning jBPM there is indeed a jbpm core plugin, containing an entire jBPM installation and all the dependencies. I planned to look at the first issue (using repository.jboss.com for building this) this week, but I had no time and will have to postpone it til next week. But I am quite sure this should be possible.
The answer for jBPM on the second issue is also yes. -
4. Re: So what is required to allow jboss projects to be updata
- This should tie into the existing repository.jboss.com mechanism used for binary dependencies in the project builds. What are the requirements for the update site?
This could get interesting ... technically an update site is just a glorified http file repository, with an XML descriptor that describes which plugins are where. I think the main technical hurdle here would be maintaining / generating the site.xml. It's possible that it could be part of the process of committing a new version of a component that is somehow automated by Ant or the like.Can the existing jboss ide plugin dependencies on jboss jars be refactored to go through a library plugin?
Yes, I think this would be relatively trivial.. It might require some changes in the ide build system too. -
5. Re: So what is required to allow jboss projects to be updata
Scott,
When you say "jboss components" are you referring to JBoss AS components or JBoss IDE components ?
The IDE already is divided into plugins and features that are available via the updatesite.
I don't follow the advantage of having JBoss AS components as seperate plugin/features available via the update site - could you elaborate ?
/max -
6. Re: So what is required to allow jboss projects to be updata
p.s. the reason i don't see the advantage is that it would only be the jboss ide plugins that will use these library plugins since I doubt users would like to have eclipse liked plugin/features directory layouts for all their used libraries...which is a requirement for the updatesite to work as far as i know.
-
7. Re: So what is required to allow jboss projects to be updata
p.p.s. and if we really wanted it then all the MANIFEST.MF of the jars needed to be osgi compliant but it would still be "weird" to use and extremely hard to manage the dependencies i think.
-
8. Re: So what is required to allow jboss projects to be updata
Max, I think Scott's idea is to try and distribute different JEMS projects (i.e. JBoss AS) via the Eclipse Update Site mechanism so that automatic updates can be rolled out to our users relatively seemlessly.
-
9. Re: So what is required to allow jboss projects to be updata
I'm referring to jboss jems components. This any project which has jars which we need to integrate into the ide. Today JBossAS, JBossSeam, JBoss jBPM, JBossAOP, Hibernate, ...
The best usecase is to speed up user interaction with updates to components that have a lot of binary dependencies, seam for example. The main problem is whether or not the ide plugins will function with the changes, but as the ide plugin updates are pushed out, things should be in synch.
I'm not looking at the eclipse update mechanism as an installer for jems changes, but that might also be a way to allow users to more easily migrate to new release versions. -
10. Re: So what is required to allow jboss projects to be updata
"max.andersen@jboss.com" wrote:
p.p.s. and if we really wanted it then all the MANIFEST.MF of the jars needed to be osgi compliant but it would still be "weird" to use and extremely hard to manage the dependencies i think.
I have been looking at the osgi bundle version stuff but need to use it to get a feel for how usable the package level version statements are. It does seem too fine grained, but maybe it can be generated from the jar level dependencies. -
11. Re: So what is required to allow jboss projects to be updata
i still don't see the advantage/need for jems components to be updated via the eclipse structure specific update manager...mainly because i don't see what the usecase is.
Is it for jboss users to get the latest version of their libraries to use in their application ? (what does an eclipse update manager help here ?)
Is it for the jboss ide's plugins to include the latest libraries then what is different from this and what we do now ? (e.g. releasing updates of the ide when there is new features which utilizes updated libraries) -
12. Re: So what is required to allow jboss projects to be updata
If we are pushing out new stuff and want feedback, today it requires users to interact at the cvs level. It would be good to get to the point of having nightly builds of user docs and binaries that could be updated into an eclipse project to speed up the feeback loop. Maybe its not practical to allow such updates to ide plugin projects because of versioning issues, but I'm just interested in exploring how we can make better use of the jboss ide project.
-
13. Re: So what is required to allow jboss projects to be updata
Hmm.. we have nightly binary downloads from here:
http://download.jboss.org/jbosside/builds/nightly
The only things we're missing I guess is Documentation builds and source builds.. -
14. Re: So what is required to allow jboss projects to be updata
Hi,
I believe in keeping things simple and if the goal is to have a mechanism that allows our users to get more easy access to the latest and greatest before there is an actual release of things then I see the following scenario:
#1
The latest and greatest things is always in cvs/svn so users can always get the latest from here and it already has a built in update mechanism (cvs update)
#2
#1 is what I would expect most users that are capable or want to give feedback uses, but in some projects (like jboss IDE and JBoss Seam) with larger dependencies and "complex" builds it is much better to provide nightly builds which should be made available automatically on our download.jboss.org site (example is http://download.jboss.org/jbosside/builds/nightly and artifacts from cruisecontrol)
So my question is - what does setting up a eclipse update site for these "on the edge" jars provide users that we don't get from #1 and #2 ?
#1 has everything covered, but requires users to have access to cvs + understand how to run "cvs update" and a following ant build or similar
#2 provides easy access but does not have an update mechanism...
An eclipse update mechanism could solve that for #2 but it requires unique versioning and bundeling of the nightlybuilds + the output is placed deeply in the users eclipse plugin directory which is far from optimal if the target is ease-of-use.
So my point is that for the usecase: "getting the latest-greatest" #1 and #2 is the best solution.
Coming back to how we could enhance the jems tutorial experiences then bundeling the tutorials with latest *releases* (be it beta or whatnot) not nightly builds makes perfect sense for JBoss IDE eclipse users. The stuff Mark(?) did as an example for the jboss as training material might be a good starting point for that.
Am i off the beat?