Announcement Announcement Module
No announcement yet.
Automated (spring) setup when importing projects Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Automated (spring) setup when importing projects

    I think it would be nice if imported could be automatically configured ny sts when importing a spring based project. Today one need to, (correct me if Iīm wrong), go into prefs on each module having spring context files and scan/add those and then create groups out of these. The groups must be created in a given order based on module dependencies, for get them all covered...

    This is a very time consuming task which should be automated in my opinion.

    When working with maven based projects, itīs more common I think to import rather than open, (pre-configured), projects.

    /Jens O

  • #2
    Hey Jens!

    I fully agree. The automatic configuration that we do today is based on Eclipse WTP dynamic web projects and doesn't do always the right job. We should do better.

    With regards to the configuration sets: What would you expect from the automatic configuration for them? I use them to define different sets of beans in order to get validation for different contexts and I am not sure how much of that can be done automatically. Do you have anything specific in mind for this?

    I created this JIRA ticket to improve the auto configuration and we can collect sub-tasks for the individual steps there:



    • #3
      Great! Thanks.

      Iīm not that familiar with configuration sets since I really not quite understand its semantics. Iīve noticed though that I need to set something up to avoid missing bean declarations.

      I usually create one called main, which includes this modules context files together with dependent modules (main) context files. Usually this would mean that all modules context files placed under src/main/resources/** would end up in the same configuration set.

      This works fine for me (when I take the time doing it ;-). Probably I could setup test sets as well, but I haventīreally experimented with that.

      So, my expectation is basically that all context files would be put i each modules (main?) configuration set. If Iīm not fine with this I could simply remove them...

      But as I said, Iīm not very experienced with these configuration sets. Probably thereīs some best practice to use these and I would willingly conform to those...


      • #4

        The main application for the bean config sets is validation:

        A Spring application might have different contexts it is running in (tests, integration, production, cloud, what so ever). Those different environments are often configured using multiple Spring XML config files (or bean profiles since Spring 3.1).

        Using the bean config sets in the IDE, you can define the context for the validations that are running in the IDE. Therefore if you would like, for example, to run validations (like the missing bean reference warning that you mentioned) in the context of production as well as integration, you can define two bean config sets (one for each context you would like the validations to run in). One bean config set would contain all the config files that are active in production and one additional config set with all the config files selected that are active in your integration setting. The validations run against each bean config set separately.

        Therefore I am not sure what a good mechanic would be to automatically configure config sets. But I fully agree, it would be very useful. We could, for example, auto-configure a config set that contains everything - and in case someone needs something else, he/she could change that configuration. But that is just a thought. Additional input would be highly appreciated!!!



        • #5
          Ok. Thx for clarifying.

          Actually I donīt quite see the usefulness of config sets. Probably Iīm missing something, but shouldnīt all context files be valid(ated)? To me contexts is more about overriding specific beans for some environment.

          Iīm aware that you sometimes has a different runtime setup, but thats (at least before bean profiles) configured outside the spring context. To me itīs like having manually defined compilation sets of java files for different configurations... Lets say I have different datasource beans in test/prod configuration. These, and all depending beans, can be validated, even though we at build time doesnīt know which one will be used in runtime.

          I think it should be fine to add everything into one set. Or, if present, sets reflecting the setup bean profiles.


          • #6

            That sounds very reasonable. Lets collect those suggestions in this JIRA issue:

            Much appreciated!!!