...
- Build/Dependency tools must be configured to retrieve the source artifact for JARs.
- Build/Dependency tools must be easily able to create and update javadocs.
- Build/Dependency tools must have the ability to support environment profiles.
- Build/Dependency tools must have support for local dependencies.
- Consider what may be the most natural and easiest option for a Grouper contributor to get started.
- There needs to be a way for Grouper to determine the version of its JARs used:
- Can be use/reference the Maven build maintained in parallel with ant.
- Can use the JAR manifest itself.
- IDE integration is important. While IntelliJ/NetBeans have no issues with either of these tools, Eclipse may be problematic for Maven or Gradle.
Notes about how it previously worked
- Jars contained the source of the jar so it could be easy and low risk to debug/patch
- Jars had names of the jar without the version in the name so that version control would show a history on the file
- Dev target in ant would copy jars to webapp folder so the application could be debugged without a warfile. Note, source is in jar so it can be easily debugged
- The hibernate jar was patched, not sure which others
- All versions are in the manifest of the jar. If the jar doesnt put it in there by default, it was added by grouper developer
- Grouper will check the size and version of jars on startup and warn which ones arent right
- Grouper installer will try to look for jar conflicts