Team development

[carmelo]

Hi everybody,
I'm planning to develop a web application with a team of developers
using JDeveloper. I'm wondering if it could be possible to assign a
specific part of the project, and of the code, to a developer, without
giving them the entire application code.


I hope you can help me.

Thank you very much in advance!

 

[Arved Sandstrom]

Hi everybody,
I'm planning to develop a web application with a team of developers
using JDeveloper. I'm wondering if it could be possible to assign a
specific part of the project, and of the code, to a developer, without
giving them the entire application code.

I hope you can help me.

Thank you very much in advance!

What's the purpose of not giving them all the application code? I can't
think of a sound technical or managerial reason for wanting to do this, so
I'm guessing it's an IP reason.

Don't get me wrong, I can think of a lot of reasons for requiring that
developers code to an API exposing a black box ( a JAR). In a full-fledged
J2EE application development environment you might enforce that by ensuring
that presentation layer (JSF, say) developers never see the guts of the
service layer (session beans, say) or domain layer (DAOs, entity beans etc),
and simply get the JAR files instead with no access to source for better
decompilation. The main reason for doing this is that developers do code to
APIs, which is never a bad idea. But it would also achieve some of your
ends.

In principle you could also, by some process I haven't put thought into
before because I've never seriously contemplated doing it, split up the web
tier functionally. If you wanted to enforce this then source control would
be a place to start; if you don't want developer A to have the JSF beans or
XHTML Facelets pages for the Toroidal Perforation Control module then you
can place that code into its own folder(s) that developer A doesn't have
source control access to. Although I wouldn't create such a folder structure
for the purpose of enforcing these restrictions - I'd have the folder
structure for organization, and simply make use of that structure for your
specific purpose. But where you could run into problems here is if you have
configuration files - web.xml and faces-config.xml and suchlike - that in
their full form reference everything (all servlets, all managed beans, and
so forth). What do you do then? Provide each web tier developer with their
own versions? You could, I guess.

AHS

 

[carmelo]

Thank you Arved.
I'm currently using Subversion as version control system.
However I'm seeing that a possible solution could be splitting the web
app in multiple modules which communicate via interfaces, but this is
not automatic and not so easy.

One solution could be using Subversion permissions on folders, so that
I could manage developer permissions accessing the code. What do you
think about it?

 

[Lew]

Thank you Arved.
I'm currently using Subversion as version control system.
However I'm seeing that a possible solution could be splitting the web
app in multiple modules which communicate via interfaces, but this is
not automatic and not so easy.

One solution could be using Subversion permissions on folders, so that
I could manage developer permissions accessing the code. What do you
think about it?

Terrible idea.

Separate the project into antecedent projects that build JARs, feeding
into the technique Arved described, that of having developers code to
completed JARs (WARs, EARs) rather than source.

You cannot completely hide Java source regardless. One really wonders
why you wish to bother. You failed to answer that question when Arved
posed it. It seems like a really dumb idea. Maybe you think you have
a good reason for trying it, even though it really cannot be done.

 

[Roedy Green]

I'm planning to develop a web application with a team of developers
using JDeveloper. I'm wondering if it could be possible to assign a
specific part of the project, and of the code, to a developer, without
giving them the entire application code.

see http://mindprod.com/jgloss/subversion.html

I suspect there would be features to control who can see what. You can
stop people from using features inside the black box by insisting they
use only an interface that exposes just what you want to guarantee
stable.

In a pinch you could set up multiple repositories.

--
Roedy Green Canadian Mind Products
http://mindprod.com

Microsoft has a new version out, Windows XP, which according to everybody is the "most reliable Windows ever." To me, this is like saying that asparagus is "the most articulate vegetable ever."
~ Dave Barry

 

[John B. Matthews]

Terrible idea.

Separate the project into antecedent projects that build JARs,
feeding into the technique Arved described, that of having developers
code to completed JARs (WARs, EARs) rather than source.

Consonant with Lew's and AHS's suggestions, my colleagues carefully
segregate antecedent projects. This greatly simplifies regression
testing, configuration management and license compliance.

As a practical matter, I use Apache and mod_dav_svn in conjunction with
trac [2] to manage multiple projects. In this way, only designated
projects need incur the overhead of SVNPathAuthz [3].

[1]<http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.ref.mod_dav_svn>
[2]<http://trac.edgewall.org/>

 

[John B. Matthews]

see http://mindprod.com/jgloss/subversion.html

I suspect there would be features to control who can see what.

Indeed, the section "Path-Based Authorization" mentions
AuthzSVNAccessFile and discusses some of the trade-offs:

<http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.serverconfig.pathbasedauthz>

 

[Eric Sosman]

Thank you Arved.
I'm currently using Subversion as version control system.
However I'm seeing that a possible solution could be splitting the web
app in multiple modules which communicate via interfaces, but this is
not automatic and not so easy.

One solution could be using Subversion permissions on folders, so that
I could manage developer permissions accessing the code. What do you
think about it?

You have failed to pay attention to Arved Sandstrom's response.
Step away for a moment from the tactics ("Programmer X must never see
source code Y"), and explain the larger strategic problem you face.
We can't give advice in a vacuum -- well, we *can* do so, but you're
going to have trouble breathing it.

 

[carmelo]

JDeveloper, the IDE I'm using for developing this web app, offers the
capability of creating reusable application components as library
jars. Therefore I could divide my application into components and
distribute them as Library JARs to the team. People who don't need to
see the source code can consume the library JARs and won't need the
source code. What do you think about it?

 

[Lew]

JDeveloper, the IDE I'm using for developing this web app, offers the
capability of creating reusable application components as library
jars [sic]. Therefore I could divide my application into components and
distribute them as Library JARs to the team. People who don't need to
see the source code can consume the library JARs and won't need the
source code. What do you think about it?

I think that it's good that you considered following the advice that three or
more folks have given you in this thread.

JDeveloper doesn't offer that capability, it offers an easy way to manage that
capability already quite vital and present in Java anyway.

 

[Martin Gregorie]

JDeveloper, the IDE I'm using for developing this web app, offers the
capability of creating reusable application components as library jars.
Therefore I could divide my application into components and distribute
them as Library JARs to the team. People who don't need to see the
source code can consume the library JARs and won't need the source code.
What do you think about it?

Sounds OK provided that:

- the jar content developers document their code well enough that
the generated Javadocs contain enough information for their packages
to be used without recourse to code reading or talking to the
developers. This does require that the Javadocs are at least as good
as the stuff in the SDK javadocs and associated tutorial documents.

This may be a problem if project standards and developer discipline
aren't good enough to enforce the required documentation standard.

Alternatively, the problem may be mitigated if the module designers
write their specs as compilable Java source that contains only package,
class and method level comments together with empty method skeletons.
As I tend to write module specs and develop code this way I think this
is a good approach, but ymmv.

- there's no adverse impact if the scope of source version control is
also limited to the contents of each jar file, i.e. there is no overall
version control spanning the whole project.

This may be a non-issue if you split code into jar files appropriately,
but again that depends on the designers and project organisation and
nobody outside the project can know if this might cause problems.

 

[Eric Sosman]

JDeveloper, the IDE I'm using for developing this web app, offers the
capability of creating reusable application components as library
jars. Therefore I could divide my application into components and
distribute them as Library JARs to the team. People who don't need to
see the source code can consume the library JARs and won't need the
source code. What do you think about it?

A squid offers the capability of squirting ink. Therefore, you
could get all your developers to look odd and smell odder. What do
you think about it?

In other words, carmelo, you still haven't described your purpose.
Nobody can tell you whether this or that capability or tactic would
be helpful or harmful to your purpose if you won't disclose it. We
cannot tell you what kind of bricks to use in your wall until we know
whether you want it to withstand an earthquake or shatter spectacularly
at the end of a movie car chase.

 

[carmelo]

I'm planning to hire some developers from around the world, and since
we will not work side by side I was wondering if could be a good idea
to divide the job without giving them the whole project, making them
work only on their personal tasks. Some developers will work only on
small project pieces, so I was wondering how could I provide them only
elements for a specific task without giving the whole project code.

I know that it depends on what you need to achieve. However now I've
got a clearer view about this.

Thank you very much for your help guys!

 

[Arne Vajhøj]

JDeveloper, the IDE I'm using for developing this web app, offers the
capability of creating reusable application components as library
jars. Therefore I could divide my application into components and
distribute them as Library JARs to the team. People who don't need to
see the source code can consume the library JARs and won't need the
source code. What do you think about it?

Certain Java features like public/private accessibility,
architectural governance and code reviews should handle that.

Without needing to use source control to enforce it. If you
have a process problem, then fix the process instead of using
a tool to try and fix a single symptom.

Arne