Well, I believe that for Maven2 we are supposed to have one JAR file per subproject, although it does seem that this could result in lots of small subprojects. Maybe someone has more ideas on this subject.

-> richard

Francesco Furfari wrote:
Yes, the base driver now is splitted in two bundles : badriver and basedriver-extra
more we have a bundle for the Generic Control Point utility
and some demo bundles to show the basedriver working on the OSGi side

another question is related to the patched CyblerLink libraries that Stefano mantain aligned with
Satoshi versioning.

more recently Nico Goeminne as donated to us a backported (Java 1.3.1) version of the Basedriver (and extra and patched cyberlink) that we should mantain separately.


ff


Richard S. Hall ha scritto:

I am fine with having a separate sub-directory for src and test, but I think in that case it makes sense to keep package names the same, e.g.:

   trunk/
      org.apache.felix.upnp/
         src/
            org/apache/felix/upnp/basedriver
            ...
         test/
            org/apache/felix/upnp/basedriver
            ...

It seems a benefit of this approach is that you can have package private access.

One thing to point out, however, is that I was under some understanding that there was supposed to be one JAR file per-subproject mapping. Does UPnP get packaged into multiple bundles? If so, we will need to create a trunk/ subproject directory for each one.

-> richard

Francesco Furfari wrote:

No, it should be
trunk/
   org.apache.felix.upnp/
      src/
         org/apache/felix/upnp/
            basedriver/*.java
            controlPoint/*.java
            samples/*.java
            otherComponents/*.java

for the source code,
now for the testcases code we could use
trunk/
   org.apache.felix.upnp/
      src/
      test/

or

trunk/
   org.apache.felix.upnp/
      src/
         org/apache/felix/upnp/
            basedriver/test/*.java
            controlPoint/test/*.java
            samples/test/*.java
            otherComponents/test/*.java

does it sound good for you?
what do you prefer? we haven't testcase yet.

ff


Richard S. Hall ha scritto:

If I understand everything correctly, under the current proposal you would have this:

trunk/
   org.apache.felix.upnp.basedriver/
       src/org/apache/felix/upnp/basedriver/*.java
       src/org/apache/felix/upnp/basedriver/test/*.java

Note that the trunk/ directory contains sub-project directories named after the sub-projects package name. We do not have an org/ directory in the trunk/ directory.

-> richard

Francesco Furfari wrote:

so in the repository we have
trunk/org/apache/felix/upnp/src[org.apache.felix.upnp.basedriver]
and
trunk/org/apache/felix/upnp/test[org.apache.felix.upnp.basedriverTest]
where [org.apache.felix.upnp.*] are the folders for packaging

is it right?
francesco

Richard S. Hall ha scritto:

I am in agreement with Enrique on this one. I would not like to see the test cases for each sub-project be a sub-project in the trunk/ directory, because this will pollute the trunk/ directory by doubling its contents. I think each sub-project should put its test cases inside of its trunk/sub-project/ directory. The only tests that should potentially be in the trunk/ directory are those that span multiple sub-projects, I think.

-> richard

Enrique Rodriguez wrote:

Richard S. Hall wrote:

Francesco Furfari wrote:

It's ok for me, we have a similar structure.
What for the test cases? do we put all inside the subprojects? org.apache.felix.upnp.test?




This seems to make more sense to me, as opposed to org.apache.felix.test.upnp...but I can go either way.




I was picturing implementation code and testcases in the same subproject, but in separate source folders. During packaging, the testcases are not included in the resulting jar/bundle.

Is this what the separate bundle for tests is for or is the test subproject specifically for some sort of integration tests, ie tests against the public API? Where do per-class unit tests go? I would like some help understanding this practice.

Enrique














Reply via email to