On 12/12/2011 9:33 AM, Max Carpentier wrote:
Thanxs Ron,
In fact our project is an old mulitple individual jars project (we had like
~40 jars), but eclipse had an hard time compiling/refreshing workspace so
we decided to merge a lot of projects.
There is no need for Eclipse to have any more than 1 or 2 projects open
at a time and we hardly ever have anyone who has more than a few modules
even closed in the workspace.
Close projects that you are not actively editing.
Delete projects that you are not referencing regularly.
The best way to use Eclipse is to check out projects as you work on
them, work on them, publish, commit and delete.
Build your jars and put them in Nexus (or some other Repo) as they are
released for testing (SNAPSHOTS) or released as finished versions.
Keep your projects small and functionally organized.
Think about your stuff the way Apache does their projects. Lots of
projects, each with a single purpose.
Don't mix your messaging utilities with your reporting functions. Don't
put any visualization in your messaging utility core.
Don't be afraid to separate your API into separate libraries along
functional lines with layers of abstraction.
Think SOA even if you can not fully convert the project at once. At
least start to move in that direction.
You will end up with more projects but they will be easier to
understand, easier to debug, faster to build and more likely to turn
into stable libraries that don't change during maintenance cycles and
only require minor tweaking and testing during major development releases.
Check-in the project often to your SCM as you work on it with proper
tagging and branching strategies.
Beat the crap out of people who put stuff in the SCM without proper
comments. Give you staff the same pleasure when you forget.
Let Maven and Eclipse get what they need from the repo not from the
Workspace.
We generally suppress Maven's search of the Workspace for dependencies
to ensure that it is building with the latest published SNAPSHOT rather
than some possibly leftover Eclipse project that the person downloaded a
week ago.
Ron
Anyways thanxs for your anwser, i think a mix of multi module projects and
individual projects may be the most acceptable solution to our problem.
A short term solution is also to individually release projects (solution 2
in my question)
Regards,
Max
On Mon, Dec 12, 2011 at 2:26 PM, Ron Wheeler<rwhee...@artifact-software.com
wrote:
We did exactly what you want to do.
We built a learning management system that includes more than 70 jar and
war files.
We started out changing every version with each release but soon reached a
point where most of the modules did not change as we improved the
modularity of the system and as maintenance and new portlets became the
cause of the majority of the new releases so even a minor release version
actually only involved the core, some web services and a few modules.
We moved to individually versioned projects with a shared parent.
At the beginning of a development cycle we document the versions of each
project that makes up the application.
We have to be careful about upward compatibility but other than that, it
works very well.
We do not use CI.
It seems to be more trouble than it is worth and I am suspicious that it
can be used as a substitute for thinking or proper testing.
We are also a small group so the sense of personal responsibility is high
and communication is not a huge problem.
We also use a lot of `provided` scope which keeps the artifacts small and
free of third party libraries or our own libraries so that the 1.10 war has
nothing in it that will conflict with any 1.11 jar file that holds the api
or core or utilities.
I hope that our experience is useful to you.
Ron
On 12/12/2011 5:23 AM, Karl Heinz Marbaise wrote:
Hi,
Well, that's the problem..we don't want to release a new version of
unchanged projects because it will confuse our users, especially for the
api projects...
maybe we did wrong using this kind of layout ?
Thanxs for your answers anyways
In this case you should separate out the api module and use this as a
dependency in your project and release it separately...
Kind regards
Karl Heinz Marbaise
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
