You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Daniel F. Savarese" <df...@savarese.org> on 2004/04/25 01:03:45 UTC

Re: [net] commons-net.1.2.0-rc1

In message <85...@firefoot.brekke.org>, Jeffrey D. Brekke writes:
>standard stuff won't do.  Or better yet, lets just put the two lines
>from the NOTICE.txt into the README.txt.

We can't do that because putting it in NOTICE is required by the Apache
License.  If I didn't miss anything, we're talking about is getting
NOTICE.txt into the jar and the tarball.  I'm no Maven maven, but it looks
like what you have to do is add the following to project.xml:
  <build>
    <resources>
      <resource>
        <directory>${basedir}</directory>
        <targetPath>META-INF</targetPath>
        <includes>
          <include>NOTICE.txt</include>
        </includes>
      </resource>
    </resources>
   </build>

That will take care of getting NOTICE.txt into the jar file.  Although,
for the life of me I can't tell how the jar plugin picks up on the
resource info ...  As far as getting the file into the distribution
goes, I think we're going to have to patch the dist plugin to make
it customizable and submit that to the Maven team, or just maintain our
own Commons dist plugin as Jeff suggested.  The dist plugin doesn't appear
to be customizable.  Of course, the Maven team will eventually add
<ant:include name="NOTICE*"/> to the dist plugin, but that doesn't solve
the general problem.  It seems like a lot of Maven plugins should be
extensible or at least customizable so they don't force a single way of
doing things on the end user.  Otherwise, you wind up having to write your
own plugins which is not exactly an efficient way to go about things when
an existing plugin already does most of what you need.  Which is to say 
that it's better if we add a hook to the dist plugin that allows arbitrary
files to be pulled into a distribution and ask the Maven team to apply the
patch.

daniel



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [net] commons-net.1.2.0-rc1

Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
>>>>> On Sat, 24 Apr 2004 19:03:45 -0400, "Daniel F. Savarese" <df...@savarese.org> said:

> In message <85...@firefoot.brekke.org>, Jeffrey D. Brekke
> writes:
>> standard stuff won't do.  Or better yet, lets just put the two
>> lines from the NOTICE.txt into the README.txt.

> We can't do that because putting it in NOTICE is required by the
> Apache License.  If I didn't miss anything, we're talking about is
> getting NOTICE.txt into the jar and the tarball.  I'm no Maven
> maven, but it looks like what you have to do is add the following to
> project.xml: <build> <resources> <resource>
> <directory>${basedir}</directory> <targetPath>META-INF</targetPath>
> <includes> <include>NOTICE.txt</include> </includes> </resource>
> </resources> </build>

That will work nicely for the jar.

> That will take care of getting NOTICE.txt into the jar file.
> Although, for the life of me I can't tell how the jar plugin picks
> up on the resource info ...  As far as getting the file into the
> distribution goes, I think we're going to have to patch the dist
> plugin to make it customizable and submit that to the Maven team, or
> just maintain our own Commons dist plugin as Jeff suggested.  The
> dist plugin doesn't appear to be customizable.  Of course, the Maven
> team will eventually add <ant:include name="NOTICE*"/> to the dist
> plugin, but that doesn't solve the general problem.  It seems like a
> lot of Maven plugins should be extensible or at least customizable
> so they don't force a single way of doing things on the end user.
> Otherwise, you wind up having to write your own plugins which is not
> exactly an efficient way to go about things when an existing plugin
> already does most of what you need.  Which is to say that it's
> better if we add a hook to the dist plugin that allows arbitrary
> files to be pulled into a distribution and ask the Maven team to
> apply the patch.

<postgoal> and <pregoal> allow for hooking onto goals.

I think we can extend the preparation of the tar dists with
<postgoal/>.  Inside the postgoal, copy the NOTICE file into the
correct directory.  I'll try it soon.

-- 
=====================================================================
Jeffrey D. Brekke                                   jbrekke@wi.rr.com
Wisconsin,  USA                                     brekke@apache.org
                                                    ekkerbj@yahoo.com


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


[net] Question regarding setup for tests for the POP3 module

Posted by Mike George <mi...@comcast.net>.
Hello,
	I'm writing tests for the POP3 and SMTP modules.  These modules must
connect to POP3 and SMTP servers in order to be fully tested.

	Currently, I am using a default installation of James running on localhost
with a user named test.  This seems to work pretty well for me but might
introduce an unwelcome dependency for people who want to run the tests.

	Question:
	(1) Should I write the tests and hardcode in 'localhost', 'user=test' and
'password=blah'??
	or
	(2) Should I make a small class named POP3TestConstants and set the values
there for the server, user and password there? Future testers would have to
modify this class or a config file to run the tests on their machines?
	or
	(3) Should I stick to unit tests that can be run without having to use a
server? (I think this would lead to a very incomplete set of tests.)

	or ???.  I'm open to advice.

	I appreciate any help.  I'm pretty new at this and would like to do things
the right way.

Thanks,

Mike

	In order to make


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org