13 Replies Latest reply on Jan 28, 2009 5:02 AM by Kamil Demecki

    Ejb3 sources in zipped form

    Kamil Demecki Novice

      Can sources be downloaded in zipped form (like binary distribution on http://www.jboss.org/jbossejb3/downloads/) or only from http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/ ?

      I understand that JBoss-5.0.0.GA-src doesn't contain sources of Ejb3 but only integration with Ejb3 ?

        • 1. Re: Ejb3 sources in zipped form
          Andrew Rubinger Master

          Sure, but at the moment, each EJB3 component has its own source artifact:

          http://repository.jboss.org/maven2/org/jboss/ejb3/

          At time of this writing, each component is at 1.0.0. This is subject to change. :)

          Short answer: all sources are available, but there's no composite JAR with all of 'em in one artifact.

          S,
          ALR

          • 2. Re: Ejb3 sources in zipped form
            Kamil Demecki Novice

            Thanks. Very good that are sources on maven repo at one http adress ;).

            I see that EJB3 project is so mavenized that there is no common tags in http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/tags/. I think it is drawback.

            At least there is plus that all ejb3 artifacts have common version number. I'm pro develop one component (here ejb3) in coherent one way, even it is divide into libraries. My tree cents.

            • 3. Re: Ejb3 sources in zipped form
              Carlo de Wolf Master

              The aim of the game here is to get one set of stable components which are certified against EJB 3.0 specs. Since it's a lengthy process to ascertain both certification and stability I want these components to stay solidly in place for a long time.

              On top of this we'll develop new components to add the extra features required by EJB 3.1 and other feature packs:
              - class based queuing for invocations
              - clustered timer service
              etc.

              The feature packs will have a separate release cycle. So you might see an EJB 3.1 installer for AS 5.1 (while the basic installation is JavaEE 5 / EJB 3.0).

              So you're seeing multiple components in the repository. It is even possible to use these components outside of EJB 3 scope.

              What we don't have yet is a nice graph which shows a good view of these components. So if anybody has some suggestions?

              • 4. Re: Ejb3 sources in zipped form
                Andrew Rubinger Master

                 

                "wolfc" wrote:
                The feature packs will have a separate release cycle.


                As do each of the components that together compose "EJB3".

                "skajotde" wrote:
                At least there is plus that all ejb3 artifacts have common version number


                ...but because of the separate release cycles, the components will not have common versions with the composite for long. :) Because once a component is stable, there's no need to re-release it as another version until some bug or feature request comes along requiring changes.

                S,
                ALR

                • 5. Re: Ejb3 sources in zipped form
                  Kamil Demecki Novice

                   

                  "wolfc" wrote:
                  The aim of the game here is to get one set of stable components which are certified against EJB 3.0 specs. Since it's a lengthy process to ascertain both certification and stability I want these components to stay solidly in place for a long time.

                  On top of this we'll develop new components to add the extra features required by EJB 3.1 and other feature packs:
                  - class based queuing for invocations
                  - clustered timer service
                  etc.

                  The feature packs will have a separate release cycle. So you might see an EJB 3.1 installer for AS 5.1 (while the basic installation is JavaEE 5 / EJB 3.0).


                  Yes, EJB 3 specs is challenge.

                  "wolfc" wrote:


                  So you're seeing multiple components in the repository. It is even possible to use these components outside of EJB 3 scope.

                  What we don't have yet is a nice graph which shows a good view of these components. So if anybody has some suggestions?


                  I think it is great that library can be used outside EJB3 and provides model and metatada. But main purposes of this libraries are be part of EJB3 product so I think it should be versioned in one way with one version number for releases of all libraries. So change in library-a should increase version in all libraries ?





                  • 6. Re: Ejb3 sources in zipped form
                    Andrew Rubinger Master

                     

                    "skajotde" wrote:
                    I think it is great that library can be used outside EJB3 and provides model and metatada. But main purposes of this libraries are be part of EJB3 product so I think it should be versioned in one way with one version number for releases of all libraries. So change in library-a should increase version in all libraries ?


                    I have two arguments.

                    1) It takes time/resources away from dev to re-release projects with no changes.

                    2) If there's no difference in the code between 1.0.0 and 1.0.1, what does bumping the version number accomplish? You're labelling a new version, signalling that some change has been made.

                    It seems like your concerns would be alleviated with another matrix showing all component versions that comprise an EJB3 release?

                    S,
                    ALR



                    • 7. Re: Ejb3 sources in zipped form
                      Kamil Demecki Novice

                       

                      "ALRubinger" wrote:
                      "skajotde" wrote:
                      I think it is great that library can be used outside EJB3 and provides model and metatada. But main purposes of this libraries are be part of EJB3 product so I think it should be versioned in one way with one version number for releases of all libraries. So change in library-a should increase version in all libraries ?


                      I have two arguments.

                      1) It takes time/resources away from dev to re-release projects with no changes.

                      2) If there's no difference in the code between 1.0.0 and 1.0.1, what does bumping the version number accomplish? You're labelling a new version, signalling that some change has been made.



                      Yes, there are true arguments but I very prefer treat these libraries as part of EJB3 Project. So when EJB3 Project change releases new version there is one number of version.

                      "ALRubinger" wrote:

                      It seems like your concerns would be alleviated with another matrix showing all component versions that comprise an EJB3 release?

                      S,
                      ALR


                      I'm afraid of versioning madness. I know that libraries have virtues but I think they shoudn't introduce additional complex level. Main product is JBossAS which is composed from few projects which you can simply download with sources and try (one version number). Now there will be hundreds libraries. Are you sure there is good solution ?

                      Maybe tagging all trunk in svn should come back ?


                      • 8. Re: Ejb3 sources in zipped form
                        Andrew Rubinger Master

                         

                        "skajotde" wrote:
                        Yes, there are true arguments but I very prefer treat these libraries as part of EJB3 Project. So when EJB3 Project change releases new version there is one number of version.


                        You can't override logical arguments with preference. :)

                        "skajotde" wrote:
                        I'm afraid of versioning madness. I know that libraries have virtues but I think they shoudn't introduce additional complex level. Main product is JBossAS which is composed from few projects which you can simply download with sources and try (one version number). Now there will be hundreds libraries. Are you sure there is good solution ?


                        AS is an integration technology. To extend your view on a unified version number between the composite and all components would impose that Hibernate, AOP, MC, EJB3, Transactions, etc all have the same version number. And that imposes that they all have the same release schedule.

                        In truth AS brings in components to form the whole. Each project is independently managed.

                        "skajotde" wrote:
                        Maybe tagging all trunk in svn should come back ?


                        We've been this route. It's not sustainable.

                        ie. Any one change in development will stall everyone else. What we have now is a solution where each project develops on their own, making releases when stable, then integrating these releases into AS. Much more stable.

                        S,
                        ALR

                        • 9. Re: Ejb3 sources in zipped form
                          Kamil Demecki Novice

                           

                          "ALRubinger" wrote:

                          You can't override logical arguments with preference. :)


                          Version madnes is my argument and I describe my way to improve/balance this situation ;) (from experience with work on granular libraries).

                          "ALRubinger" wrote:

                          AS is an integration technology. To extend your view on a unified version number between the composite and all components would impose that Hibernate, AOP, MC, EJB3, Transactions, etc all have the same version number. And that imposes that they all have the same release schedule.

                          In truth AS brings in components to form the whole. Each project is independently managed.


                          Please don't generalise. There are projects as like whole EJB3, dont libraries.

                          Indeed eg Hibernate have 4 subprojects (core, annotations, em, validator) but on link http://repository.jboss.org/maven2/org/jboss/ejb3/ there is 22 libraries ;)

                          In definition I would separate projects from libraries. Project has separate vesioning and release schedule but library not necessary.

                          You say maven releases will have independent releases - ok, so I think there should be additional release as zipped whole binary because it is project not library. Why EJB3 doesn't release zipped distribution like JBossWS, JBossAS, JBM (there is secret installer) ? We are in Linux World and Linux Users don't like when something try hide details. I'm not pro shell scripts but ejb3-installer imho should be in zipped distro and operates on files in this zip. Now I guess it downloads jars from maven repo ?

                          So my proposition to EJB3 binaries is zip (which always can be unpack) with structure:

                          ejb3-installer.jar
                          ejb3-installer-sources.jar (shell script can be read to see what to do, so sources installer are needed)
                          other jars of EJB3 without sources

                          I suspect you are maven fan and it is main reason to using automagic installer. I'm not so (I have many trouble with unpredicatble maven dependencies). When you download whole distribution there is closed space and you see what you get. With maven this space of dependecies are open and very fast grow (to 1GB maven repo) and I have many class conflicts because I dont see which library is using. Predicable closed dependencies is my prefered way to configure project and it is main reason I ask if there is enable one whole binary of EJB3. So user is not forced to maven when using EJB3.

                          Little digression and other question: What is way to get dependency to ejb3 in my maven project. I will have to list all libraries explicite, all 22 libraries ?

                          • 10. Re: Ejb3 sources in zipped form
                            Andrew Rubinger Master

                             

                            "skajotde" wrote:
                            Version madnes is my argument and I describe my way to improve/balance this situation ;) (from experience with work on granular libraries).


                            Your proposal to address "version madness" involves coupling the release schedule of all EJB3 components. This comes at the cost of the 2 drawbacks I'd presented.

                            Would an additional assembly of all the EJB3 component resources in one place solve this? ie. ejb3-sources-1.0.0.jar, which contains all the sources from the various component versions that are in the EJB3 1.0.0 distribution?

                            "skajotde" wrote:
                            Please don't generalise. There are projects as like whole EJB3, dont libraries.


                            You've now defined a difference between "project" (ie. EJB3) and "library" (the components that make up a project release); that distinction wasn't present before.

                            "skajotde" wrote:
                            In definition I would separate projects from libraries. Project has separate vesioning and release schedule but library not necessary.


                            For the reasons laid out previously, separate release schedule for each component is necessary (or at least desirable). This *ensures* that nothing has changed when no source changes have been made. It's about a guarantee of stability, one of the reasons we've componentized so heavily in the first place.

                            "skajotde" wrote:
                            You say maven releases will have independent releases - ok, so I think there should be additional release as zipped whole binary because it is project not library. Why EJB3 doesn't release zipped distribution like JBossWS, JBossAS, JBM (there is secret installer) ? We are in Linux World and Linux Users don't like when something try hide details.


                            I think you're just asking for a new assembly to contain all of the EJB3 binaries in a unified JAR. And another one for all sources.

                            "skajotde" wrote:
                            I'm not pro shell scripts but ejb3-installer imho should be in zipped distro and operates on files in this zip. Now I guess it downloads jars from maven repo ?


                            No, the ejb3-plugin contains all artifacts to be installed, and is a standard executable JAR. There's no downloading involved.

                            "skajotde" wrote:
                            I suspect you are maven fan and it is main reason to using automagic installer. I'm not so (I have many trouble with unpredicatble maven dependencies). When you download whole distribution there is closed space and you see what you get. With maven this space of dependecies are open and very fast grow (to 1GB maven repo) and I have many class conflicts because I dont see which library is using. Predicable closed dependencies is my prefered way to configure project and it is main reason I ask if there is enable one whole binary of EJB3. So user is not forced to maven when using EJB3.


                            I didn't follow a lot of that reasoning.

                            * We use Maven as a build tool and work through both its benefits and shortcomings. No one I've found has been a "fan" for any non-technical reason.
                            * Maven has nothing to do with the "automagic installer" (ejb3-plugin).
                            * As an end-user you're not forced to use Maven at all. Take our built artifacts and go.
                            * The issue of dependencies isn't just Maven's fault. The EJB3 project must declare dependencies to be built, and AS provides its own dependency chain. So there's a compilation/test set and a runtime set, which may be mismatched. We've been in talks to address this.

                            "skajotde" wrote:
                            Little digression and other question: What is way to get dependency to ejb3 in my maven project. I will have to list all libraries explicite, all 22 libraries ?


                            Just bring in org.jboss.ejb3:jboss-ejb3-as-int:1.0.0. Everything else will come in transitively.

                            But if you're just building applications that *use* JBoss EJB3, you can get by with just the EJB3 API and the JBoss EJB3 External API. Or more simply, a dependency upon jbossall-client.jar.

                            S,
                            ALR

                            • 11. Re: Ejb3 sources in zipped form
                              Kamil Demecki Novice

                               

                              "ALRubinger" wrote:

                              Your proposal to address "version madness" involves coupling the release schedule of all EJB3 components. This comes at the cost of the 2 drawbacks I'd presented.

                              Would an additional assembly of all the EJB3 component resources in one place solve this? ie. ejb3-sources-1.0.0.jar, which contains all the sources from the various component versions that are in the EJB3 1.0.0 distribution?


                              Yes, it would be great.
                              "ALRubinger" wrote:
                              You've now defined a difference between "project" (ie. EJB3) and "library" (the components that make up a project release); that distinction wasn't present before.


                              Sorry I was unclear.
                              "ALRubinger" wrote:
                              "skajotde" wrote:
                              In definition I would separate projects from libraries. Project has separate vesioning and release schedule but library not necessary.


                              For the reasons laid out previously, separate release schedule for each component is necessary (or at least desirable). This *ensures* that nothing has changed when no source changes have been made. It's about a guarantee of stability, one of the reasons we've componentized so heavily in the first place.


                              OK.

                              "ALRubinger" wrote:
                              "skajotde" wrote:
                              You say maven releases will have independent releases - ok, so I think there should be additional release as zipped whole binary because it is project not library. Why EJB3 doesn't release zipped distribution like JBossWS, JBossAS, JBM (there is secret installer) ? We are in Linux World and Linux Users don't like when something try hide details.


                              I think you're just asking for a new assembly to contain all of the EJB3 binaries in a unified JAR. And another one for all sources.


                              Yes, as I write above.

                              "ALRubinger" wrote:
                              "skajotde" wrote:
                              I'm not pro shell scripts but ejb3-installer imho should be in zipped distro and operates on files in this zip. Now I guess it downloads jars from maven repo ?


                              No, the ejb3-plugin contains all artifacts to be installed, and is a standard executable JAR. There's no downloading involved.


                              Ok, but I'm suprised. Other JBoss projects release zips with scripts. Why you release jar which hide details what to do? As I wrote I'm not pro shell script, I think java to instalation is good but in more open form ;) Like zip with jars and sources with ejb3-installer (You can see what doing install shell script so I think it would be fine to see what doing ejb3-installer). You don't give reason why you choose ejb3-installer as jar.

                              I checked jar and you are right, it contain all libraries and has simple rules to work but I many prefer zip and when downloaded jar I was some confused.

                              "ALRubinger" wrote:
                              "skajotde" wrote:
                              I suspect you are maven fan and it is main reason to using automagic installer. I'm not so (I have many trouble with unpredicatble maven dependencies). When you download whole distribution there is closed space and you see what you get. With maven this space of dependecies are open and very fast grow (to 1GB maven repo) and I have many class conflicts because I dont see which library is using. Predicable closed dependencies is my prefered way to configure project and it is main reason I ask if there is enable one whole binary of EJB3. So user is not forced to maven when using EJB3.


                              I didn't follow a lot of that reasoning.

                              * We use Maven as a build tool and work through both its benefits and shortcomings. No one I've found has been a "fan" for any non-technical reason.
                              * Maven has nothing to do with the "automagic installer" (ejb3-plugin).
                              * As an end-user you're not forced to use Maven at all. Take our built artifacts and go.
                              * The issue of dependencies isn't just Maven's fault. The EJB3 project must declare dependencies to be built, and AS provides its own dependency chain. So there's a compilation/test set and a runtime set, which may be mismatched. We've been in talks to address this.


                              Thanks for info. I know you are right about dependencies between libraries.

                              "ALRubinger" wrote:
                              "skajotde" wrote:
                              Little digression and other question: What is way to get dependency to ejb3 in my maven project. I will have to list all libraries explicite, all 22 libraries ?


                              Just bring in org.jboss.ejb3:jboss-ejb3-as-int:1.0.0. Everything else will come in transitively.

                              But if you're just building applications that *use* JBoss EJB3, you can get by with just the EJB3 API and the JBoss EJB3 External API. Or more simply, a dependency upon jbossall-client.jar.

                              S,
                              ALR


                              Thanks.

                              • 12. Re: Ejb3 sources in zipped form
                                Andrew Rubinger Master

                                 

                                "skajotde" wrote:
                                "ALRubinger" wrote:

                                Would an additional assembly of all the EJB3 component resources in one place solve this? ie. ejb3-sources-1.0.0.jar, which contains all the sources from the various component versions that are in the EJB3 1.0.0 distribution?


                                Yes, it would be great.


                                Cool, I'll discuss this w/ the other guys on the team. Appreciate your feedback.

                                "skajotde" wrote:
                                "ALRubinger" wrote:
                                No, the ejb3-plugin contains all artifacts to be installed, and is a standard executable JAR. There's no downloading involved.


                                Ok, but I'm suprised. Other JBoss projects release zips with scripts. Why you release jar which hide details what to do? As I wrote I'm not pro shell script, I think java to instalation is good but in more open form ;) Like zip with jars and sources with ejb3-installer (You can see what doing install shell script so I think it would be fine to see what doing ejb3-installer). You don't give reason why you choose ejb3-installer as jar.

                                I checked jar and you are right, it contain all libraries and has simple rules to work but I many prefer zip and when downloaded jar I was some confused.


                                Well, the difference between ZIP and JAR is just a format specification, right? ;)

                                The Plugin, as packaged currently, takes just one step to install, making it less error-prone (no need to unzip, run a script; just execute the JAR).

                                "Why hide details what to do"? Encapsulation! :D I don't understand your Linux comparison; in standard RedHat packaging a RPM also will self-extract and install itself. I believe implementation details *should* be hidden to the user. The contract is that this artifact patches AS. The issue of "how" is out-of-scope, but you can still get at the working parts underneath if you need to.

                                S,
                                ALR

                                • 13. Re: Ejb3 sources in zipped form
                                  Kamil Demecki Novice

                                   

                                  "ALRubinger" wrote:
                                  Cool, I'll discuss this w/ the other guys on the team. Appreciate your feedback.


                                  Thanks.

                                  "ALRubinger" wrote:
                                  Well, the difference between ZIP and JAR is just a format specification, right? ;)


                                  No just specification. Zip is standard format to download files. There is Readme, you can view install script when are problems, you can change install script to do workaround.

                                  "ALRubinger" wrote:
                                  The Plugin, as packaged currently, takes just one step to install, making it less error-prone (no need to unzip, run a script; just execute the JAR).

                                  "Why hide details what to do"? Encapsulation! :D I don't understand your Linux comparison; in standard RedHat packaging a RPM also will self-extract and install itself. I believe implementation details *should* be hidden to the user. The contract is that this artifact patches AS. The issue of "how" is out-of-scope, but you can still get at the working parts underneath if you need to.

                                  S,
                                  ALR


                                  Hm encapsulation yes, but give additional ways to do workaround problems. So attach ejb3-plugin sources to jar ;). Of course sources of all jars are not need. And give README with info from run this script.