You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Brett Porter <br...@gmail.com> on 2006/01/01 03:28:53 UTC

Re: [scm] [STATUS] Repository reorg and move to m2 "completed"

Nice work Alex! I'm gald to hear this hasn't appeared to cause a great
deal of pain.

On 12/31/05, Alex Karasulu <ao...@bellsouth.net> wrote:
> No more emma plugin for MINA.

clover and cobertura should work out of the box (though they both need
releases at this point).

>
> Site doc generation is not setup.  We need some kind of scheme for this
> with the new m2 functionality.

It will be about 2 weeks before the final site stuff is released, so
it might be easiest to wait for that rather than using snapshots.

> I could not find a way to do what javaapp plugin does for the
> apacheds-server-main.  We need to figure something out for minimal
> packaging.  For now it builds an executable jar but does not hold all
> dependencies.

I can help with that. It's how maven-artifact-ant is packaged. Catch
me on IRC some time and remind me :)

> POMs are no longer filled with all the info in old m1 project.xml.  Only
> the minimal set of elements are present to build although a couple
> projects may have all fields transfered.

Should aim to inherit as much of this as possible.

> 5. Deploy some jars to ibiblio.

What JARs do you need deployed to ibiblio?

I'll review soon and give feedback. I'm particularly interested in the
selection of groupIds, etc.

Thanks!

- Brett

Re: [scm] [STATUS] Repository reorg and move to m2 "completed"

Posted by Brett Porter <br...@gmail.com>.
On 1/4/06, Alex Karasulu <ao...@bellsouth.net> wrote:
> That's great Brett thanks a bunch.  BTW one last thing though I cannot
> seem to pull down that SNAPSHOT for the assembly plugin in the
> apacheds-server-main/pom.xml.  Could you deploy the snapshot to
> http://cvs.apache.org/maven-snapshot-repository?

The right repo is in the parent pom. You can do a full install to
correct it. If the hierachical layout were used, or <relativePath>
were set to adapt the layout, it would be detected from the file
system. I can do those if you decide to stick with flat.

> Right.  When migrating I followed the flat structure that was voted in.

Maybe I glossed over it, but I think the vote proposal wasn't
exhaustive and didn't really give the indication of how it would end
up. I always thought (probably assumed) that it was going to be
hierachical.

- Brett

Re: [scm] [STATUS] Repository reorg and move to m2 "completed"

Posted by Alex Karasulu <ao...@bellsouth.net>.
Brett Porter wrote:

>Ok, the assembly is working. I had to fix a few bugs on the way, but
>I'll push forward for an assembly plugin release soon.
>  
>
That's great Brett thanks a bunch.  BTW one last thing though I cannot 
seem to pull down that SNAPSHOT for the assembly plugin in the 
apacheds-server-main/pom.xml.  Could you deploy the snapshot to 
http://cvs.apache.org/maven-snapshot-repository?

>Some more comments...
>
>On 1/3/06, Brett Porter <br...@gmail.com> wrote:
>  
>
>>>Yeah we got some issues with the groupId's because of every subproject
>>>picking its own package name.  I think we all need to derive from the
>>>same org.apache.directory base for packages.  Then make our groupId this
>>>or off of it like org.apache.directory.asn1.  WDYT?
>>>      
>>>
>>You don't have to change the package names, but definitely should have
>>o.a.directory as a base for groups. You can either put them all in the
>>one group, or if you expect each subproject to have a number of
>>modules (like mina), then they might want their own group IDs like
>>you've suggested.
>>    
>>
>
>The main comment I have on the build is that the very flat layout
>might be better as a hierachy (which is similar to the comment above).
>That way, you can build all the apacheds modules, all the mina
>modules, or everything together. Currently, it's one or everything.
>
>  
>
We actually have a mina-build and an apacheds-build for handling 
specific builds.  Others have also had issues with this flat scheme. 

>so:
>+ pom.xml
>+- apacheds
>  +- pom.xml
>  +- apacheds-shared
>    +- pom.xml
>  +- apacheds-server-main
>    +- pom.xml
>  ...
>+- mina
>  +- pom.xml
>  +- mina-examples
>    +- pom.xml
>...
>
>This would also give you the level to include the parent poms,
>removing the need for -build modules.
>  
>
Right.  When migrating I followed the flat structure that was voted in.  
Looks like this will change.  We can take a re vote if need be.  
Personally I waver: I liked hierarchy with what you recommended but flat 
looks good too.  I can go either way really.  What do the others think?

>I haven't done any more than the base build, but it worked out of the
>box on my clean environment. Nice!
>  
>
This was possible thanks to the maven2 team. :)

Alex


Re: [scm] [STATUS] Repository reorg and move to m2 "completed"

Posted by Brett Porter <br...@gmail.com>.
I forgot to mention, the generated server is >9Mb. I think there are a
lot of unnecessary dependencies in there - eg. ant and xerces. You
might want to review your dependency tree.

In addition, Torsten has recently been working on a jar trimming
plugin for Maven that will post-remove any unused classes. That will
help shrink it down once that's done.

- Brett

On 1/3/06, Brett Porter <br...@gmail.com> wrote:
> Ok, the assembly is working. I had to fix a few bugs on the way, but
> I'll push forward for an assembly plugin release soon.

Re: [scm] [STATUS] Repository reorg and move to m2 "completed"

Posted by Brett Porter <br...@gmail.com>.
Ok, the assembly is working. I had to fix a few bugs on the way, but
I'll push forward for an assembly plugin release soon.

Some more comments...

On 1/3/06, Brett Porter <br...@gmail.com> wrote:
> > Yeah we got some issues with the groupId's because of every subproject
> > picking its own package name.  I think we all need to derive from the
> > same org.apache.directory base for packages.  Then make our groupId this
> > or off of it like org.apache.directory.asn1.  WDYT?
>
> You don't have to change the package names, but definitely should have
> o.a.directory as a base for groups. You can either put them all in the
> one group, or if you expect each subproject to have a number of
> modules (like mina), then they might want their own group IDs like
> you've suggested.

The main comment I have on the build is that the very flat layout
might be better as a hierachy (which is similar to the comment above).
That way, you can build all the apacheds modules, all the mina
modules, or everything together. Currently, it's one or everything.

so:
+ pom.xml
+- apacheds
  +- pom.xml
  +- apacheds-shared
    +- pom.xml
  +- apacheds-server-main
    +- pom.xml
  ...
+- mina
  +- pom.xml
  +- mina-examples
    +- pom.xml
...

This would also give you the level to include the parent poms,
removing the need for -build modules.

WDYT?

I haven't done any more than the base build, but it worked out of the
box on my clean environment. Nice!

- Brett

Re: [scm] [STATUS] Repository reorg and move to m2 "completed"

Posted by Brett Porter <br...@gmail.com>.
On 1/3/06, Alex Karasulu <ao...@bellsouth.net> wrote:
> >It will be about 2 weeks before the final site stuff is released, so
> >it might be easiest to wait for that rather than using snapshots.
> >
> >
> Is the current release candidate all that different from what is to be
> released?

Release candidate? Its just in SVN. The current version is pretty
close functionally, just some bugs and improvements to take care of. I
only recommended waiting because you might get some teething pains
using it now (it requires Maven 2.0.2, which is also unreleased).

> Cool thanks!  This is the most important thing we have to take care of
> for now to get back to our old state with M1.

Ok, it shouldn't take long.

> Yeah we got some issues with the groupId's because of every subproject
> picking its own package name.  I think we all need to derive from the
> same org.apache.directory base for packages.  Then make our groupId this
> or off of it like org.apache.directory.asn1.  WDYT?

You don't have to change the package names, but definitely should have
o.a.directory as a base for groups. You can either put them all in the
one group, or if you expect each subproject to have a number of
modules (like mina), then they might want their own group IDs like
you've suggested.

- Brett

Re: [scm] [STATUS] Repository reorg and move to m2 "completed"

Posted by Alex Karasulu <ao...@bellsouth.net>.
Brett Porter wrote:

>Nice work Alex! I'm gald to hear this hasn't appeared to cause a great
>deal of pain.
>  
>
Yeah it was pretty good.  Just had to dive in.  M2 is a quantum leap 
better than M1.  The maven peeps did a great job.

>>Site doc generation is not setup.  We need some kind of scheme for this
>>with the new m2 functionality.
>>    
>>
>
>It will be about 2 weeks before the final site stuff is released, so
>it might be easiest to wait for that rather than using snapshots.
>  
>
Is the current release candidate all that different from what is to be 
released?

>>I could not find a way to do what javaapp plugin does for the
>>apacheds-server-main.  We need to figure something out for minimal
>>packaging.  For now it builds an executable jar but does not hold all
>>dependencies.
>>    
>>
>
>I can help with that. It's how maven-artifact-ant is packaged. Catch
>me on IRC some time and remind me :)
>  
>
Cool thanks!  This is the most important thing we have to take care of 
for now to get back to our old state with M1. 

>>POMs are no longer filled with all the info in old m1 project.xml.  Only
>>the minimal set of elements are present to build although a couple
>>projects may have all fields transfered.
>>    
>>
>
>Should aim to inherit as much of this as possible.
>
>  
>
Right I want to do this to reduce amount yes.

>>5. Deploy some jars to ibiblio.
>>    
>>
>
>What JARs do you need deployed to ibiblio?
>
>I'll review soon and give feedback. I'm particularly interested in the
>selection of groupIds, etc.
>  
>
Yeah we got some issues with the groupId's because of every subproject 
picking its own package name.  I think we all need to derive from the 
same org.apache.directory base for packages.  Then make our groupId this 
or off of it like org.apache.directory.asn1.  WDYT?

Alex